On Sat, 10 Sep 2016 16:22:57 +0200 Christian Heimes <christ...@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. _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com