classification
Title: Remove 3DES from cipher list (sweet32 CVE-2016-2183)
Type: security Stage: resolved
Components: Library (Lib), SSL Versions: Python 3.4
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: Nosy List: Jim.Jewett, Lukasa, alex, christian.heimes, dstufft, georg.brandl, giampaolo.rodola, hynek, janssen, larry, python-dev, steve.dower, vstinner
Priority: release blocker Keywords: patch

Created on 2016-08-24 13:43 by christian.heimes, last changed 2017-03-10 01:00 by larry. This issue is now closed.

Files
File name Uploaded Description Edit
Remove-3DES-from-and-add-ChaCha20-Poly1305-to-cipher.patch christian.heimes, 2016-08-26 13:46 review
Pull Requests
URL Status Linked Edit
PR 224 vstinner, 2017-02-21 21:42
Messages (43)
msg273559 - (view) Author: Christian Heimes (christian.heimes) * (Python committer) Date: 2016-08-24 13:43
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.
msg273560 - (view) Author: Hynek Schlawack (hynek) * (Python committer) Date: 2016-08-24 13:47
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”.
msg273561 - (view) Author: Alex Gaynor (alex) * (Python committer) Date: 2016-08-24 13:49
+! from me, removing 3DES is a totally sane default, people who need IE8+XP compat can change the default.
msg273562 - (view) Author: Donald Stufft (dstufft) * (Python committer) Date: 2016-08-24 13:51
+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.
msg273563 - (view) Author: Cory Benfield (Lukasa) * Date: 2016-08-24 14:03
+1 from me, Requests, urllib3, and Twisted are all removing 3DES cipher suites from our default list.
msg273564 - (view) Author: Christian Heimes (christian.heimes) * (Python committer) Date: 2016-08-24 14:14
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.
msg273567 - (view) Author: Donald Stufft (dstufft) * (Python committer) Date: 2016-08-24 14:23
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.
msg273569 - (view) Author: Cory Benfield (Lukasa) * Date: 2016-08-24 14:27
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.
msg273570 - (view) Author: Christian Heimes (christian.heimes) * (Python committer) Date: 2016-08-24 14:54
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.
msg273571 - (view) Author: Donald Stufft (dstufft) * (Python committer) Date: 2016-08-24 14:55
Christian: But that doesn't help all of the existing releases of OpenSSL.
msg273632 - (view) Author: Christian Heimes (christian.heimes) * (Python committer) Date: 2016-08-25 07:05
Donald, !3DES de-selects all 3DES block ciphers suites.
msg273665 - (view) Author: Jim Jewett (Jim.Jewett) Date: 2016-08-25 16:27
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.
msg273666 - (view) Author: Donald Stufft (dstufft) * (Python committer) Date: 2016-08-25 16:28
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.
msg273670 - (view) Author: Christian Heimes (christian.heimes) * (Python committer) Date: 2016-08-25 16:48
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.
msg273705 - (view) Author: Christian Heimes (christian.heimes) * (Python committer) Date: 2016-08-26 13:46
Patch for 3DES and ChaCha20 (#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
msg273728 - (view) Author: Jim Jewett (Jim.Jewett) Date: 2016-08-26 21:34
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 (#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>
> _______________________________________
>
msg274071 - (view) Author: Steve Dower (steve.dower) * (Python committer) Date: 2016-08-31 21:01
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?
msg274072 - (view) Author: Christian Heimes (christian.heimes) * (Python committer) Date: 2016-08-31 21:03
My time machine strikes again: #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.
msg274073 - (view) Author: Steve Dower (steve.dower) * (Python committer) Date: 2016-08-31 21:07
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).
msg274582 - (view) Author: Roundup Robot (python-dev) Date: 2016-09-06 18:12
New changeset d2111109fd77 by Christian Heimes in branch '3.5':
Issues #27850 and #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 #27850 and #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 #27850 and #27766: Remove 3DES from ssl default cipher list and add ChaCha20 Poly1305.
https://hg.python.org/cpython/rev/f586742e56cb
msg274584 - (view) Author: Christian Heimes (christian.heimes) * (Python committer) Date: 2016-09-06 18:15
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.
msg274587 - (view) Author: Larry Hastings (larry) * (Python committer) Date: 2016-09-06 18:19
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+.
msg274590 - (view) Author: Donald Stufft (dstufft) * (Python committer) Date: 2016-09-06 18:32
> 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.
msg274594 - (view) Author: Christian Heimes (christian.heimes) * (Python committer) Date: 2016-09-06 18:34
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.
msg274595 - (view) Author: Donald Stufft (dstufft) * (Python committer) Date: 2016-09-06 18:37
We should backport OpenSSL 1.1.0 too *shrug*.
msg274706 - (view) Author: Larry Hastings (larry) * (Python committer) Date: 2016-09-07 02:26
> 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.
msg274718 - (view) Author: Donald Stufft (dstufft) * (Python committer) Date: 2016-09-07 02:55
> > 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).
msg274721 - (view) Author: Larry Hastings (larry) * (Python committer) Date: 2016-09-07 02:59
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.
msg274726 - (view) Author: Larry Hastings (larry) * (Python committer) Date: 2016-09-07 03:06
> 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.
msg274772 - (view) Author: Cory Benfield (Lukasa) * Date: 2016-09-07 07:31
> 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?
msg274892 - (view) Author: Christian Heimes (christian.heimes) * (Python committer) Date: 2016-09-07 21:02
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
msg274902 - (view) Author: Larry Hastings (larry) * (Python committer) Date: 2016-09-07 22:10
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.
msg274932 - (view) Author: Jim Jewett (Jim.Jewett) Date: 2016-09-08 00:26
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?
msg274934 - (view) Author: Donald Stufft (dstufft) * (Python committer) Date: 2016-09-08 00:28
> 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.
msg274936 - (view) Author: Larry Hastings (larry) * (Python committer) Date: 2016-09-08 00:50
> 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.
msg274982 - (view) Author: Cory Benfield (Lukasa) * Date: 2016-09-08 07:28
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.
msg274988 - (view) Author: Christian Heimes (christian.heimes) * (Python committer) Date: 2016-09-08 09:16
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 :)
msg275059 - (view) Author: Jim Jewett (Jim.Jewett) Date: 2016-09-08 16:26
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".
msg275073 - (view) Author: Larry Hastings (larry) * (Python committer) Date: 2016-09-08 17:32
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.
msg277235 - (view) Author: Christian Heimes (christian.heimes) * (Python committer) Date: 2016-09-22 18:40
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.
msg288293 - (view) Author: Christian Heimes (christian.heimes) * (Python committer) Date: 2017-02-21 13:00
Victor found out that Python is considered as affect by CVE-2016-2183, https://www.cvedetails.com/cve/CVE-2016-2183/
msg288323 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2017-02-21 21:42
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.
msg289330 - (view) Author: Larry Hastings (larry) * (Python committer) Date: 2017-03-10 01:00
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.
History
Date User Action Args
2017-03-10 01:00:16larrysetstatus: open -> closed
resolution: fixed
messages: + msg289330

stage: commit review -> resolved
2017-03-10 00:16:09vstinnersetpriority: critical -> release blocker
2017-02-21 21:42:50vstinnersetnosy: + vstinner

messages: + msg288323
pull_requests: + pull_request189
2017-02-21 13:00:31christian.heimessetmessages: + msg288293
2016-09-26 19:25:43christian.heimessetassignee: christian.heimes ->
versions: - Python 2.7, Python 3.5, Python 3.6
2016-09-22 18:40:38christian.heimessetmessages: + msg277235
2016-09-15 07:53:02christian.heimessetassignee: christian.heimes
components: + SSL
2016-09-08 17:32:36larrysetmessages: + msg275073
2016-09-08 16:26:36Jim.Jewettsetmessages: + msg275059
2016-09-08 09:16:47christian.heimessetmessages: + msg274988
2016-09-08 07:28:58Lukasasetmessages: + msg274982
2016-09-08 00:51:01larrysetmessages: + msg274936
2016-09-08 00:28:26dstufftsetmessages: + msg274934
2016-09-08 00:26:12Jim.Jewettsetmessages: + msg274932
2016-09-07 22:10:49larrysetmessages: + msg274902
versions: + Python 3.4
2016-09-07 21:02:14christian.heimessetmessages: + msg274892
2016-09-07 07:31:54Lukasasetmessages: + msg274772
2016-09-07 03:06:09larrysetmessages: + msg274726
2016-09-07 02:59:50larrysetmessages: + msg274721
2016-09-07 02:55:53dstufftsetmessages: + msg274718
2016-09-07 02:26:06larrysetmessages: + msg274706
2016-09-06 18:37:11dstufftsetmessages: + msg274595
2016-09-06 18:34:57christian.heimessetmessages: + msg274594
2016-09-06 18:32:06dstufftsetmessages: + msg274590
2016-09-06 18:19:17larrysetmessages: + msg274587
versions: - Python 3.3, Python 3.4
2016-09-06 18:15:36christian.heimessetnosy: + georg.brandl, larry
messages: + msg274584
2016-09-06 18:12:44christian.heimessetstage: commit review
2016-09-06 18:12:06python-devsetnosy: + python-dev
messages: + msg274582
2016-08-31 21:07:47steve.dowersetmessages: + msg274073
2016-08-31 21:03:49christian.heimessetmessages: + msg274072
2016-08-31 21:01:13steve.dowersetnosy: + steve.dower
messages: + msg274071
2016-08-26 21:34:30Jim.Jewettsetmessages: + msg273728
2016-08-26 13:46:54christian.heimessetfiles: + Remove-3DES-from-and-add-ChaCha20-Poly1305-to-cipher.patch
keywords: + patch
messages: + msg273705
2016-08-25 16:48:23christian.heimessetmessages: + msg273670
2016-08-25 16:28:53dstufftsetmessages: + msg273666
2016-08-25 16:27:31Jim.Jewettsetnosy: + Jim.Jewett
messages: + msg273665
2016-08-25 07:05:19christian.heimessetmessages: + msg273632
2016-08-24 14:55:42dstufftsetmessages: + msg273571
2016-08-24 14:54:05christian.heimessetmessages: + msg273570
2016-08-24 14:27:41Lukasasetmessages: + msg273569
2016-08-24 14:23:03dstufftsetmessages: + msg273567
2016-08-24 14:14:12christian.heimessetmessages: + msg273564
2016-08-24 14:03:57Lukasasetnosy: + Lukasa
messages: + msg273563
2016-08-24 13:51:38dstufftsetmessages: + msg273562
2016-08-24 13:49:58alexsetmessages: + msg273561
2016-08-24 13:47:30hyneksetnosy: + hynek
messages: + msg273560
2016-08-24 13:43:48christian.heimescreate