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
server-specific SSL context configuration #65212
Comments
Currently, create_default_context() doesn't do anything special for server use. It seems the configuration could be improved, though:
|
(also perhaps enable OP_CIPHER_SERVER_PREFERENCE, although it seems it could cause interoperability problems with some clients) |
Nah it should be fine to enable that, and it's preferable to do so. The server selects the cipher anyways in the TLS handshake. That just tells the server to prefer it's list for precedence and not the client list. |
Attached is a patch that:
|
(as an aside, Donald, perhaps you want to consider adding yourself to relevant topics in http://docs.python.org/devguide/experts.html ) |
I'll do that :) To be clear about this patch, it raises the upper bounds of security by enabling TLS 1.1, and 1.2 as well as the single use for (EC)DH and preferring the server ciphers. However it also lowers the lower bounds of security and includes SSLv3 which has some issues (see https://en.wikipedia.org/wiki/Transport_Layer_Security#SSL_3.0). However there exists clients who only support SSL3 (The primary one I'm aware of is IE6 on Windows XP). We can add OP_NO_SSLv3 to the default context to prevent SSL3 but it's sort of a situational thing. If you're doing something where you need SSL3 clients you don't want OP_NO_SSLv3. So I guess the question is, do we want to be more secure by default and *not* lower the lower bounds of security and require people to add context.options & ~ssl.OP_NO_SSLv3 if they want to support SSLv3 connections? |
Most people won't understand the symptoms if some clients can't connect, |
Unfortunately most TLS implementations (particularly those in browser stacks) are vulnerable to downgrade attacks, whereby an attacker can send some malicious packets to simulate a connection failure and cause a lower version of the protocol to be negotiated, https://crypto.stackexchange.com/questions/10493/why-is-tls-susceptible-to-protocol-downgrade-attacks has some info on it. As a result, whenever possible it's really desirable to completely disallow as many poor choices as possible. |
That's not entirely true unfortunately :( There are downgrade attacks that work all the way up through TLS 1.2. These are not strictly a problem of the protocol specs but instead of the implementations. The general gist of it is some servers/firewalls/etc have buggy implementations that cause a TLS1.0+ handshake to fail and some clients (browsers being a big one) decided to handle this by restarting the connection with SSL3.0 instead of TLS1.0+. So thus it is possible to effectively downgrade a client, even one that supports TLS1.2. It is not however possible to do it within a single connection. The version selection process should not be considered a security feature but should instead be looked at as a way to opportunistically add newer features. |
To be clear though, a lot of TLS servers out there still have SSL3.0 enabled by default, primarily because of IE6 / XP. I'm on the fence about what the right answer is for create_default_context. From a strictly "best practices for security" sense of view you want to disable SSLv3 (and this matches what create_default_context did prior to my patch). Can we perhaps split the difference and disable SSL3.0 and document what the error looks like when you try to connect with SSL3.0 and how to re-enable it? |
Well, I suppose IE6/XP is starting to look very old (though probably deployed quite widely), and TLS 1.0 was standardized in 1999. |
(by which I mean: ok, let's disable SSLv3) |
Attached is a new patch. It has:
|
I think I'm happy with this patch, if anyone has a chance to review it and see if it looks OK I'd love that and then I can commit it :) |
Added guards to protect against constants not existing. |
New changeset 92efd86d1a38 by Donald Stufft in branch '3.4': |
New changeset aa2eb034c4f7 by Donald Stufft in branch 'default': |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: