This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author lemburg
Recipients Arfrever, alex, benjamin.peterson, christian.heimes, dstufft, ezio.melotti, lemburg, ncoghlan, pitrou, r.david.murray, vstinner
Date 2014-03-20.22:51:45
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <532B70FB.5000001@egenix.com>
In-reply-to <1395355017.29.0.108583471995.issue20995@psf.upfronthosting.co.za>
Content
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 OpenSSL
system defaults should be used.

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.

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.

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.
History
Date User Action Args
2014-03-20 22:51:45lemburgsetrecipients: + lemburg, ncoghlan, pitrou, vstinner, christian.heimes, benjamin.peterson, ezio.melotti, Arfrever, alex, r.david.murray, dstufft
2014-03-20 22:51:45lemburglinkissue20995 messages
2014-03-20 22:51:45lemburgcreate