-
Notifications
You must be signed in to change notification settings - Fork 3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
SSL false sense of security #5899
Comments
@mcodev31, not sure you're aware but there's also this reference: https://erlef.github.io/security-wg/secure_coding_and_deployment_hardening/ssl.html, from the Security Working Group of the Erlang Ecosystem Foundation. |
Thanks, I'm not stating that there is a lack of documentation (although that article should probably mention the dangers of adding server and client root ca to cacerts), but rather that, given how prone to error the area of security is, it may be a good idea for OTP to lower the risk of the user removing the S from TLS unknowingly. |
Maybe a good first step is making it more clear that I don't see any public erlang OTP docs that state that and I always have to jump back into ssl_internal's source code whenever I am trying to show someone erlang's current default SSL behavior. It seems like something that should be discoverable on the ssl docs but it is not. |
I agree that the documentation for the ssl API should clearly state that |
We should improve the documentation, however, we do have this warning (since OTP 24 I think) if you have not specified any CA-certs. =WARNING REPORT==== 5-May-2022::10:19:07.667363 === |
Worth noting is that while |
I don't think that this is a big problem in general (or perhaps even a problem at all, if you feel this is how it should be) but simple things like this just feel like they should fail to me (hence the suggestion in the first place):
since it may very well be that someone running that command assumes that the cert is verified against a system root (like so many things are), or perhaps doesn't understand TLS at all. |
The default behavior of an HTTP client (such as httpc) and the ssl application (that is a socket/transport API) are different things. The ssl application does not make assumptions and decisions that it does not have enough knowledge to make. We have been working on support for OS-provided CA certs that can be used to improve httpc implementation. |
Of course they are different, but the example problem above also applies to e.g. gun or ibrowse, which I think is telling. These projects have a lot of users and hence a lot of potential security vulnerabilities. The application doesn't have to make any assumptions. Just like opting into weak ciphers is explicit, opting out of one of the main TLS security measures should be as well. If it's not clear by now, my suggestion is to not compromise the security of the protocol by default and rely on the application developer having a good enough understanding of the implementation to rectify the problem. If that can't be done then I would suggest at least adding peer verification options to all examples like these Thanks for all the good work. |
The side initiating the connection should always verify the peer by default. That said, without ca store to use by default, that doesn't work out. Looking forward to:
and hoping that can be applied to ssl app itself, not just httpc. |
I think that we agree on the basic principle of having secure defaults when possible. But not every user of the ssl application is an HTTPS client. I do not think it should be up to the general library to decide who the user application should trust. For many other applications trusting the hundreds of web CAs out there does not make sense. We will be fixing httpc (as we maintain it). I do understand that from your perspective it would be nice if all HTTPS clients were just automatically fixed by our default values. However, we now made it easy for Web-client developers to use the os provided CA-certs for their applications, so hopefully, they will. |
Actually my suggestion is not to default to any os root store, but rather to fail with an error when no ca is supplied (unless no peer verification is set). It would be a breaking change, but the “break” would be to expose vulnerable connections. But great that it’s easier to use os certs. |
We could consider such a breaking change for the OTP-26 time frame. We did add the ``=WARNING REPORT==== 12-May-2022::10:20:12.907384 === |
Yah, I agree that not all ssl clients would want to trust the OS cert store by default. I do agree it is better to fail by default if no CA is provided. Hopefully OTP 26 can make that change. Thank you! |
* ingela/ssl/false-sense-of-security/GH-5899/OTP-18455: ssl: Change client default verify
Is your feature request related to a problem? Please describe.
Some of the ssl default options/behaviour leads to a false sense of security.
Most ssl systems will force explicit deactivation of peer verification in order to prevent accidental mitm exposure (otp default is verify_none).
Using cacerts option for both server can client CAs is a potential security problem where e.g. a client cert can be signed by a cert in the server CA chain.
Both of these problems can be avoided by the user (verify_peer, don't specify server CA, only chain), but typically with a security related library you want to err on the side of caution.
Describe the solution you'd like
Default verify to verify_peer, and clear separation of ca for server/client certificates.
Additional context
You could e.g. imagine a http client (meant for http) being exposed to a user that specifies a https url giving them a false sense of security.
The text was updated successfully, but these errors were encountered: