[Python-Dev] Let's make the SSL module sane (original) (raw)

Antoine Pitrou solipsis at pitrou.net
Mon Sep 12 07:57:57 EDT 2016

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(PROTOCOLSSLv23) secure bu default. Changelog: The context is created with more secure default values. The options OPNOCOMPRESSION, OPCIPHERSERVERPREFERENCE, OPSINGLEDHUSE, OPSINGLEECDHUSE, OPNOSSLv2 (except for PROTOCOLSSLv2), and OPNOSSLv3 (except for PROTOCOLSSLv3) are set by default. The initial cipher suite list contains only HIGH ciphers, no NULL ciphers and MD5 ciphers (except for PROTOCOLSSLv2).

+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 PROTOCOLSSLv23). My patch #26470 added PROTOCOLTLS as alias for PROTOCOLSSLv23. If the last idea is accepted I will remove PROTOCOLTLS again. It hasn't been released yet. Instead I'm going to add PROTOCOLTLSCLIENT and PROTOCOLTLSSERVER (see https://www.openssl.org/docs/manmaster/ssl/SSLCTXnew.html TLSservermethod(), TLSclientmethod()). PROTOCOLTLSCLIENT is like PROTOCOLSSLv23 but only supports client-side sockets and PROTOCOLTLSSERVER 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 PROTOCOLTLSCLIENT and PROTOCOLTLSSERVER.

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.

More information about the Python-Dev mailing list