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

Well Python is already doing that and Python should be doing that. OpenSSL
defaults are horrendous.

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

Luckily my default cipher string still contains RC4 only the "restricted" best
practices one doesn't. Obviously this was only an example but the problem
you're arguing against doesn't exist in practice. The cipherstring I've posted
is largely similar to the one we already have except it removes a few other
ciphers that are either weak or unable to actually be used with the API of the
ssl module and it applies an explicit ordering in order to, in the cases the
server let's us pick, get the best cipher suite.

Let me repeat, this cipher string, compatability wise, is not that different
from what is *already* there and contains every moderately secure cipher that
is in use.

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

You can get it back just by passing the ciphers keyword argument to the ssl
module.

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

My cipherstring includes all HIGH ciphers and only explicitly excludes MD5,
aNULL, eNULL, and DSS.

> If we want to enhance the user security, we should educate
> our users about best practices and provide information on how
> to implement them,

Expecting users to properly configure a cipher string in order to get modern
best practices when Python itself can do it for practically zero difference
in compatibility is user hostile. In many cases those users are not even going
to be aware that they are using the ssl module or what OpenSSL even is. To be
perfectly honest this set will work with more servers than most browsers will
and browsers are typically the kings of bending over backwards not to ever
break SSL.