server-specific SSL context configuration

[pitrou]

BPO	21013
Nosy	@pitrou, @tiran, @alex, @dstufft
Files	ssl-server-defaults.diff ssl-context-defaults-ssl3-diff ssl-context-defaults-ssl3-guards.diff

^{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:

assignee = None
closed_at = <Date 2015-04-13.19:02:56.500>
created_at = <Date 2014-03-21.19:07:46.089>
labels = ['type-feature', 'library']
title = 'server-specific SSL context configuration'
updated_at = <Date 2015-04-13.19:02:56.500>
user = 'https://github.com/pitrou'

bugs.python.org fields:

activity = <Date 2015-04-13.19:02:56.500>
actor = 'pitrou'
assignee = 'none'
closed = True
closed_date = <Date 2015-04-13.19:02:56.500>
closer = 'pitrou'
components = ['Library (Lib)']
creation = <Date 2014-03-21.19:07:46.089>
creator = 'pitrou'
dependencies = []
files = ['34569', '34577', '34590']
hgrepos = []
issue_num = 21013
keywords = ['patch']
message_count = 17.0
messages = ['214405', '214407', '214408', '214487', '214493', '214498', '214499', '214500', '214501', '214502', '214504', '214505', '214538', '214614', '214620', '214649', '214650']
nosy_count = 5.0
nosy_names = ['pitrou', 'christian.heimes', 'alex', 'python-dev', 'dstufft']
pr_nums = []
priority = 'normal'
resolution = 'fixed'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue21013'
versions = ['Python 3.4', 'Python 3.5']

[pitrou]

Currently, create_default_context() doesn't do anything special for server use. It seems the configuration could be improved, though:

• PROTOCOL_TLSv1 is suboptimal for servers: a "TLSv1" server can't accept a TLSv1.2 client, but a "SSLv23" server will; so we should use PROTOCOL_SSLv23 (!)

• we could enable ECDH by calling SSLContext.set_ecdh_curve(<something>)

[pitrou]

(also perhaps enable OP_CIPHER_SERVER_PREFERENCE, although it seems it could cause interoperability problems with some clients)

[dstufft]

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.

[dstufft]

Attached is a patch that:

• Switches the protocol to SSLv23 so that we can negotiate a TLS1.1 or TLS1.2 connection.
• Sets OP_CIPHER_SERVER_PREFERENCE for Purpose.CLIENT_AUTH so that our carefully selected cipher priority gives us better encryption and PFS
• Sets OP_SINGLE_DH_USE and OP_SINGLE_ECDH_USE for Purpose.CLIENT_AUTH to prevent re-use of the DH and ECDH keys in distinct sessions.

[pitrou]

(as an aside, Donald, perhaps you want to consider adding yourself to relevant topics in http://docs.python.org/devguide/experts.html )

[dstufft]

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?

[pitrou]

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,
so I'd say no.
Also, clients should always use the higher possible protocol version, so
I don't think security is at stake here.

[alex]

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.

[dstufft]

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.

See: https://crypto.stackexchange.com/questions/10493/why-is-tls-susceptible-to-protocol-downgrade-attacks

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.

[dstufft]

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?

[pitrou]

Well, I suppose IE6/XP is starting to look very old (though probably deployed quite widely), and TLS 1.0 was standardized in 1999.

[pitrou]

(by which I mean: ok, let's disable SSLv3)

[dstufft]

Attached is a new patch. It has:

• Switches the protocol to SSLv23 so that we can negotiate a TLS1.1 or TLS1.2 connection.
• Sets OP_CIPHER_SERVER_PREFERENCE for Purpose.CLIENT_AUTH so that our carefully selected cipher priority gives us better encryption and PFS
• Sets OP_SINGLE_DH_USE and OP_SINGLE_ECDH_USE for Purpose.CLIENT_AUTH to prevent re-use of the DH and ECDH keys in distinct sessions.
• Disables SSLv3 connections explicitly to match lower bounds of the original security of the created context
• Moves the "restricted" ciphers to only apply to servers. Servers can be much more picky about which ciphers they accept than clients can, and further more with how our ciphers are laid out now if RC4 is selected it is entirely the fault of the server we are connecting to.
• Document what the type of error message would be if a SSL 3.0 connection is required and how to re-enable it.