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