As of right now the default cipher list for the ssl module is DEFAULT:!aNULL:!eNULL:!LOW:!EXPORT:!SSLv2, additionally on Python 3.4 when you use create_default_context() then you also additionally get HIGH:!aNULL:!RC4:!DSS.

I think we should change this to the cipher string:

ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AESGCM:RSA+AES:RSA+3DES:!aNULL:!MD5:!DSS

This will:

* Prefer cipher suites that offer perfect forward secrecy (DHE/ECDHE)
* prefer ECDHE over DHE for better performance
* prefer any AES-GCM over any AES-CBC for better performance and security
* use 3DES as fallback which is secure but slow
* disable NULL authentication, MD5 MACs and DSS for security reasons

This cipher string is taken from urllib3 where it was compiled through the resources of:

* https://www.ssllabs.com/projects/best-practices/index.html
* https://hynek.me/articles/hardening-your-web-servers-ssl-ciphers/

The compatibility of this is pretty good. The only time this should cause a connection to *fail* is if a server is using an insecure cipher and in that case you can re-enable it by simply passing the original cipher list through the ssl.wrap_socket ciphers function.

I really don't think hardcoding specific ciphers is a good idea.

On 20.03.2014 15:11, Donald Stufft wrote:
> 
> The compatibility of this is pretty good. The only time this should cause a connection to *fail* is if a server is using an insecure cipher and in that case you can re-enable it by simply passing the original cipher list through the ssl.wrap_socket ciphers function.

Depends on who "you" is :-) Most of the time this will be the user of
some script or application with no clue as to how to change this or
what a cipher string is.

I think we should leave this decision to the OpenSSL lib vendors
and developers.

create_default_context is about best practices, though, so it seems to me it wouldn't be crazy to do it there.

> create_default_context is about best practices, though, so it seems to
> me it wouldn't be crazy to do it there.

Agreed, but the real problem here is maintenance. Hardcoding a list of
specific ciphers means someone must follow closely the introduction of
new ciphers in OpenSSL, and choose whether or not to include them in the
list.

I'd prefer an open-ended cipher string. Here is a proposal:
'ECDH:EDH:AESGCM:HIGH:!eNULL:!aNULL:!DSS'

It prioritizes Diffie-Hellman key exchange (for perfect forward
secrecy), and AESGCM for the symmetric cipher; it also lets OpenSSL
append other possible ciphers.

BTW, apparently removing RC4 prevents ECDHE in SSv23 mode: 

$ ./python -c 'import ssl, socket; ctx = ssl.SSLContext(ssl.PROTOCOL_SSLv23); ctx.set_ciphers("EECDH:EDH:AESGCM:HIGH:!eNULL:!aNULL");  s = ctx.wrap_socket(socket.socket()); s.connect(("linuxfr.org", 443)); print(s.cipher()); s.close()'
('ECDHE-RSA-RC4-SHA', 'TLSv1/SSLv3', 128)

$  ./python -c 'import ssl, socket; ctx = ssl.SSLContext(ssl.PROTOCOL_SSLv23); ctx.set_ciphers("EECDH:EDH:AESGCM:HIGH:!eNULL:!aNULL:!RC4");  s = ctx.wrap_socket(socket.socket()); s.connect(("linuxfr.org", 443)); print(s.cipher()); s.close()'
('DHE-RSA-AES256-SHA', 'TLSv1/SSLv3', 256)

That's because of the set of ciphersuites offered by the server (see https://www.ssllabs.com/ssltest/analyze.html?d=linuxfr.org), it's not an inevitable property of TLS. For example jenkins.cryptography.io (see https://www.ssllabs.com/ssltest/analyze.html?d=jenkins.cryptography.io) offers ECDHE suites without any RC4 at all.

Yea I noticed that, so I was doing some more testing, here's what I think we should be using (It Adds back in RC4):

ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AESGCM:RSA+AES:RSA+3DES:ECDH+RC4:DH+RC4:RSA+RC4!aNULL:!MD5:!DSS

This gives us everything that DEFAULT:!aNULL:!eNULL:!LOW:!EXPORT:!SSLv2 does except for the ciphers list here https://gist.github.com/dstufft/251dbeb8962e2182e668 on my OpenSSL 1.0.1f install.

Antoine, your cipher string priortizes ECDHE RC4 over DHE AES or even just plain AES. The string I'm proposing has been carefully crafted in order to get the ciphers in a very particular order. That order is basically - 1) Security of the cipher itself 2) PFS 3) Performance while also maintaining compatibility both forwards and backwards.

RC4 is in a precarious condition and it's use should be heavily discouraged. It is still required in some cases which is why my revised default cipher suggestion includes it, but at the end as a last fall back. At that point if RC4 gets selected it's the servers fault and the client did everything it could except refuse.

I still do believe that this should be the default ciphers while my original string should be the "restricted" ciphers that create_default_context() uses.

In terms of following closely, I'd be willing to encourage Red Hat's SRT to
keep an eye on this.

Another bit of maintenance here:

If a new cipher suite is added to OpenSSL it won' be generally available for a long while so very few if any services are going to be willing to depend on *only* it. For the very rare and unlikely case that somebody does setup a service that requires some brand new cipher they can override this list easily.

Using the default or the "wide" open strings are inherently more dangerous because of the wide range of OpenSSL's that are in production use. It's hard without auditing every version of OpenSSL to figure out what ciphers will be available in what circumstances. It also means that if OpenSSL adds a new cipher that ends up being insecure that it will be picked up automatically. Therefore the strings I've posted take the opinion that a whitelist is more secure than a blacklist and whitelist the cipher suites to a very specific set that happen to be best practices at this current time.

The only *required* maintenance would be if one of the selected ciphers are found to be insecure. However that was already a required maintenance because (again) of the wide range of OpenSSL versions available and the fact that these strings don't *add* any new ciphers, only remove some and create an explicit priority.

It's also worth noting that users appear to be FAR more likely to have an up to date Python than they are an up to date OpenSSL, meaning that if a change needs to be made, we're much better situated to get that disseminated to actual users than OpenSSL is

> The string I'm proposing has been carefully crafted in order to get 
> the ciphers in a very particular order. That order is basically - 1)
> Security of the cipher itself 2) PFS 3) Performance while also
> maintaining compatibility both forwards and backwards.

I still think the ciphers list should be open-ended, i.e. have "HIGH" somewhere at the end.

Why? At best users will get yet another secure algorithm and at worst they'll get an insecure algorithm.

See http://bugs.python.org/issue20995#msg214249

By the way:

> Using the default or the "wide" open strings are inherently more
> dangerous because of the wide range of OpenSSL's that are in
> production use. It's hard without auditing every version of OpenSSL to 
> figure out what ciphers will be available in what circumstances

This doesn't parse. If the system OpenSSL isn't maintained properly, it's not Python's job to workaround that. And we certainly don't have the required knowledge and dedication anyway.

> This doesn't parse. If the system OpenSSL isn't maintained properly, it's not Python's job to workaround that. And we certainly don't have the required knowledge and dedication anyway.

Please let's not have a repeat of https://bugs.ruby-lang.org/issues/9424, Python is in a better place to workaround that than anyone else.

> Please let's not have a repeat of
> https://bugs.ruby-lang.org/issues/9424, Python is in a better place to
> workaround that than anyone else.

Please stop the FUD. I proposed an alternative, how is it insecure
according according to you?

Oh and don't confuse me that I think Python's current situation is as bad as Ruby's was, but that attitude is dangerous and wrong :/

I'm still looking into what "HIGH" entails across all the various OpenSSLs that are in production that I can access. That "FUD" was responding to the attitude that it's not Python's job to do this. Python is exposing a security sensitive API, it is it's job.

On 20.03.2014 23:36, Donald Stufft wrote:
> 
> Donald Stufft added the comment:
> 
> I'm still looking into what "HIGH" entails across all the various OpenSSLs that are in production that I can access. That "FUD" was responding to the attitude that it's not Python's job to do this. Python is exposing a security sensitive API, it is it's job.

I disagree. Python only provides an interface to OpenSSL, so the OpenSSL
system defaults should be used.

Maintaining system security is an easier and more scalable approach than
trying to properly configure half a dozen sub-systems which happen to use
OpenSSL as basis for their SSL configuration. By forcing a specific
set of ciphers, we're breaking this approach.

By restricting the set of allowed ciphers you can also create the
situation that Python in its default configuration cannot talk to
certain web servers which use a different set of ciphers than the
one you are proposing.

We shouldn't do this in Python for the same reason we're not including
a predefined set of CA root certificates with the distribution.

On 20.03.2014 21:52, Alex Gaynor wrote:
> 
> It's also worth noting that users appear to be FAR more likely to have an up to date Python than they are an up to date OpenSSL, meaning that if a change needs to be made, we're much better situated to get that disseminated to actual users than OpenSSL is

This depends a lot on the type of users you're looking at. Corporate
users won't upgrade their Python version easily. They will happily
install patched OpenSSL versions.

> I disagree. Python only provides an interface to OpenSSL, so the OpenSSL
> system defaults should be used.

Python is already changing the OpenSSL defaults, also you're advocating that
Python should support 40bit encryption that can be brute forced in a matter of
days.

> Maintaining system security is an easier and more scalable approach than
> trying to properly configure half a dozen sub-systems which happen to use
> OpenSSL as basis for their SSL configuration. By forcing a specific
> set of ciphers, we're breaking this approach.

Again, Python is already forcing a set of ciphers. I don't know what sort of
Systems you use, but even RHEL 6.5 has *horrible* ciphers by in the OpenSSL
default set. Things like DES (not 3DES, DES) and 40bit RC4.

> By restricting the set of allowed ciphers you can also create the
> situation that Python in its default configuration cannot talk to
> certain web servers which use a different set of ciphers than the
> one you are proposing.

Of course, any restriction does that, that's not reason to also allow aNULL
or eNULL by default just because somewhere someone out there might be running
a server that only speaks them. Secure, Sane Defaults and the Ability to
override.

> We shouldn't do this in Python for the same reason we're not including
> a predefined set of CA root certificates with the distribution.

The difference here is that there are properly maintained alternatives to
Python including a predefined set of CA root certificates. This isn't the
case with OpenSSL. OpenSSL doesn't provide good defaults and I'm not aware of
a single OS which ships with OpenSSL that patches it to provide good defaults.

Python exposes this API, it's Python's job to properly secure it.

> Again, Python is already forcing a set of ciphers. I don't know what sort of
> Systems you use, but even RHEL 6.5 has *horrible* ciphers by in the OpenSSL
> default set. Things like DES (not 3DES, DES) and 40bit RC4.

I wonder why RedHat doesn't bother changing the defaults.
Did nobody ever report the issue to them, or are they more conservative
than we are?

> > Again, Python is already forcing a set of ciphers. I don't know what sort of
> > Systems you use, but even RHEL 6.5 has *horrible* ciphers by in the OpenSSL
> > default set. Things like DES (not 3DES, DES) and 40bit RC4.
> 
> I wonder why RedHat doesn't bother changing the defaults.
> Did nobody ever report the issue to them, or are they more conservative
> than we are?

I don't know why. Probably because the OpenSSL defaults are not intended to
be secure so OpenSSL is working as intended. The users of OpenSSL are intended
to use the cipher selection string to secure themselves.

Ok Antoine I've looked around.

Using a string like this:

ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AESGCM:RSA+AES:RSA+3DES:ECDH+RC4:DH+RC4:RSA+RC4:ECDH+HIGH:DH+HIGH:RSA+HIGH:!aNULL:!eNULL:!MD5:!DSS

The only *additional* ciphers that get added from the use of HIGH are various Camellia ciphers. These ciphers are not known to be insecure at this point in time so as of right now this is not an insecure cipher string.

However I still content that using HIGH in the cipherstring actually adds additional maintenance burden. In order to know if that cipherstring is still safe you must run it against every target OpenSSL you want to make secure to ensure that it doesn't allow a new cipher that doesn't meet the security strength that was attempted to be had with that cipherstring. If you use an explicit cipher string then you know exactly which cipher suites Python will use no matter what the OpenSSL claims is HIGH or not. This means that instead of having to monitor all the various OpenSSL versions for new ciphers you only have to periodically check that the suites that Python selected are still secure.

Remember the "failure" mode for not having a cipher in the list is that a different cipher is selected unless there are no other ciphers. A New cipher being added to OpenSSL is not going to be the only cipher available in any meaningful timeframe. The "failure" mode for having a bad cipher in the list is possibly making the users of Python insecure. That's why an explicit approach is preferred over an open ended approach. Because you don't have to audit a moving target.

Oh, additionally OpenSSL makes no promises what the meaning of "HIGH" will be in the future. So you can only look at what it means now and what it means in the past.

OpenSSL is not a good library and it's unfortunate that they don't attempt to make people secure by default.

Oh, Additionally Marc:

Even if some system administrator or some system out there does patch their OpenSSL to actually be safe by default Python changing it's cipher string only adds to the potential security (or at worst does nothing). If even one system (of which there are legion) does not do that patch then Python changing it's ciphers will protect that user.

The failure mode for a bad cipher is silent insecurity, the failure mode for not having a needed cipher is an obvious error.

> However I still content that using HIGH in the cipherstring actually
> adds additional maintenance burden. In order to know if that
> cipherstring is still safe you must run it against every target
> OpenSSL you want to make secure to ensure that it doesn't allow a new
> cipher that doesn't meet the security strength that was attempted to
> be had with that cipherstring.

I think that is a bit reverse. The main configuration point for ciphers
should be the server, not the client. We set a cipher string to guide
cipher selection in case the server lets us choose amongst its supported
ciphers, but that's all.

Besides, the ssl module doesn't promise a specific "security strength".
The defaults are a best effort thing, and paranoid people should
probably override the cipher string (and deal with the consequences).

> > However I still content that using HIGH in the cipherstring actually
> > adds additional maintenance burden. In order to know if that
> > cipherstring is still safe you must run it against every target
> > OpenSSL you want to make secure to ensure that it doesn't allow a new
> > cipher that doesn't meet the security strength that was attempted to
> > be had with that cipherstring.

> I think that is a bit reverse. The main configuration point for ciphers
> should be the server, not the client. We set a cipher string to guide
> cipher selection in case the server lets us choose amongst its supported
> ciphers, but that's all.

The Python ssl module is used for servers and clients. Ideally servers will
have prefer server ciphers on, but that doesn't always happen and providing
a modern level of security for end users is preferable. 

> Besides, the ssl module doesn't promise a specific "security strength".
> The defaults are a best effort thing, and paranoid people should
> probably override the cipher string (and deal with the consequences).

These are not things that affect only paranoid people and expecting someone
to even know what OpenSSL is much less how to configure it and what they want
to configure it to in order to get modern levels of security is backwards. The
danger for breakage here is *tiny*, *miniscule*, almost non existent and the
failure case is obvious and easy to fix.

> The Python ssl module is used for servers and clients. Ideally servers will
> have prefer server ciphers on, but that doesn't always happen and providing
> a modern level of security for end users is preferable. 

We should have specific defaults for servers in
create_default_context().

> The
> danger for breakage here is *tiny*, *miniscule*, almost non existent and the
> failure case is obvious and easy to fix.

Again: the point is maintenance later, not breakage now.

> Again: the point is maintenance later, not breakage now.

Ok, well I don't agree that it's more maintenance later to be explicit and not include HIGH, but whatever it's not insecure at the moment so.

Attached is a patch against 3.5 for folks to review.

On 21.03.2014 00:10, Donald Stufft wrote:
> 
>> We shouldn't do this in Python for the same reason we're not including
>> a predefined set of CA root certificates with the distribution.
> 
> The difference here is that there are properly maintained alternatives to
> Python including a predefined set of CA root certificates. This isn't the
> case with OpenSSL. OpenSSL doesn't provide good defaults and I'm not aware of
> a single OS which ships with OpenSSL that patches it to provide good defaults.
> 
> Python exposes this API, it's Python's job to properly secure it.

Perhaps I should have clarified this earlier on:
I agree to use such defaults for writing SSL servers in Python.
I disagree when it comes to SSL clients.

If we enforce a specific set of ciphers per default and a user finds
that a server he wants to communicate with for example only supports
RC4 ciphers, because that's the server admins were told to use after
the BEAST attack was found, the user most likely won't be able to
fix this.

So what's the net result: the scripts doesn't work, without any
way to get it back to work again. That's not more secure, it's
a failure :-)

IMO, Python should make SSL server code use best practices and make
it easy to alter the defaults. Python should also make sure that SSL
client code works using HIGH level ciphers, but not limit the
selection much further or make it more specific (apart from removing
completely broken features like e.g. MD5, aNULL, etc.).

If we want to enhance the user security, we should educate
our users about best practices and provide information on how
to implement them,

> > 
> >> We shouldn't do this in Python for the same reason we're not including
> >> a predefined set of CA root certificates with the distribution.
> > 
> > The difference here is that there are properly maintained alternatives to
> > Python including a predefined set of CA root certificates. This isn't the
> > case with OpenSSL. OpenSSL doesn't provide good defaults and I'm not aware of
> > a single OS which ships with OpenSSL that patches it to provide good defaults.
>>  
> > Python exposes this API, it's Python's job to properly secure it.

> Perhaps I should have clarified this earlier on:
> I agree to use such defaults for writing SSL servers in Python.
> I disagree when it comes to SSL clients.

Well Python is already doing that and Python should be doing that. OpenSSL
defaults are horrendous.

> > If we enforce a specific set of ciphers per default and a user finds
> > that a server he wants to communicate with for example only supports
> > RC4 ciphers, because that's the server admins were told to use after
> > the BEAST attack was found, the user most likely won't be able to
> > fix this.

Luckily my default cipher string still contains RC4 only the "restricted" best
practices one doesn't. Obviously this was only an example but the problem
you're arguing against doesn't exist in practice. The cipherstring I've posted
is largely similar to the one we already have except it removes a few other
ciphers that are either weak or unable to actually be used with the API of the
ssl module and it applies an explicit ordering in order to, in the cases the
server let's us pick, get the best cipher suite.

Let me repeat, this cipher string, compatability wise, is not that different
from what is *already* there and contains every moderately secure cipher that
is in use.

> So what's the net result: the scripts doesn't work, without any
> way to get it back to work again. That's not more secure, it's
> a failure :-)

You can get it back just by passing the ciphers keyword argument to the ssl
module.

> IMO, Python should make SSL server code use best practices and make
> it easy to alter the defaults. Python should also make sure that SSL
> client code works using HIGH level ciphers, but not limit the
> selection much further or make it more specific (apart from removing
> completely broken features like e.g. MD5, aNULL, etc.).

My cipherstring includes all HIGH ciphers and only explicitly excludes MD5,
aNULL, eNULL, and DSS.

> If we want to enhance the user security, we should educate
> our users about best practices and provide information on how
> to implement them,

Expecting users to properly configure a cipher string in order to get modern
best practices when Python itself can do it for practically zero difference
in compatibility is user hostile. In many cases those users are not even going
to be aware that they are using the ssl module or what OpenSSL even is. To be
perfectly honest this set will work with more servers than most browsers will
and browsers are typically the kings of bending over backwards not to ever
break SSL.

Updated the patch to change the priority slightly to ensure that all the secure PFS ciphers come first and that non PFS AES comes before the other Non PFS HIGH ciphers

On 21.03.2014 12:42, Donald Stufft wrote:
> 
>>> If we enforce a specific set of ciphers per default and a user finds
>>> that a server he wants to communicate with for example only supports
>>> RC4 ciphers, because that's the server admins were told to use after
>>> the BEAST attack was found, the user most likely won't be able to
>>> fix this.
> 
> Luckily my default cipher string still contains RC4 only the "restricted" best
> practices one doesn't. Obviously this was only an example but the problem
> you're arguing against doesn't exist in practice. The cipherstring I've posted
> is largely similar to the one we already have except it removes a few other
> ciphers that are either weak or unable to actually be used with the API of the
> ssl module and it applies an explicit ordering in order to, in the cases the
> server let's us pick, get the best cipher suite.

> Let me repeat, this cipher string, compatability wise, is not that different
> from what is *already* there and contains every moderately secure cipher that
> is in use.

Ok, here's a test to compare the outcome of your suggestion compared
to the defaults used in Python (which are basically the OpenSSL
defaults minus the broken parts). I've added !MD5 to the Python cipher
string, since that seems to be missing for some reason.

Here's the diff (taking order into account):

Using OpenSSL 1.0.1f 6 Jan 2014
---------------------------------------------------------------------------
--- standard.txt        2014-03-21 13:10:38.451648736 +0100
+++ donald.txt  2014-03-21 13:10:38.491649094 +0100
@@ -1,73 +1,51 @@
 ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AESGCM(256) Mac=AEAD
 ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AESGCM(256) Mac=AEAD
+ECDH-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH/RSA Au=ECDH Enc=AESGCM(256) Mac=AEAD
+ECDH-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AESGCM(256) Mac=AEAD
+ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AESGCM(128) Mac=AEAD
+ECDHE-ECDSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AESGCM(128) Mac=AEAD
+ECDH-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH/RSA Au=ECDH Enc=AESGCM(128) Mac=AEAD
+ECDH-ECDSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AESGCM(128) Mac=AEAD
+DHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=DH       Au=RSA  Enc=AESGCM(256) Mac=AEAD
+DHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=DH       Au=RSA  Enc=AESGCM(128) Mac=AEAD
 ECDHE-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AES(256)  Mac=SHA384
 ECDHE-ECDSA-AES256-SHA384 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AES(256)  Mac=SHA384
 ECDHE-RSA-AES256-SHA    SSLv3 Kx=ECDH     Au=RSA  Enc=AES(256)  Mac=SHA1
 ECDHE-ECDSA-AES256-SHA  SSLv3 Kx=ECDH     Au=ECDSA Enc=AES(256)  Mac=SHA1
-SRP-DSS-AES-256-CBC-SHA SSLv3 Kx=SRP      Au=DSS  Enc=AES(256)  Mac=SHA1
-SRP-RSA-AES-256-CBC-SHA SSLv3 Kx=SRP      Au=RSA  Enc=AES(256)  Mac=SHA1
-DHE-DSS-AES256-GCM-SHA384 TLSv1.2 Kx=DH       Au=DSS  Enc=AESGCM(256) Mac=AEAD
-DHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=DH       Au=RSA  Enc=AESGCM(256) Mac=AEAD
-DHE-RSA-AES256-SHA256   TLSv1.2 Kx=DH       Au=RSA  Enc=AES(256)  Mac=SHA256
-DHE-DSS-AES256-SHA256   TLSv1.2 Kx=DH       Au=DSS  Enc=AES(256)  Mac=SHA256
-DHE-RSA-AES256-SHA      SSLv3 Kx=DH       Au=RSA  Enc=AES(256)  Mac=SHA1
-DHE-DSS-AES256-SHA      SSLv3 Kx=DH       Au=DSS  Enc=AES(256)  Mac=SHA1
-DHE-RSA-CAMELLIA256-SHA SSLv3 Kx=DH       Au=RSA  Enc=Camellia(256) Mac=SHA1
-DHE-DSS-CAMELLIA256-SHA SSLv3 Kx=DH       Au=DSS  Enc=Camellia(256) Mac=SHA1
-ECDH-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH/RSA Au=ECDH Enc=AESGCM(256) Mac=AEAD
-ECDH-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AESGCM(256) Mac=AEAD
 ECDH-RSA-AES256-SHA384  TLSv1.2 Kx=ECDH/RSA Au=ECDH Enc=AES(256)  Mac=SHA384
 ECDH-ECDSA-AES256-SHA384 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AES(256)  Mac=SHA384
 ECDH-RSA-AES256-SHA     SSLv3 Kx=ECDH/RSA Au=ECDH Enc=AES(256)  Mac=SHA1
 ECDH-ECDSA-AES256-SHA   SSLv3 Kx=ECDH/ECDSA Au=ECDH Enc=AES(256)  Mac=SHA1
-AES256-GCM-SHA384       TLSv1.2 Kx=RSA      Au=RSA  Enc=AESGCM(256) Mac=AEAD
-AES256-SHA256           TLSv1.2 Kx=RSA      Au=RSA  Enc=AES(256)  Mac=SHA256
-AES256-SHA              SSLv3 Kx=RSA      Au=RSA  Enc=AES(256)  Mac=SHA1
-CAMELLIA256-SHA         SSLv3 Kx=RSA      Au=RSA  Enc=Camellia(256) Mac=SHA1
-PSK-AES256-CBC-SHA      SSLv3 Kx=PSK      Au=PSK  Enc=AES(256)  Mac=SHA1
-ECDHE-RSA-DES-CBC3-SHA  SSLv3 Kx=ECDH     Au=RSA  Enc=3DES(168) Mac=SHA1
-ECDHE-ECDSA-DES-CBC3-SHA SSLv3 Kx=ECDH     Au=ECDSA Enc=3DES(168) Mac=SHA1
-SRP-DSS-3DES-EDE-CBC-SHA SSLv3 Kx=SRP      Au=DSS  Enc=3DES(168) Mac=SHA1
-SRP-RSA-3DES-EDE-CBC-SHA SSLv3 Kx=SRP      Au=RSA  Enc=3DES(168) Mac=SHA1
-EDH-RSA-DES-CBC3-SHA    SSLv3 Kx=DH       Au=RSA  Enc=3DES(168) Mac=SHA1
-EDH-DSS-DES-CBC3-SHA    SSLv3 Kx=DH       Au=DSS  Enc=3DES(168) Mac=SHA1
-ECDH-RSA-DES-CBC3-SHA   SSLv3 Kx=ECDH/RSA Au=ECDH Enc=3DES(168) Mac=SHA1
-ECDH-ECDSA-DES-CBC3-SHA SSLv3 Kx=ECDH/ECDSA Au=ECDH Enc=3DES(168) Mac=SHA1
-DES-CBC3-SHA            SSLv3 Kx=RSA      Au=RSA  Enc=3DES(168) Mac=SHA1
-PSK-3DES-EDE-CBC-SHA    SSLv3 Kx=PSK      Au=PSK  Enc=3DES(168) Mac=SHA1
-ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AESGCM(128) Mac=AEAD
-ECDHE-ECDSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AESGCM(128) Mac=AEAD
+DHE-RSA-AES256-SHA256   TLSv1.2 Kx=DH       Au=RSA  Enc=AES(256)  Mac=SHA256
+DHE-RSA-AES256-SHA      SSLv3 Kx=DH       Au=RSA  Enc=AES(256)  Mac=SHA1
 ECDHE-RSA-AES128-SHA256 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AES(128)  Mac=SHA256
 ECDHE-ECDSA-AES128-SHA256 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AES(128)  Mac=SHA256
 ECDHE-RSA-AES128-SHA    SSLv3 Kx=ECDH     Au=RSA  Enc=AES(128)  Mac=SHA1
 ECDHE-ECDSA-AES128-SHA  SSLv3 Kx=ECDH     Au=ECDSA Enc=AES(128)  Mac=SHA1
-SRP-DSS-AES-128-CBC-SHA SSLv3 Kx=SRP      Au=DSS  Enc=AES(128)  Mac=SHA1
-SRP-RSA-AES-128-CBC-SHA SSLv3 Kx=SRP      Au=RSA  Enc=AES(128)  Mac=SHA1
-DHE-DSS-AES128-GCM-SHA256 TLSv1.2 Kx=DH       Au=DSS  Enc=AESGCM(128) Mac=AEAD
-DHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=DH       Au=RSA  Enc=AESGCM(128) Mac=AEAD
-DHE-RSA-AES128-SHA256   TLSv1.2 Kx=DH       Au=RSA  Enc=AES(128)  Mac=SHA256
-DHE-DSS-AES128-SHA256   TLSv1.2 Kx=DH       Au=DSS  Enc=AES(128)  Mac=SHA256
-DHE-RSA-AES128-SHA      SSLv3 Kx=DH       Au=RSA  Enc=AES(128)  Mac=SHA1
-DHE-DSS-AES128-SHA      SSLv3 Kx=DH       Au=DSS  Enc=AES(128)  Mac=SHA1
-DHE-RSA-SEED-SHA        SSLv3 Kx=DH       Au=RSA  Enc=SEED(128) Mac=SHA1
-DHE-DSS-SEED-SHA        SSLv3 Kx=DH       Au=DSS  Enc=SEED(128) Mac=SHA1
-DHE-RSA-CAMELLIA128-SHA SSLv3 Kx=DH       Au=RSA  Enc=Camellia(128) Mac=SHA1
-DHE-DSS-CAMELLIA128-SHA SSLv3 Kx=DH       Au=DSS  Enc=Camellia(128) Mac=SHA1
-ECDH-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH/RSA Au=ECDH Enc=AESGCM(128) Mac=AEAD
-ECDH-ECDSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AESGCM(128) Mac=AEAD
 ECDH-RSA-AES128-SHA256  TLSv1.2 Kx=ECDH/RSA Au=ECDH Enc=AES(128)  Mac=SHA256
 ECDH-ECDSA-AES128-SHA256 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AES(128)  Mac=SHA256
 ECDH-RSA-AES128-SHA     SSLv3 Kx=ECDH/RSA Au=ECDH Enc=AES(128)  Mac=SHA1
 ECDH-ECDSA-AES128-SHA   SSLv3 Kx=ECDH/ECDSA Au=ECDH Enc=AES(128)  Mac=SHA1
+DHE-RSA-AES128-SHA256   TLSv1.2 Kx=DH       Au=RSA  Enc=AES(128)  Mac=SHA256
+DHE-RSA-AES128-SHA      SSLv3 Kx=DH       Au=RSA  Enc=AES(128)  Mac=SHA1
+ECDHE-RSA-DES-CBC3-SHA  SSLv3 Kx=ECDH     Au=RSA  Enc=3DES(168) Mac=SHA1
+ECDHE-ECDSA-DES-CBC3-SHA SSLv3 Kx=ECDH     Au=ECDSA Enc=3DES(168) Mac=SHA1
+ECDH-RSA-DES-CBC3-SHA   SSLv3 Kx=ECDH/RSA Au=ECDH Enc=3DES(168) Mac=SHA1
+ECDH-ECDSA-DES-CBC3-SHA SSLv3 Kx=ECDH/ECDSA Au=ECDH Enc=3DES(168) Mac=SHA1
+DHE-RSA-CAMELLIA256-SHA SSLv3 Kx=DH       Au=RSA  Enc=Camellia(256) Mac=SHA1
+EDH-RSA-DES-CBC3-SHA    SSLv3 Kx=DH       Au=RSA  Enc=3DES(168) Mac=SHA1
+DHE-RSA-CAMELLIA128-SHA SSLv3 Kx=DH       Au=RSA  Enc=Camellia(128) Mac=SHA1
+AES256-GCM-SHA384       TLSv1.2 Kx=RSA      Au=RSA  Enc=AESGCM(256) Mac=AEAD
 AES128-GCM-SHA256       TLSv1.2 Kx=RSA      Au=RSA  Enc=AESGCM(128) Mac=AEAD
+AES256-SHA256           TLSv1.2 Kx=RSA      Au=RSA  Enc=AES(256)  Mac=SHA256
+AES256-SHA              SSLv3 Kx=RSA      Au=RSA  Enc=AES(256)  Mac=SHA1
 AES128-SHA256           TLSv1.2 Kx=RSA      Au=RSA  Enc=AES(128)  Mac=SHA256
 AES128-SHA              SSLv3 Kx=RSA      Au=RSA  Enc=AES(128)  Mac=SHA1
-SEED-SHA                SSLv3 Kx=RSA      Au=RSA  Enc=SEED(128) Mac=SHA1
+CAMELLIA256-SHA         SSLv3 Kx=RSA      Au=RSA  Enc=Camellia(256) Mac=SHA1
+DES-CBC3-SHA            SSLv3 Kx=RSA      Au=RSA  Enc=3DES(168) Mac=SHA1
 CAMELLIA128-SHA         SSLv3 Kx=RSA      Au=RSA  Enc=Camellia(128) Mac=SHA1
-PSK-AES128-CBC-SHA      SSLv3 Kx=PSK      Au=PSK  Enc=AES(128)  Mac=SHA1
 ECDHE-RSA-RC4-SHA       SSLv3 Kx=ECDH     Au=RSA  Enc=RC4(128)  Mac=SHA1
 ECDHE-ECDSA-RC4-SHA     SSLv3 Kx=ECDH     Au=ECDSA Enc=RC4(128)  Mac=SHA1
 ECDH-RSA-RC4-SHA        SSLv3 Kx=ECDH/RSA Au=ECDH Enc=RC4(128)  Mac=SHA1
 ECDH-ECDSA-RC4-SHA      SSLv3 Kx=ECDH/ECDSA Au=ECDH Enc=RC4(128)  Mac=SHA1
 RC4-SHA                 SSLv3 Kx=RSA      Au=RSA  Enc=RC4(128)  Mac=SHA1
-PSK-RC4-SHA             SSLv3 Kx=PSK      Au=PSK  Enc=RC4(128)  Mac=SHA1

Here's the same diff but using sorted order, so only showing ciphers
that were added/removed:

Sorted diff:
--- standard-sorted.txt 2014-03-21 13:17:14.307181546 +0100
+++ donald-sorted.txt   2014-03-21 13:17:14.307181546 +0100
@@ -5,28 +5,18 @@ AES256-GCM-SHA384       TLSv1.2 Kx=RSA
 AES256-SHA256           TLSv1.2 Kx=RSA      Au=RSA  Enc=AES(256)  Mac=SHA256
 AES256-SHA              SSLv3 Kx=RSA      Au=RSA  Enc=AES(256)  Mac=SHA1
 CAMELLIA128-SHA         SSLv3 Kx=RSA      Au=RSA  Enc=Camellia(128) Mac=SHA1
 CAMELLIA256-SHA         SSLv3 Kx=RSA      Au=RSA  Enc=Camellia(256) Mac=SHA1
 DES-CBC3-SHA            SSLv3 Kx=RSA      Au=RSA  Enc=3DES(168) Mac=SHA1
-DHE-DSS-AES128-GCM-SHA256 TLSv1.2 Kx=DH       Au=DSS  Enc=AESGCM(128) Mac=AEAD
-DHE-DSS-AES128-SHA256   TLSv1.2 Kx=DH       Au=DSS  Enc=AES(128)  Mac=SHA256
-DHE-DSS-AES128-SHA      SSLv3 Kx=DH       Au=DSS  Enc=AES(128)  Mac=SHA1
-DHE-DSS-AES256-GCM-SHA384 TLSv1.2 Kx=DH       Au=DSS  Enc=AESGCM(256) Mac=AEAD
-DHE-DSS-AES256-SHA256   TLSv1.2 Kx=DH       Au=DSS  Enc=AES(256)  Mac=SHA256
-DHE-DSS-AES256-SHA      SSLv3 Kx=DH       Au=DSS  Enc=AES(256)  Mac=SHA1
-DHE-DSS-CAMELLIA128-SHA SSLv3 Kx=DH       Au=DSS  Enc=Camellia(128) Mac=SHA1
-DHE-DSS-CAMELLIA256-SHA SSLv3 Kx=DH       Au=DSS  Enc=Camellia(256) Mac=SHA1
-DHE-DSS-SEED-SHA        SSLv3 Kx=DH       Au=DSS  Enc=SEED(128) Mac=SHA1
 DHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=DH       Au=RSA  Enc=AESGCM(128) Mac=AEAD
 DHE-RSA-AES128-SHA256   TLSv1.2 Kx=DH       Au=RSA  Enc=AES(128)  Mac=SHA256
 DHE-RSA-AES128-SHA      SSLv3 Kx=DH       Au=RSA  Enc=AES(128)  Mac=SHA1
 DHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=DH       Au=RSA  Enc=AESGCM(256) Mac=AEAD
 DHE-RSA-AES256-SHA256   TLSv1.2 Kx=DH       Au=RSA  Enc=AES(256)  Mac=SHA256
 DHE-RSA-AES256-SHA      SSLv3 Kx=DH       Au=RSA  Enc=AES(256)  Mac=SHA1
 DHE-RSA-CAMELLIA128-SHA SSLv3 Kx=DH       Au=RSA  Enc=Camellia(128) Mac=SHA1
 DHE-RSA-CAMELLIA256-SHA SSLv3 Kx=DH       Au=RSA  Enc=Camellia(256) Mac=SHA1
-DHE-RSA-SEED-SHA        SSLv3 Kx=DH       Au=RSA  Enc=SEED(128) Mac=SHA1
 ECDH-ECDSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AESGCM(128) Mac=AEAD
 ECDH-ECDSA-AES128-SHA256 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AES(128)  Mac=SHA256
 ECDH-ECDSA-AES128-SHA   SSLv3 Kx=ECDH/ECDSA Au=ECDH Enc=AES(128)  Mac=SHA1
 ECDH-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AESGCM(256) Mac=AEAD
 ECDH-ECDSA-AES256-SHA384 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AES(256)  Mac=SHA384
@@ -55,19 +45,7 @@ ECDH-RSA-AES128-SHA     SSLv3 Kx=ECDH/RS
 ECDH-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH/RSA Au=ECDH Enc=AESGCM(256) Mac=AEAD
 ECDH-RSA-AES256-SHA384  TLSv1.2 Kx=ECDH/RSA Au=ECDH Enc=AES(256)  Mac=SHA384
 ECDH-RSA-AES256-SHA     SSLv3 Kx=ECDH/RSA Au=ECDH Enc=AES(256)  Mac=SHA1
 ECDH-RSA-DES-CBC3-SHA   SSLv3 Kx=ECDH/RSA Au=ECDH Enc=3DES(168) Mac=SHA1
 ECDH-RSA-RC4-SHA        SSLv3 Kx=ECDH/RSA Au=ECDH Enc=RC4(128)  Mac=SHA1
-EDH-DSS-DES-CBC3-SHA    SSLv3 Kx=DH       Au=DSS  Enc=3DES(168) Mac=SHA1
 EDH-RSA-DES-CBC3-SHA    SSLv3 Kx=DH       Au=RSA  Enc=3DES(168) Mac=SHA1
-PSK-3DES-EDE-CBC-SHA    SSLv3 Kx=PSK      Au=PSK  Enc=3DES(168) Mac=SHA1
-PSK-AES128-CBC-SHA      SSLv3 Kx=PSK      Au=PSK  Enc=AES(128)  Mac=SHA1
-PSK-AES256-CBC-SHA      SSLv3 Kx=PSK      Au=PSK  Enc=AES(256)  Mac=SHA1
-PSK-RC4-SHA             SSLv3 Kx=PSK      Au=PSK  Enc=RC4(128)  Mac=SHA1
 RC4-SHA                 SSLv3 Kx=RSA      Au=RSA  Enc=RC4(128)  Mac=SHA1
-SEED-SHA                SSLv3 Kx=RSA      Au=RSA  Enc=SEED(128) Mac=SHA1
-SRP-DSS-3DES-EDE-CBC-SHA SSLv3 Kx=SRP      Au=DSS  Enc=3DES(168) Mac=SHA1
-SRP-DSS-AES-128-CBC-SHA SSLv3 Kx=SRP      Au=DSS  Enc=AES(128)  Mac=SHA1
-SRP-DSS-AES-256-CBC-SHA SSLv3 Kx=SRP      Au=DSS  Enc=AES(256)  Mac=SHA1
-SRP-RSA-3DES-EDE-CBC-SHA SSLv3 Kx=SRP      Au=RSA  Enc=3DES(168) Mac=SHA1
-SRP-RSA-AES-128-CBC-SHA SSLv3 Kx=SRP      Au=RSA  Enc=AES(128)  Mac=SHA1
-SRP-RSA-AES-256-CBC-SHA SSLv3 Kx=SRP      Au=RSA  Enc=AES(256)  Mac=SHA1

It shows the effect of the additional !DSS - which I don't understand;
DSA is part of the X.509 standard, so it's removing support will break
compatibility. Could you perhaps explain you're reasoning ?

It also shows that by removing DEFAULT, you are not allowing other
ciphers.

PSK and SRP are not likely to be used by web servers. SEED doesn't appear
to have wide spread use either, so leaving it out probably won't matter.
Leaving those in doesn't hurt either.

So modulo the DSS question I see your point about compatibility :-)

Still, OpenSSL might add more ciphers or modes in the future
and you'd automatically get those by using DEFAULT in the cipher
string, so I'd opt for just adding !MD5 to the default cipher list,
i.e.

DEFAULT:!aNULL:!eNULL:!MD5:!LOW:!EXPORT:!SSLv2

With such a string, both servers and client get good compatibility,
while keeping Python users reasonably safe per default and
keeping the maintenance burden out of Python.

> It shows the effect of the additional !DSS - which I don't understand;
> DSA is part of the X.509 standard, so it's removing support will break
> compatibility. Could you perhaps explain you're reasoning ?

Well DSA has problems with weak RNGs and consequently no CA that I'm aware of
will even issue a DSS cert and I've never seen nor heard of anyone actually
using them in practice. If it makes you feel better I can add DSS back in.

> It also shows that by removing DEFAULT, you are not allowing other
> ciphers.

> PSK and SRP are not likely to be used by web servers. SEED doesn't appear
> to have wide spread use either, so leaving it out probably won't matter.
> Leaving those in doesn't hurt either.

I'm pretty sure you can't even use PSK or SRP using the stdlib ssl module, I
didn't explicitly exclude them though. It's just a side effect of specifying
ECDH, DH, and RSA explicitly.

> So modulo the DSS question I see your point about compatibility :-)

I've uploaded a new patch that removes the !DSS from the default ciphers.

Here's the diff from the original default string (with the added !MD5) and
my new patch's default string

> DHE-DSS-SEED-SHA        SSLv3 Kx=DH       Au=DSS  Enc=SEED(128) Mac=SHA1
> DHE-RSA-SEED-SHA        SSLv3 Kx=DH       Au=RSA  Enc=SEED(128) Mac=SHA1
> IDEA-CBC-SHA            SSLv3 Kx=RSA      Au=RSA  Enc=IDEA(128) Mac=SHA1
> PSK-3DES-EDE-CBC-SHA    SSLv3 Kx=PSK      Au=PSK  Enc=3DES(168) Mac=SHA1
> PSK-AES128-CBC-SHA      SSLv3 Kx=PSK      Au=PSK  Enc=AES(128)  Mac=SHA1
> PSK-AES256-CBC-SHA      SSLv3 Kx=PSK      Au=PSK  Enc=AES(256)  Mac=SHA1
> PSK-RC4-SHA             SSLv3 Kx=PSK      Au=PSK  Enc=RC4(128)  Mac=SHA1
> SEED-SHA                SSLv3 Kx=RSA      Au=RSA  Enc=SEED(128) Mac=SHA1
> SRP-DSS-3DES-EDE-CBC-SHA SSLv3 Kx=SRP      Au=DSS  Enc=3DES(168) Mac=SHA1
> SRP-DSS-AES-128-CBC-SHA SSLv3 Kx=SRP      Au=DSS  Enc=AES(128)  Mac=SHA1
> SRP-DSS-AES-256-CBC-SHA SSLv3 Kx=SRP      Au=DSS  Enc=AES(256)  Mac=SHA1
> SRP-RSA-3DES-EDE-CBC-SHA SSLv3 Kx=SRP      Au=RSA  Enc=3DES(168) Mac=SHA1
> SRP-RSA-AES-128-CBC-SHA SSLv3 Kx=SRP      Au=RSA  Enc=AES(128)  Mac=SHA1
> SRP-RSA-AES-256-CBC-SHA SSLv3 Kx=SRP      Au=RSA  Enc=AES(256)  Mac=SHA1

> Still, OpenSSL might add more ciphers or modes in the future
> and you'd automatically get those by using DEFAULT in the cipher
> string, so I'd opt for just adding !MD5 to the default cipher list,
> i.e.

> DEFAULT:!aNULL:!eNULL:!MD5:!LOW:!EXPORT:!SSLv2

> With such a string, both servers and client get good compatibility,
> while keeping Python users reasonably safe per default and
> keeping the maintenance burden out of Python.

The (newly uploaded) cipher string is still better because it includes a
priority that is import. It prioritizes:

PFS > Non PFS but Secure > Non PFS Secure Slow > Security Problematic but for Compatibility

This is important especially in the modern age of bulk data collection. It will
still pick up new HIGH ciphers added by OpenSSL without any changes made to
Python itself. This is better than a blacklist approach because it'd be easy
for OpenSSL to add something else bad to DEFAULT that didn't get caught by
!aNULL:!eNULL:!MD5:!LOW:!EXPORT:!SSLv2.

I think the proposed cipher string is still overly complicated and tedious to maintain. The following seems to achieve similar results:

'EECDH+AESGCM:DH+AESGCM:ECDH:DH:HIGH:!aNULL:!eNULL:!MD5:!DSS:!LOW:!EXPORT'

Also, as Marc-André points out, we probably shouldn't ban RC4 even from the so-called "restricted ciphers".

> I'm pretty sure you can't even use PSK or SRP using the stdlib ssl
> module, I
> didn't explicitly exclude them though.

This is true. There are issues open, though: issue 11943 and issue 19084.

(oh, I missed the part where Marc-André suggested not to drop DSS; this should also be removed from my cipher string proposal)

As I said earlier Antoine, doing that puts PFS RC4 before non PFS AES. That isn't good because RC4 key stream bias makes it extremely fragile. RC4 needs to be in the default ciphers for compatibility sake but it should be dead last so that it's only used as a last ditch effort because it should *not* be considered generally secure anymore.

With regard to PSK and SRP. Seeing as how Python doesn't currently support them, SRP had a patch that hasn't been worked on since 2011 and PSK doesn't have a patch at all that this cipher string shouldn't concern itself with something that Python might someday in the future gain support for.

If someone comes along and adds PSK or SRP support they can adjust the cipher string in that patch, probably by adding the PSK or SRP ciphers conditionally when the parameters that are required for those ciphers are passed into wrap_socket, or maybe just all the time. Point being it shouldn't be a consideration now as adding it later is simple.

> With regard to PSK and SRP. Seeing as how Python doesn't currently
support them, SRP had a patch that hasn't been worked on since 2011 and
PSK doesn't have a patch at all that this cipher string shouldn't
concern itself with something that Python might someday in the future
gain support for.

I didn't say otherwise.

Yup :) Just being explicit in that!

Ok, so I think the latest patch is mostly good but I don't understand why the "restricted ciphers" (again, misnomer) would ban RC4 (and DSS?). These are the ciphers used by higher-level client libs, and connection failures will confuse the hell out of people.

Note: The RC4 and DSS exclusion existed previously on the restricted ciphers so we'd have to ask Christian why he did that. For me personally the restricted ciphers are intended to be best practice ciphers and that means no RC4. DSS here I'm kind of meh about the same way I was for the default ciphers. DSA has historically had problems with weak RNGs and as far as I'm aware no CA's actually issue DSS certificates. But I mostly left !DSS in the restricted set because Christian had it in originally.

This might be a case where to really do "best practices" we need to diverge between client and server. For a server I definitely think putting RC4 in the cipher string is a bad thing. For clients it is not the greatest thing but it more closely matches what browsers do because there are a few services here and there which only expose RC4.

Forgot to add! If you think splitting between "restricted" server and client ciphers I can split them like that and upload a new patch.

> Forgot to add! If you think splitting between "restricted" server and
> client ciphers I can split them like that and upload a new patch.

I was about to open a separate issue for the server side. How about
restricting this issue to client usage?

Not sure what you mean by client issue. Do you mean to keep RC4?

Which "client issue"? Sorry, I've lost track :-)

Er, I typed issue and meant usage. Right now the only difference between restricted ciphers and the default ciphers is restricted ciphers have no RC4 and no DSS. You wanted this issue limited to client changes and I'm not sure how to do that without enabling RC4/DSS for servers (which is a regression in the security of the restricted ciphers).

I think if we want to make restricted ciphers apply only for servers that's OK but as this ticket doesn't change the restrictions (other than omitting SRP/PSK and SEED/IDEA) that there's no changes to be made here, it should be accepted and then another ticket for restricting the restricted ciphers to servers only? Or what did you have in mind?

> Er, I typed issue and meant usage. Right now the only difference
> between restricted ciphers and the default ciphers is restricted
> ciphers have no RC4 and no DSS. You wanted this issue limited to
> client changes and I'm not sure how to do that without enabling
> RC4/DSS for servers (which is a regression in the security of the
> restricted ciphers).

Hmm, fair enough, let's change them all at once here. Also, since
"restricted ciphers" aren't actually used by stdlib modules, I changed
my mind and think it's ok to disable RC4 and DSS :-)

I'll still open another issue for server-specific configuration: not the
ciphers, but other stuff.

Shall we commit the new string for 3.5 for the time being? I'm currently working on a PEP to help define a policy for dealing with network security related issues/enhancements in maintenance branches, so I don't think we should touch those until we have that discussion on python-dev and get an explicit direction from Guido.

(for the record and for the sake of comparison, Postfix's "high" security setting is "ALL:!EXPORT:!LOW:!MEDIUM:+RC4:@STRENGTH")

The patch will also need updating the "Cipher selection" paragraph in ssl.rst, I think.

I can add that.

Hmm, I'm not sure what needs updated. The docs only say that ssl module disabled certain weak ciphers by default which is still the case. Was there some specific place or wording you were looking for?

Well, the doc currently says:

"""Starting from Python 3.2.3, the
ssl module disables certain weak ciphers by default, but you may want
to further restrict the cipher choice.  For example::

   context = ssl.SSLContext(ssl.PROTOCOL_TLSv1)
   context.set_ciphers('HIGH:!aNULL:!eNULL')"""

But after your changes, calling set_ciphers('HIGH:!aNULL:!eNULL') will actually weaken security, so this example should simply be removed (IMHO).

Ah yes, I skipped over that looking for a place where we were detailing what ciphers were picked. Ok Thanks!

Added the docs changes

New changeset e9749a7aa958 by Donald Stufft in branch '3.4':
Issue #20995: Enhance default ciphers used by the ssl module
http://hg.python.org/cpython/rev/e9749a7aa958

New changeset 60f696488c4f by Donald Stufft in branch 'default':
Merge changes from 3.4 to bring in fixes for Issue #20995
http://hg.python.org/cpython/rev/60f696488c4f

New changeset 869277faf3dc by Antoine Pitrou in branch '3.4':
Issue #21015: SSL contexts will now automatically select an elliptic curve for ECDH key exchange on OpenSSL 1.0.2 and later, and otherwise default to "prime256v1".
http://hg.python.org/cpython/rev/869277faf3dc

New changeset 3b81d1b3f9d1 by Antoine Pitrou in branch 'default':
Issue #21015: SSL contexts will now automatically select an elliptic curve for ECDH key exchange on OpenSSL 1.0.2 and later, and otherwise default to "prime256v1".
http://hg.python.org/cpython/rev/3b81d1b3f9d1

The buildbot failures should have been fixed by #21015, should we close this one?

Yes

The cipher strings rely too much on AES for my taste. Imagine that ChaCha20Poly1305 or any other strong cipher suite is introduced to OpenSSL in the future.

Enabling using general, and demoting using narrow terms, seems IMHO a better approach. For example:

    ECDH+HIGH:DH+HIGH:!aNULL:!MD5:!RC4:-3DES:HIGH

The cipher string includes HIGH, so if ChaCha20Poly1305 or another cipher suite is added to OpenSSL it'll get included in the cipher string by default.

So the major difference of what you suggest would be no longer prioritizing ciphers. However I would argue that would be bad. The priority exists so that we get the best possible cipher is as many situations as we possibly can. It doesn't mean that we'll get the best possible cipher in *every* single situation, but generally we will.

To this ends it prioritizes:
    * PFS with a secure cipher over everything else (Your string would do this as well)
    * After that prefer ECDHE over DHE
    * After that, prefer AES-GCM
    * After that, prefer AES-CBC
    * After that, any other HIGH cipher
    * After that, 3DES
    * After that, any use of RC4 including those with PFS

So if OpenSSL added ChaCha20Poly1305 it would fit into the priority after AES-GCM and AES-CBC. 

For any device that has hardware support for AES (AES-NI) AES-GCM is hands down a better choice of cipher. It is secure, has no issues in the spec itself, and it is *fast*, like 900MB/s for AES-128-GCM on a Sandy Bridge Xeon w/ AES-NI (ChaCha20Poly1305 got 500MB/s on the same hardware, however it is a 256bit cipher will AES-128-GCM is a 128 bit cipher). Using ChaCha20 on those devices would be a worse choice than AES-GCM.

However on lower powered devices, such  as smart phones, especially those without hardware support for AES, ChaCha20 really shines. A Galaxy Nexus can do AES-256-GCM at 20MB/s whereas it can do ChaCha20Poly1305 at 92MB/s (same phone).

So in an ideal world, assuming ChaCha20 was implemented in OpenSSL, we'd adjust the default cipher string based on the hardware they are running on. However since we don't have the ability to do that then preferring AES (which we know on some systems will be much faster) over an unknown future cipher (which we have no knowledge of if it will be faster or not) is a much more reasonable choice. If at some point in the future OpenSSL gains ChaCha20Poly1305 support then these strings should probably change to put ChaCha20Poly1305 in between AES-GCM and AES-CBC because on any given the system the likelyhood that you want AES-GCM is still higher than ChaCha20, but the likelyhood you want ChaCha20 over AES-CBC is greater.

It's also important to note that the server in any TLS communication is the end that picks exactly which cipher we select. Ideally all servers will be configured to have the strongest cipher first, and to prefer their own cipher order. In that case for the *client* side of a TLS connection the order of the ciphers doesn't matter and thus your string vs the implemented string has no difference in behavior. However if the server doesn't enforce their own preference for ciphers, then the difference will be that an undefined cipher will be selected (could be AESGCM, AESCBC, ChaCha20, or Camellia). On the server side of this, if you're using Python to terminate your TLS on the server side, the likelyhood that a server is running on a low powered device where the benefits of ChaCha20Poly1305 are the highest are pretty low and preferring AES-GCM is an even safer idea.

> For any device that has hardware support for AES (AES-NI) AES-GCM is
> hands down a better choice of cipher. It is secure, has no issues in
> the spec itself, and it is *fast*, like 900MB/s for AES-128-GCM on a
> Sandy Bridge Xeon w/ AES-NI (ChaCha20Poly1305 got 500MB/s on the same
> hardware, however it is a 256bit cipher will AES-128-GCM is a 128 bit
> cipher). Using ChaCha20 on those devices would be a worse choice than
> AES-GCM.

I think performance isn't really relevant, except perhaps on very busy
servers. A smartphone acting as a *client* certainly shouldn't need to
download 20 MB/s of encrypted data.

> I think performance isn't really relevant, except perhaps on very busy
> servers. A smartphone acting as a *client* certainly shouldn't need to
> download 20 MB/s of encrypted data.

Well, if you factor out performance then ChaCha20Poly1305 and AES-GCM are more
or less equivalent in preference with AES-CBC still less than either of them
because of problematic construction choices in the TLS spec. If you factor
out performance completely there is maybe a slight preference for
ChaCha20Poly1305 over AES-GCM simply because AES-GCM is hard to implement in
a timing safe way in software. However that discussion is mostly academic as
right now ChaCha20Poly1305 is not available in OpenSSL.

In general I agree that the performance of all of these are "good enough" that
the average user of this API won't be able to tell the difference, however
there is no cost to selecting the generally more performant of the two so I
think it still makes sense to consider it.

Hopefully what I was trying to achieve was provide some more context for markk so he'd hopefully be able to better understand why the string cipher calls out AES specifically before falling back to HIGH.

Thanks for the detailed insight, Donald! And I certainly love the progress these changes here bring. :-)

Perhaps limiting the scope to ChaCha20Poly1305 (»CCP«) has been a wrong approach of mine to explain my concerns:

We should not refer to any particular cipher in those lists, and by that avoid to revisit the defaults at any point in the future.

0. Properties of any cipher to come are known to the makers of OpenSSL first.
1. Python shouldn't duplicate the work of ordering ciphers, which is already done by OpenSSL.
2. … especially because it is unknown which ciphers a user's OpenSSL does actually implement (Is EC present? CCP? HC-256 or HC-128? WIERZA? Rabbit? NTRU…) or will implement in the future.
3. Whether a cipher is regarded as more secure than another depends on its implementation, too. The implementors are better judges of that, and hence ordering should done by them and could vary between versions [e.g., of OpenSSL].
4. Given our experiences with Python 2.7 I'd like to argue that there is reluctance to upgrading existing installations and its cipher suite strings. ;-)

But we know from experience with already established ciphers if and when to demote them.

That said I don't insist on any changes.

It would be great if we could rely on OpenSSL's ordering. It would be seriously fantastic. OpenSSL is best positioned to be able to do the right things, it's updated at the right times. It should be where we do this.

Unfortunately the OpenSSL maintainers have utterly abdicated any responsibility for helping secure users, and has gone with poor defaults, obligating us to fill the hole.