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:!DSSThis 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 reasonsThis 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 ofsome script or application with no clue as to how to change this orwhat a cipher string is.I think we should leave this decision to the OpenSSL lib vendorsand 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 ofspecific ciphers means someone must follow closely the introduction ofnew ciphers in OpenSSL, and choose whether or not to include them in thelist.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 forwardsecrecy), and AESGCM for the symmetric cipher; it also lets OpenSSLappend 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 (seehttps://www.ssllabs.com/ssltest/analyze.html?d=linuxfr.org), it's not an inevitable property of TLS. For example jenkins.cryptography.io (seehttps://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:!DSSThis gives us everything that DEFAULT:!aNULL:!eNULL:!LOW:!EXPORT:!SSLv2 does except for the ciphers list herehttps://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 tokeep 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.

Seehttp://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 circumstancesThis 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 ofhttps://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 insecureaccording 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 OpenSSLsystem defaults should be used.Maintaining system security is an easier and more scalable approach thantrying to properly configure half a dozen sub-systems which happen to useOpenSSL as basis for their SSL configuration. By forcing a specificset of ciphers, we're breaking this approach.By restricting the set of allowed ciphers you can also create thesituation that Python in its default configuration cannot talk tocertain web servers which use a different set of ciphers than theone you are proposing.We shouldn't do this in Python for the same reason we're not includinga 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 isThis depends a lot on the type of users you're looking at. Corporateusers won't upgrade their Python version easily. They will happilyinstall 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 thatPython should support 40bit encryption that can be brute forced in a matter ofdays.> 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 ofSystems you use, but even RHEL 6.5 has *horrible* ciphers by in the OpenSSLdefault 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 aNULLor eNULL by default just because somewhere someone out there might be runninga server that only speaks them. Secure, Sane Defaults and the Ability tooverride.> 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 toPython including a predefined set of CA root certificates. This isn't thecase with OpenSSL. OpenSSL doesn't provide good defaults and I'm not aware ofa 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 conservativethan 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 tobe secure so OpenSSL is working as intended. The users of OpenSSL are intendedto 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:!DSSThe 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 ciphersshould be the server, not the client. We set a cipher string to guidecipher selection in case the server lets us choose amongst its supportedciphers, 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 shouldprobably 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 willhave prefer server ciphers on, but that doesn't always happen and providinga 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 someoneto even know what OpenSSL is much less how to configure it and what they wantto configure it to in order to get modern levels of security is backwards. Thedanger for breakage here is *tiny*, *miniscule*, almost non existent and thefailure 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 increate_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 findsthat a server he wants to communicate with for example only supportsRC4 ciphers, because that's the server admins were told to use afterthe BEAST attack was found, the user most likely won't be able tofix this.So what's the net result: the scripts doesn't work, without anyway to get it back to work again. That's not more secure, it'sa failure :-)IMO, Python should make SSL server code use best practices and makeit easy to alter the defaults. Python should also make sure that SSLclient code works using HIGH level ciphers, but not limit theselection much further or make it more specific (apart from removingcompletely broken features like e.g. MD5, aNULL, etc.).If we want to enhance the user security, we should educateour users about best practices and provide information on howto 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. OpenSSLdefaults 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" bestpractices one doesn't. Obviously this was only an example but the problemyou're arguing against doesn't exist in practice. The cipherstring I've postedis largely similar to the one we already have except it removes a few otherciphers that are either weak or unable to actually be used with the API of thessl module and it applies an explicit ordering in order to, in the cases theserver let's us pick, get the best cipher suite.Let me repeat, this cipher string, compatability wise, is not that differentfrom what is *already* there and contains every moderately secure cipher thatis 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 sslmodule.> 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 modernbest practices when Python itself can do it for practically zero differencein compatibility is user hostile. In many cases those users are not even goingto be aware that they are using the ssl module or what OpenSSL even is. To beperfectly honest this set will work with more servers than most browsers willand browsers are typically the kings of bending over backwards not to everbreak 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 comparedto the defaults used in Python (which are basically the OpenSSLdefaults minus the broken parts). I've added !MD5 to the Python cipherstring, 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=SHA1Here's the same diff but using sorted order, so only showing ciphersthat 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=SHA1It 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 breakcompatibility. Could you perhaps explain you're reasoning ?It also shows that by removing DEFAULT, you are not allowing otherciphers.PSK and SRP are not likely to be used by web servers. SEED doesn't appearto 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 futureand you'd automatically get those by using DEFAULT in the cipherstring, so I'd opt for just adding !MD5 to the default cipher list,i.e.DEFAULT:!aNULL:!eNULL:!MD5:!LOW:!EXPORT:!SSLv2With such a string, both servers and client get good compatibility,while keeping Python users reasonably safe per default andkeeping 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 ofwill even issue a DSS cert and I've never seen nor heard of anyone actuallyusing 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, Ididn't explicitly exclude them though. It's just a side effect of specifyingECDH, 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) andmy 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 apriority that is import. It prioritizes:PFS > Non PFS but Secure > Non PFS Secure Slow > Security Problematic but for CompatibilityThis is important especially in the modern age of bulk data collection. It willstill pick up new HIGH ciphers added by OpenSSL without any changes made toPython itself. This is better than a blacklist approach because it'd be easyfor 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 andissue 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 currentlysupport them, SRP had a patch that hasn't been worked on since 2011 andPSK doesn't have a patch at all that this cipher string shouldn'tconcern itself with something that Python might someday in the futuregain 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 aboutrestricting 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 changedmy mind and think it's ok to disable RC4 and DSS :-)I'll still open another issue for server-specific configuration: not theciphers, 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, thessl module disables certain weak ciphers by default, but you may wantto 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 changesete9749a7aa958 by Donald Stufft in branch '3.4':Issue#20995: Enhance default ciphers used by the ssl modulehttp://hg.python.org/cpython/rev/e9749a7aa958

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

New changeset869277faf3dc 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/869277faf3dcNew changeset3b81d1b3f9d1 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 PFSSo 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 busyservers. A smartphone acting as a *client* certainly shouldn't need todownload 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 moreor less equivalent in preference with AES-CBC still less than either of thembecause of problematic construction choices in the TLS spec. If you factorout performance completely there is maybe a slight preference forChaCha20Poly1305 over AES-GCM simply because AES-GCM is hard to implement ina timing safe way in software. However that discussion is mostly academic asright now ChaCha20Poly1305 is not available in OpenSSL.In general I agree that the performance of all of these are "good enough" thatthe average user of this API won't be able to tell the difference, howeverthere is no cost to selecting the generally more performant of the two so Ithink 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.