[Python-Dev] Let's make the SSL module sane

[Antoine Pitrou]

On Sat, 10 Sep 2016 16:22:57 +0200
Christian Heimes <christian at python.org> wrote:
> 
> For 3.6 I like to make the SSL more sane and more secure by default.
> Yes, I'm a bit late but all my proposals are implemented, documented,
> partly tested and  existing tests are passing.

I don't have time nor motivation to review most of them, but I trust
you that the implementations are sane :-)

> First I like to deprecated some old APIs and favor of SSLCotext.

This has always been the plan (to me), so a big +1.

> The patch
> also deprecates certfile, keyfile an similar arguments in network
> protocol libraries.

+1.

> I also considered to make cert validation enabled by default for all
> protocol in 3.6, Victor has rising some concerns.

I assume you mean "in client mode". I think that sounds fine nowadays.
If people haven't configured a set of trusted CAs properly, this should
error out immediately, so they would notice it quickly IMHO.

(in other words, +0.5)

> How about we change
> the behavior in 3.7 and just add a warning to 3.6?

As you (or others) prefer :-)

> Next up SSLContext default configuration. A bare SSLContext comes with
> insecure default settings. I'd like to make SSLContext(PROTOCOL_SSLv23)
> secure bu default. Changelog: The context is created with more secure
> default values. The options OP_NO_COMPRESSION,
> OP_CIPHER_SERVER_PREFERENCE, OP_SINGLE_DH_USE, OP_SINGLE_ECDH_USE,
> OP_NO_SSLv2 (except for PROTOCOL_SSLv2), and OP_NO_SSLv3 (except for
> PROTOCOL_SSLv3) are set by default.
> The initial cipher suite list
> contains only HIGH ciphers, no NULL ciphers and MD5 ciphers (except for
> PROTOCOL_SSLv2).

+1 to all this from me.  The ship has sailed on most of this stuff
already.

> Finally (and this is the biggest) I like to change how the protocols
> work. OpenSSL 1.1.0 has deprecated all version specific protocols. Soon
> OpenSSL will only support auto-negotiation (formerly known as
> PROTOCOL_SSLv23). My patch #26470 added PROTOCOL_TLS as alias for
> PROTOCOL_SSLv23. If the last idea is accepted I will remove PROTOCOL_TLS
> again. It hasn't been released yet. Instead I'm going to add
> PROTOCOL_TLS_CLIENT and PROTOCOL_TLS_SERVER (see
> https://www.openssl.org/docs/manmaster/ssl/SSL_CTX_new.html
> TLS_server_method(), TLS_client_method()). PROTOCOL_TLS_CLIENT is like
> PROTOCOL_SSLv23 but only supports client-side sockets and
> PROTOCOL_TLS_SERVER just server-side sockets. In my experience we can't
> have a SSLContext with sensible and secure settings for client and
> server at the same time. Hostname checking and cert validation is only
> sensible for client-side sockets.

This sounds reasonable.  No strong opinion from me but +0.5 as well.

> Starting in 3.8 (or 3.7?) there will be only PROTOCOL_TLS_CLIENT and
> PROTOCOL_TLS_SERVER.

You *may* provide the old constants for compatibility, though (meaning
"PROTOCOL_TLS", roughly).

> How will my proposals change TLS/SSL code?
> 
> Application must create a SSLContext object. Applications are
> recommended to keep the context around to benefit from session reusage
> and reduce overload of cert parsing.

(well, most applications are advised to use an intermediate layer such
as httplib ;-))

> I hope this mail makes sense.

It does to me!

Regards

Antoine.