Donald Stufft added the comment: > > > >> 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. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue20995> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
