> > By default the Python SSL/TLS Stack (client/server) expose
> > unsecure protocols (SSLv2) and unsecure ciphers (EXPORT 40bit DES).
> 
> If there is a problem, it should not be fixed in Python, but in the
> underlying library (OpenSSL) or in applications. Python only exposes
> features of the OpenSSL library.

The ssl module's theoretical goal is to provide access to SSL features;
that it wraps OpenSSL APIs is mostly an implementation detail, although
it is true that the APIs resemble OpenSSL's in some places.

This is where we can have different policies: OpenSSL is a low-level
library with an exhaustive (if poorly documented) API; the ssl module is
more synthetic and slightly higher-level, and likely to be used by
crypto novices. As such, we can have a different set of default ciphers.

> You should not see Python as an application but as a language: Python
> doesn't know what is your use case, or if you write a client or a
> server.

This is why I would like to stay conservative when disabling ciphers:
disable the really weak ones, but avoid being too opinionated.

> If you consider that it is too complex to change the cipher list in a
> high level API (like http.client?), we may a ssl.DEFAULT_CIPHERS to
> allow an application to change the *default* cipher list.

Changing higher-level APIs means there are more places where the change
has to be done.

> SSLContext() requires a protocol, I suppose that the protocol is also
> by OpenSSL used in the negociation of the cipher list.

There are weak ciphers even in TLS1.

> If we change the default behaviour, we should allow the user to get
> back the old behaviour (e.g. mark ssl._DEFAULT_CIPHERS as public in
> default_ciphers.patch).

set_ciphers("something") is how you change ciphers. It is a public API.
But I wouldn't expect anyone to re-enable 56-bit DES ciphers: if we are
conservative with our choice of default ciphers, nobody should have
issues with it.

> IMO this issue is more a documentation issue: we should add a warning
> in the ssl module documentation, and maybe also in the documentation
> of modules using the ssl module (as we done for certificates for
> HTTPS).

Most ssl-using modules won't give the user access to such settings.
Besides, you can't expect someone using urllib.request() to know which
ciphers should be disabled. The library (either ssl or urllib or
http.client) should choose the right defaults.

I agree about documenting it in any case. But that doesn't mean we
shouldn't *also* set a reasonable default.