Donald Stufft added the comment: > > However I still content that using HIGH in the cipherstring actually > > adds additional maintenance burden. In order to know if that > > cipherstring is still safe you must run it against every target > > OpenSSL you want to make secure to ensure that it doesn't allow a new > > cipher that doesn't meet the security strength that was attempted to > > be had with that cipherstring.
> I think that is a bit reverse. The main configuration point for ciphers > should be the server, not the client. We set a cipher string to guide > cipher selection in case the server lets us choose amongst its supported > ciphers, but that's all. The Python ssl module is used for servers and clients. Ideally servers will have prefer server ciphers on, but that doesn't always happen and providing a modern level of security for end users is preferable. > Besides, the ssl module doesn't promise a specific "security strength". > The defaults are a best effort thing, and paranoid people should > probably override the cipher string (and deal with the consequences). These are not things that affect only paranoid people and expecting someone to even know what OpenSSL is much less how to configure it and what they want to configure it to in order to get modern levels of security is backwards. The danger for breakage here is *tiny*, *miniscule*, almost non existent and the failure case is obvious and easy to fix. ---------- _______________________________________ 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
