Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove 3DES from cipher list (sweet32 CVE-2016-2183) #72037

Closed
tiran opened this issue Aug 24, 2016 · 43 comments
Closed

Remove 3DES from cipher list (sweet32 CVE-2016-2183) #72037

tiran opened this issue Aug 24, 2016 · 43 comments
Labels
expert-SSL release-blocker stdlib Python modules in the Lib dir type-security A security issue

Comments

@tiran
Copy link
Member

tiran commented Aug 24, 2016

BPO 27850
Nosy @birkenfeld, @vstinner, @larryhastings, @giampaolo, @tiran, @alex, @hynek, @JimJJewett, @zooba, @dstufft, @Lukasa
PRs
  • [3.4] Issues #27850 and #27766: Remove 3DES from ssl default cipher list an… #224
  • Files
  • Remove-3DES-from-and-add-ChaCha20-Poly1305-to-cipher.patch
  • 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']

    @tiran
    Copy link
    Member Author

    tiran commented 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/

    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.

    @tiran tiran added stdlib Python modules in the Lib dir type-security A security issue labels Aug 24, 2016
    @hynek
    Copy link
    Member

    hynek commented 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
    Copy link
    Member

    alex commented Aug 24, 2016

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

    @dstufft
    Copy link
    Member

    dstufft commented 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
    Copy link
    Mannequin

    Lukasa mannequin commented Aug 24, 2016

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

    @tiran
    Copy link
    Member Author

    tiran commented 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
    Copy link
    Member

    dstufft commented 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
    Copy link
    Mannequin

    Lukasa mannequin commented 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
    Copy link
    Member Author

    tiran commented Aug 24, 2016

    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.

    @dstufft
    Copy link
    Member

    dstufft commented Aug 24, 2016

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

    @tiran
    Copy link
    Member Author

    tiran commented Aug 25, 2016

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

    @jimjjewett
    Copy link
    Mannequin

    jimjjewett mannequin commented 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
    Copy link
    Member

    dstufft commented 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.

    @tiran
    Copy link
    Member Author

    tiran commented Aug 25, 2016

    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.

    @tiran
    Copy link
    Member Author

    tiran commented Aug 26, 2016

    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

    @jimjjewett
    Copy link
    Mannequin

    jimjjewett mannequin commented Aug 26, 2016

    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\>


    @zooba
    Copy link
    Member

    zooba commented Aug 31, 2016

    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?

    @tiran
    Copy link
    Member Author

    tiran commented Aug 31, 2016

    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.

    @zooba
    Copy link
    Member

    zooba commented Aug 31, 2016

    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).

    @python-dev
    Copy link
    Mannequin

    python-dev mannequin commented Sep 6, 2016

    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

    @tiran
    Copy link
    Member Author

    tiran commented Sep 6, 2016

    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.

    @larryhastings
    Copy link
    Contributor

    larryhastings commented Sep 6, 2016

    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+.

    @dstufft
    Copy link
    Member

    dstufft commented Sep 6, 2016

    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.

    @tiran
    Copy link
    Member Author

    tiran commented Sep 6, 2016

    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.

    @dstufft
    Copy link
    Member

    dstufft commented Sep 6, 2016

    We should backport OpenSSL 1.1.0 too *shrug*.

    @larryhastings
    Copy link
    Contributor

    larryhastings commented Sep 7, 2016

    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.

    @dstufft
    Copy link
    Member

    dstufft commented Sep 7, 2016

    > 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).

    @larryhastings
    Copy link
    Contributor

    larryhastings commented Sep 7, 2016

    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.

    @larryhastings
    Copy link
    Contributor

    larryhastings commented Sep 7, 2016

    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.

    @Lukasa
    Copy link
    Mannequin

    Lukasa mannequin commented Sep 7, 2016

    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?

    @tiran
    Copy link
    Member Author

    tiran commented Sep 7, 2016

    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

    @larryhastings
    Copy link
    Contributor

    larryhastings commented Sep 7, 2016

    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.

    @jimjjewett
    Copy link
    Mannequin

    jimjjewett mannequin commented Sep 8, 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?

    @dstufft
    Copy link
    Member

    dstufft commented Sep 8, 2016

    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.

    @larryhastings
    Copy link
    Contributor

    larryhastings commented Sep 8, 2016

    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.

    @Lukasa
    Copy link
    Mannequin

    Lukasa mannequin commented 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:

    • 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.

    @tiran
    Copy link
    Member Author

    tiran commented Sep 8, 2016

    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 :)

    @jimjjewett
    Copy link
    Mannequin

    jimjjewett mannequin commented 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
    Copy link
    Contributor

    larryhastings commented 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 tiran self-assigned this Sep 15, 2016
    @tiran
    Copy link
    Member Author

    tiran commented 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 tiran removed their assignment Sep 26, 2016
    @tiran
    Copy link
    Member Author

    tiran commented 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
    Copy link
    Member

    vstinner commented 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
    Copy link
    Contributor

    larryhastings commented 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.

    @ezio-melotti ezio-melotti transferred this issue from another repository Apr 10, 2022
    Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
    Labels
    expert-SSL release-blocker stdlib Python modules in the Lib dir type-security A security issue
    Projects
    None yet
    Development

    No branches or pull requests

    7 participants