Author christian.heimes
Recipients christian.heimes
Date 2016-09-11.21:54:39
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1473630879.3.0.622304028726.issue28085@psf.upfronthosting.co.za>
In-reply-to
Content
In ticket #28022 and in thread https://mail.python.org/pipermail/python-dev/2016-September/146366.html I discussed two new protocols for SSLContext: PROTOCOL_TLS_CLIENT and PROTOCOL_TLS_SERVER. A SSLContext with PROTOCOL_TLS_CLIENT can only create connections to a server but cannot wrap server sockets. We can use it to have better defaults (e.g. cert validation and hostname verification for client side) and to make it impossible to confuse a server context with a client context. In the long run I'm planning to deprecate all but PROTOCOL_TLS_CLIENT and PROTOCOL_TLS_SERVER.

---
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.
---
History
Date User Action Args
2016-09-11 21:54:39christian.heimessetrecipients: + christian.heimes
2016-09-11 21:54:39christian.heimessetmessageid: <1473630879.3.0.622304028726.issue28085@psf.upfronthosting.co.za>
2016-09-11 21:54:39christian.heimeslinkissue28085 messages
2016-09-11 21:54:39christian.heimescreate