Repository navigation
Remove 3DES from cipher list (sweet32 CVE-2016-2183) #72037
Description
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee = None
closed_at = <Date 2017-03-10.01:00:16.787>
created_at = <Date 2016-08-24.13:43:48.259>
labels = ['type-security', 'expert-SSL', 'library', 'release-blocker']
title = 'Remove 3DES from cipher list (sweet32 CVE-2016-2183)'
updated_at = <Date 2017-03-10.01:00:16.785>
user = 'https://github.com/tiran'bugs.python.org fields:
activity = <Date 2017-03-10.01:00:16.785>
actor = 'larry'
assignee = 'none'
closed = True
closed_date = <Date 2017-03-10.01:00:16.787>
closer = 'larry'
components = ['Library (Lib)', 'SSL']
creation = <Date 2016-08-24.13:43:48.259>
creator = 'christian.heimes'
dependencies = []
files = ['44233']
hgrepos = []
issue_num = 27850
keywords = ['patch']
message_count = 43.0
messages = ['273559', '273560', '273561', '273562', '273563', '273564', '273567', '273569', '273570', '273571', '273632', '273665', '273666', '273670', '273705', '273728', '274071', '274072', '274073', '274582', '274584', '274587', '274590', '274594', '274595', '274706', '274718', '274721', '274726', '274772', '274892', '274902', '274932', '274934', '274936', '274982', '274988', '275059', '275073', '277235', '288293', '288323', '289330']
nosy_count = 13.0
nosy_names = ['georg.brandl', 'janssen', 'vstinner', 'larry', 'giampaolo.rodola', 'christian.heimes', 'alex', 'python-dev', 'hynek', 'Jim.Jewett', 'steve.dower', 'dstufft', 'Lukasa']
pr_nums = ['224']
priority = 'release blocker'
resolution = 'fixed'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'security'
url = 'https://bugs.python.org/issue27850'
versions = ['Python 3.4']
Activity
tiran commentedon Aug 24, 2016
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/
hynek commentedon Aug 24, 2016
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”.
alex commentedon Aug 24, 2016
+! from me, removing 3DES is a totally sane default, people who need IE8+XP compat can change the default.
dstufft commentedon Aug 24, 2016
+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.
Lukasa commentedon Aug 24, 2016
+1 from me, Requests, urllib3, and Twisted are all removing 3DES cipher suites from our default list.
tiran commentedon Aug 24, 2016
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.
dstufft commentedon Aug 24, 2016
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.
Lukasa commentedon Aug 24, 2016
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.
tiran commentedon Aug 24, 2016
Donald: 3DES will be removed from HIGH with the next release:
https://www.openssl.org/blog/blog/2016/08/24/sweet32/
dstufft commentedon Aug 24, 2016
Christian: But that doesn't help all of the existing releases of OpenSSL.
tiran commentedon Aug 25, 2016
Donald, !3DES de-selects all 3DES block ciphers suites.
jimjjewett commentedon Aug 25, 2016
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.
dstufft commentedon Aug 25, 2016
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.
21 remaining items
larryhastings commentedon Sep 8, 2016
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.
Lukasa commentedon Sep 8, 2016
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:
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.
tiran commentedon Sep 8, 2016
On 2016-09-08 09:28, Cory Benfield wrote:
I'm going to discuss these points in my OpenSSL PEP. Thanks for the
summary :)
jimjjewett commentedon Sep 8, 2016
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".
larryhastings commentedon Sep 8, 2016
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.
tiran commentedon Sep 22, 2016
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.
tiran commentedon Feb 21, 2017
Victor found out that Python is considered as affect by CVE-2016-2183, https://www.cvedetails.com/cve/CVE-2016-2183/
vstinner commentedon Feb 21, 2017
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.
larryhastings commentedon Mar 10, 2017
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.