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-21.11:23:34
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <532C2130.7040506@egenix.com>
In-reply-to <1395357048.5.0.0382883591735.issue20995@psf.upfronthosting.co.za>
Content
On 21.03.2014 00:10, Donald Stufft wrote:
> 
>> 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.
> 
> The difference here is that there are properly maintained alternatives to
> Python including a predefined set of CA root certificates. This isn't the
> case with OpenSSL. OpenSSL doesn't provide good defaults and I'm not aware of
> a single OS which ships with OpenSSL that patches it to provide good defaults.
> 
> Python exposes this API, it's Python's job to properly secure it.

Perhaps I should have clarified this earlier on:
I agree to use such defaults for writing SSL servers in Python.
I disagree when it comes to SSL clients.

If we enforce a specific set of ciphers per default and a user finds
that a server he wants to communicate with for example only supports
RC4 ciphers, because that's the server admins were told to use after
the BEAST attack was found, the user most likely won't be able to
fix this.

So what's the net result: the scripts doesn't work, without any
way to get it back to work again. That's not more secure, it's
a failure :-)

IMO, Python should make SSL server code use best practices and make
it easy to alter the defaults. Python should also make sure that SSL
client code works using HIGH level ciphers, but not limit the
selection much further or make it more specific (apart from removing
completely broken features like e.g. MD5, aNULL, etc.).

If we want to enhance the user security, we should educate
our users about best practices and provide information on how
to implement them,
History
Date User Action Args
2014-03-21 11:23:35lemburgsetrecipients: + lemburg, ncoghlan, pitrou, vstinner, christian.heimes, benjamin.peterson, ezio.melotti, Arfrever, alex, r.david.murray, dstufft
2014-03-21 11:23:35lemburglinkissue20995 messages
2014-03-21 11:23:34lemburgcreate