Another attack with a catchy name and logo. This time 3DES is showing its age. 3DES should be removed from the list of server ciphers in ssl._RESTRICTED_SERVER_CIPHERS. For client ciphers we can leave it in for now. An attack requires dynamic code execution of code from a malicious 3rd party and several hundred GB of traffic. It's relevant for browsers with JS but not for majority of Python applications. OpenSSL 1.1.0 will remove 3DES support by default anyway.

https://www.openssl.org/blog/blog/2016/08/24/sweet32/
https://sweet32.info/

As seen previously, the full attack should require 236.6 blocks (785 GB) to recover a two-block cookie, which should take 38 hours in our setting. Experimentally, we have recovered a two-block cookie from an HTTPS trace of only 610 GB, captured in 30.5 hours.

JFTR the main compatibility impact on the browser side is the loss of IE8 on WinXP whose last stable release is qua Wikipedia from “February 22, 2011; 5 years ago”.

+! from me, removing 3DES is a totally sane default, people who need IE8+XP compat can change the default.

+1 from me, as another data point, the PSF infrastructure (which serves things like hg.python.org that aren't behind Fastly) has had 3DES disabled since 2014 without any complaints that I've seen.

+1 from me, Requests, urllib3, and Twisted are all removing 3DES cipher suites from our default list.

I'm +1 for removal from server-side suite and +0.5 for removal from client-side suite.

Unless somebody makes a compelling reason for keeping 3DES at all, let's get rid of it for good. Users are free to override the settings. It might make sense to include ChaCha20 at the same time so we don't have to touch the same lines twice.

Should we also remove HIGH from the cipher list? If I recall, at the time we added it under the assumption that we might get new, better ciphers automatically but 3DES is considered "HIGH", so we'll get it pulled in via that on older OpenSSLs.

As another data point, I just pushed a PR to remove HIGH from urllib3/requests for exactly this reason, and Twisted already doesn't use it.

Donald: 3DES will be removed from HIGH with the next release:

https://www.openssl.org/blog/blog/2016/08/24/sweet32/

For 1.0.2 and 1.0.1, we removed the triple-DES ciphers from the “HIGH” keyword and put them into “MEDIUM.” Note that we did not remove them from the “DEFAULT” keyword.

Christian: But that doesn't help all of the existing releases of OpenSSL.

Donald, !3DES de-selects all 3DES block ciphers suites.

What does overriding to put it back require?

Does it require a re-compile, or can it be done via a config file?

Taking it out of the default set sounds reasonable, but requiring a recompile for people who want to retain backwards compatibility strikes me as too much, particularly for a maintenance release.

It's not a recompile but it's not a configuration file either, it's a Python level API you can call when you're creating a connection to specify what ciphers you want to allow for that connection.

Jim, https://docs.python.org/3/library/ssl.html#ssl.SSLContext.set_ciphers

>> ctx = ssl.create_default_context()
>> ctx.set_ciphers('HIGH:+3DES:!MD5')

Please note that OpenSSL 1.1 will remove 3DES from default builds. You will have to build your own OpenSSL and re-compile Python in order to use 3DES with OpenSSL 1.1.

Patch for 3DES and ChaCha20 (bpo-27766).

For ChaCha the patch does not check CPU cap vector and just follows the advice from https://wiki.mozilla.org/Security/Server_Side_TLS#Modern_compatibility

I think a python call is fine to require ... if they don't have the python
source they should have a support contract. I assume the advice followed is
intermediate, based on the earlier comment about xp and ie?

On Aug 26, 2016 9:46 AM, "Christian Heimes" <report@bugs.python.org> wrote:

Christian Heimes added the comment:

Patch for 3DES and ChaCha20 (bpo-27766).

For ChaCha the patch does not check CPU cap vector and just follows the
advice from https://wiki.mozilla.org/Security/Server_Side_TLS#
Modern_compatibility

----------
keywords: +patch
Added file: https://bugs.python.org/file44233/Remove-3DES-from-
and-add-ChaCha20-Poly1305-to-cipher.patch

---

Python tracker <report@bugs.python.org>
<https://bugs.python.org/issue27850\>

---

How can I test that the ciphers are available? Our Windows build of OpenSSL (managed by us) does not necessarily include everything and I honestly don't know an easy way to ensure that ChaCha20 has actually been built in. It doesn't look like there are any link-time references.

Everything built fine for me against 3.6, so I'm assuming there's some Python code I can run to make sure it's actually there?

My time machine strikes again: bpo-27866 introduces a new method to get all enabled ciphers. ChaCha20 needs either LibreSSL, OpenSSL 1.1.0 or OpenSSL 1.0.2 with an extra patch.

Just found and added that :)

Guessing one of the 'name' fields will show it? If so, looks like all the Windows builds will be missing it.

I'm assuming that doesn't block this change. We should have a separate task to change the Windows build to use 1.1.0 I guess (currently it's 1.0.2).

New changeset d2111109fd77 by Christian Heimes in branch '3.5':
Issues bpo-27850 and bpo-27766: Remove 3DES from ssl default cipher list and add ChaCha20 Poly1305.
https://hg.python.org/cpython/rev/d2111109fd77

New changeset 6f4f19217d9b by Christian Heimes in branch '2.7':
Issues bpo-27850 and bpo-27766: Remove 3DES from ssl default cipher list and add ChaCha20 Poly1305.
https://hg.python.org/cpython/rev/6f4f19217d9b

New changeset f586742e56cb by Christian Heimes in branch 'default':
Issues bpo-27850 and bpo-27766: Remove 3DES from ssl default cipher list and add ChaCha20 Poly1305.
https://hg.python.org/cpython/rev/f586742e56cb

Larry, Georg

I haven't pushed the new cipher suite list to 3.3 and 3.4 yet. It can break compatibility with ancient IE versions on Windows XP machines. The risk of 3DES is small for a typical application.

I don't think "remove de-recommended cypher" qualifies as a security fix for 3.3 or 3.4. Certainly you're not permitted to add ChaCha20 to 3.3 or 3.4. IMO these changes should only be in 2.7 and 3.5+.

I don't think "remove de-recommended cypher" qualifies as a security fix for 3.3 or 3.4. Certainly you're not permitted to add ChaCha20 to 3.3 or 3.4

I think that this is a bad stance to take here. The difference between a security feature and a security fix is incredibly hard to differentiate. For instance, with 3DES being de-recommended (and removed in future OpenSSLs) that leaves basically only AES-GCM and AES-CBC left as a secure cipher. This is a very precarious position to be in because all it takes is some reason that these constructions are less secure (it doesn't even have to be an attack on AES itself, could just be the way TLS uses it) and suddenly 3.3 and 3.4 don't have *any* secure ciphers. It is important from a security standpoint to have multiple secure ciphers available with different implementation details to protect against problems in one of them from causing widespread harm.

As far as removing 3DES, I think that we need to either remove it or we need to implement protections to prevent it from being used for too much data. 3DES isn't insecure so much as it's so old that you can only safely encrypt so much data with it with a single TLS key (Key == Connection roughly) before it becomes insecure. This is likely to hit automated tooling worse because it only affects things that hold long lived connections or re-use TLS session keys for a long period of time and a lot of tooling does just that for performance reasons.

Donald, my OpenSSL 1.1.0 patch hasn't landed in 3.3 and 3.4 either. It's a bit mood to discuss ChaCha20 w/o OpenSSL 1.1.0. Rich Salz doesn't want to include ChaCha20 suites in 1.0.2 upstream. You either have to patch and build OpenSSL yourself or use LibreSSL.

We should backport OpenSSL 1.1.0 too *shrug*.

The difference between a security feature and a security fix
is incredibly hard to differentiate.

I'm not buying this argument.

For instance, with 3DES being de-recommended (and removed in future
OpenSSLs) that leaves basically only AES-GCM and AES-CBC left as a
secure cipher.

Future OpenSSLs don't affect Python 3.4, as Python 3.4 won't be upgraded to them. Anyway we don't ship binary installers for 3.4 anymore.

Please don't check in support for new cyphers to 3.4.

> The difference between a security feature and a security fix
> is incredibly hard to differentiate.

I'm not buying this argument.

This touches on it http://web.mit.edu/tabbott/www/papers/hotos.pdf but I'm not sure how you don't see it... In the hypothetical case we don't backport ChaCha20 support and 3DES and AES constructs in TLS are no longer secure... what do you do? Do you just plug your fingers in your ears and hope nobody attacks you? Do you rush to try and patch it at the last minute as a rush job instead of being able to phase it in at a controlled time?

Future OpenSSLs don't affect Python 3.4, as Python 3.4 won't be upgraded to them. Anyway we don't ship binary installers for 3.4 anymore.

Well except LibreSSL already supports this just fine, so it doesn't require a new OpenSSL at all and I'm not sure what it means that "Python 3.4 won't be upgraded to them". Python will forcibly mandate that nobody ever links against a newer OpenSSL version?

Please don't check in support for new cyphers to 3.4.

FWIW the cipher list (at least the restricted ones for ssl.create_default_context()) is explicitly documented as being able to be changed at any time without prior deprecation (and RC4 for instance was dropped in Python 3.4.4).

Here at the core dev sprint we had a discussion about whether adding ChaCha20 into 3.5 was the right call. Strictly speaking, of course, it's neither a bug fix or a security fix, so that suggests it shouldn't be permitted. However ultimately we concluded it was okay to leave it in.

One thing that bears pointing point out: the Windows binary installers and the Mac 64-bit installers are built against OpenSSL versions that don't have support for ChaCha20 anyway, so it's not going to change anything for those users. Ned wasn't sure whether or not 32-bit Mac binary installers would or not--and it's such an irrelevant platform he couldn't be bothered to find out.

FWIW the cipher list (at least the restricted ones for
ssl.create_default_context()) is explicitly documented
as being able to be changed at any time without prior deprecation

Yes. To be specific: "The protocol, options, cipher and other settings may change to more restrictive values anytime without prior deprecation."

https://docs.python.org/3/library/ssl.html#ssl.create_default_context

I've seen no documentation suggesting that we can add new ciphers at any time.

Future OpenSSLs don't affect Python 3.4, as Python 3.4 won't be upgraded to them.

Can I get a clarification on this, please, Larry? I just want to confirm I understand what your meaning is here.

My reading of this is that for OpenSSL Python defines a range of compatible sonames at the time of the first release in a series (e.g. 3.4.0), and then will never extend that in either direction for that release series. Put another way: patches to extend the supported OpenSSL versions are not acceptable in patch releases of Python.

Is that reading accurate?

On 2016-09-07 05:06, Larry Hastings wrote:

Larry Hastings added the comment:

> FWIW the cipher list (at least the restricted ones for
> ssl.create_default_context()) is explicitly documented
> as being able to be changed at any time without prior deprecation

Yes. To be specific: "The protocol, options, cipher and other settings may change to more restrictive values anytime without prior deprecation."

https://docs.python.org/3/library/ssl.html#ssl.create_default_context

I've seen no documentation suggesting that we can add new ciphers at any time.

ChaCha20 is part of the HIGH cipher set. That means the patch does not
*add* ChaCha20. It's already added by the HIGH rule. The patch rather
moves the cipher ChaCha20 Poly1305 suits in the right place.

Christian

Okay. We (Ned Deily + Steve Dower + me) talked it over here at the core dev sprints, and they convinced me that it's basically okay to add the CHACHA20 string to 3.4 and 3.5--it has some history, and OpenSSL is a little different, etc etc. So go for it.

I suspect it won't affect very many people anyway, because not many will use Python 3.4 with a version of OpenSSL that supports ChaCha20. It's more likely with 3.5 users--not with our binary installers, but perhaps the Linux distributions that release during what remains of 2016.

On Sep 6, 2016 10:55 PM, Donald Stufft added the comment:

In the hypothetical case we don't backport ChaCha20 support and 3DES and
AES constructs in TLS are no longer secure... what do you do? Do you just
plug your fingers in your ears and hope nobody attacks you?

That works fine for an awful lot of uses.

For the ones where it doesn't work, people can either upgrade to 3.5 or get
support from a reseller like red hat or caconical or ActiveState or ...

Providing the support for free isn't *wrong*, but "we don't add new things
except to the current release" is a both clear and sensible ... overriding
should be rare. Assuming an override should be accepted just because
"security" reminds me of the boy who cried wolf.

> Future OpenSSLs don't affect Python 3.4, as Python 3.4 won't be
upgraded to them. ...

Well except LibreSSL already supports this just fine,

Is switching to a different SSL library without OS vendor support any more
reasonable than switching to a newer python without that same support?

Is switching to a different SSL library without OS vendor support any more
reasonable than switching to a newer python without that same support?

There are OSs that ship with Python 3.4 and LibreSSL.

My reading of this is that for OpenSSL Python defines a range of
compatible sonames at the time of the first release in a series (e.g.
3.4.0), and then will never extend that in either direction for that
release series. Put another way: patches to extend the supported
OpenSSL versions are not acceptable in patch releases of Python.

Is that reading accurate?

So, as RM, I don't exactly directly interact with our OpenSSL support. I don't decide on a version anywhere. I do test against it when I build and test, but I do my testing on Linux so I just wind up with whatever version of OpenSSL my OS shipped with. The decision about what version(s) to support on Windows and Mac falls to the Windows and Mac "platform experts", respectively Steve Dower and Ned Deily. When it's a platform-specific question regarding those two platforms, I defer to them.

With all that said, my understanding is that the OpenSSL devs aren't very strict about what changes they make in minor releases (say, 1.0.2g -> 1.0.2h). I mean, sure, they might add bugs--it happens. But that's not what I'm talking about. IIUC they may introduce new features or even break APIs. So changing the OpenSSL version for an existing release doesn't seem like a very good idea, unless it's necessary to fix awful security holes. I wouldn't want to upgrade to a new OpenSSL point release just on basic "gee it's nice to stay current on software" general principles.

As for this modifying the list of acceptable ciphers thing--at this point I'm fine with it, even for 3.4.

I hope that clarified it for you. Sadly that's all the clarity I've got on hand.

Thanks for your response Larry. I think it cleared up my understanding a bit, and I'm (extremely!) sympathetic to your desire to not get any closer to this problem than you have to.

I think it may be worth, in future, defining what effort will be made to achieve compatibility with libraries that Python relies on. I can see several questions here that, AFAIK, have no concrete answer:

• Can a Python minor version increase (e.g. 3.6 -> 3.7) add support for a new ABI in a library dependency? (This one has an answer, which is certainly yes, but we could still stand to write it down because you'd be amazed how often it helps to write down the basic starting point of the argument.)
• Can a Python patch version increase *before* security release mode (e.g. 3.6.1 -> 3.6.2) add support for a new ABI in a library dependency?
  • What about a new API that maintains ABI compatibility?
• Can a Python security version increase (e.g. 3.4.5 -> 3.4.6) add support for a new ABI in a library dependency?
  • What about a new API that maintains ABI compatibility?
• How do the answers to the above questions vary if the change is security-focused (e.g. AES is broken tomorrow so ChaCha20 is the only safe cipher left in OpenSSL)?

I'm not qualified or authoritative enough to answer those questions, but having an answer to them would help modulate expectations from people like myself.

On 2016-09-08 09:28, Cory Benfield wrote:

Cory Benfield added the comment:

Thanks for your response Larry. I think it cleared up my understanding a bit, and I'm (extremely!) sympathetic to your desire to not get any closer to this problem than you have to.

I think it may be worth, in future, defining what effort will be made to achieve compatibility with libraries that Python relies on. I can see several questions here that, AFAIK, have no concrete answer:

• Can a Python minor version increase (e.g. 3.6 -> 3.7) add support for a new ABI in a library dependency? (This one has an answer, which is certainly yes, but we could still stand to write it down because you'd be amazed how often it helps to write down the basic starting point of the argument.)
• Can a Python patch version increase *before* security release mode (e.g. 3.6.1 -> 3.6.2) add support for a new ABI in a library dependency?
  • What about a new API that maintains ABI compatibility?
• Can a Python security version increase (e.g. 3.4.5 -> 3.4.6) add support for a new ABI in a library dependency?
  • What about a new API that maintains ABI compatibility?
• How do the answers to the above questions vary if the change is security-focused (e.g. AES is broken tomorrow so ChaCha20 is the only safe cipher left in OpenSSL)?

I'm not qualified or authoritative enough to answer those questions, but having an answer to them would help modulate expectations from people like myself.

I'm going to discuss these points in my OpenSSL PEP. Thanks for the
summary :)

In general, the rule is that micro versions (such as 3.4.4 to 3.4.5)
should not make any changes that are not clearly bug fixes. If users would
call the new API (or ABI) differently, it is almost certainly a change that
should be reserved for a development release (3.4 to 3.5).

That said, the two main reasons for exceptions are security (not an
automatic OK, but at least not an automatic NO) and "no one could possibly
rely on the old behavior", which covers "this wouldn't even compile on this
platform before".

I agree completely Jim. The problem is that OpenSSL regularly discovers face-meltingly bad security bugs, so it frequently pulls the "security exception" lever.

As with so many things in this life, we play the hand we're dealt. I have my fingers crossed that LibreSSL will, in the long run, be far more sane, and that we can switch to it someday. But for now I expect to have plenty more "necessary" OpenSSL upgrades foisted onto Python.

Larry, the issue has nothing to do with the TLS/SSL library or implementation. It's about cipher suite selection. All (!) SSL libraries are affected because they had 3DES enabled as legacy fallback.

Fun fact: OpenSSL latest security fix has addressed the issue and disabled 3DES by default. But Python overrides the fix and enables 3DES again. LibreSSL hasn't announced a fix yet.

By the way I don't take LibreSSL serious. The developers are all cookie about best practice and security but they don't even offer HTTPS on their website or for downloads. Yes, the official download location for LibreSSL does not support secure file transfer.

Victor found out that Python is considered as affect by CVE-2016-2183, https://www.cvedetails.com/cve/CVE-2016-2183/

Larry: "I agree completely Jim. The problem is that OpenSSL regularly discovers face-meltingly bad security bugs, so it frequently pulls the "security exception" lever."

We chose to maintain our own cipher list, and so we have to maintain it.

I created a pull request to backport the fix to Python 3.4.

I've accepted PR 224. I don't plan an emergency release of 3.4 to get this change out into the world. Unless there's any other business, we can now close this issue.