Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Terminate early with TLS certificate errors #192

Open
danschultzer opened this issue Feb 25, 2019 · 3 comments
Open

Terminate early with TLS certificate errors #192

danschultzer opened this issue Feb 25, 2019 · 3 comments

Comments

@danschultzer
Copy link

I'm building an adapter to one of my libraries to use Gun, and testing with badssl.com for expired certificate.

I use the following SSL verification setup (elixir):

opts =
  %{transport_opts: [
    verify: :verify_peer,
    depth: 99,
    cacerts: :certifi.cacerts(),
    verify_fun: {&:ssl_verify_hostname.verify_fun/3, check_hostname: to_charlist(host)}
  ]}

However there's no way to monitor errors in the transport_connect/2 method, and it just keeps on retrying until it fails. I think it should be possible to monitor the process there, and it should probably always terminate early if {bad_cert, Reason} error is returned for the gun_tls transport.

@essen
Copy link
Member

essen commented Feb 25, 2019

Hmm I wonder. On the one hand if the certificate is wrong there's no point retrying. On the other hand if the certificate is in a file the file may be updated and Gun can then reconnect successfully. So I suppose it depends on the setup. I would be OK with adding an option retry_on_bad_cert = boolean() that defaults to true.

@danschultzer
Copy link
Author

I agree, adding that option is the best solution. It won't break any existing setup 👍

Though from my personal experience working with SSL in elixir, I do think that most devs would want it to stop retrying since there is only a 5 second timeout by default and the majority would use something like :certifi.cacerts/0 to package certs with their erlang/elixir releases.

@essen
Copy link
Member

essen commented Feb 25, 2019

If your main concern is cacerts I don't disagree, but don't forget the case of client certificates for things like authentication. If we could distinguish perhaps the default behavior could be improved.

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants