<div dir="auto">my country, mauritius, had a participation in the dev,<div dir="auto"><br></div><div dir="auto">internet society vid :</div><div dir="auto"><a href="https://youtu.be/u6rz4PWA_As?t=4524">https://youtu.be/u6rz4PWA_As?t=4524</a></div><div dir="auto"><br></div><div dir="auto">the red blue yellow green flag is our flag<br><br><div data-smartmail="gmail_signature" dir="auto">Abdur-Rahmaan Janhangeer<br><a href="https://github.com/Abdur-rahmaanJ">https://github.com/Abdur-rahmaanJ</a><br>Mauritius</div></div></div><br><div class="gmail_quote"><div dir="ltr">On Thu, 16 Aug 2018, 17:27 Christian Heimes, <<a href="mailto:christian@python.org">christian@python.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
I have some exciting news. RFC 8446 [1] for TLS 1.3 was finalized a<br>
couple of days ago. The new TLS standard comes with several major<br>
improvements, but also with major changes.<br>
<br>
First some good news:<br>
Python's ssl module not compiles with OpenSSL 1.1.1-pre. It's also able<br>
to negotiate and establish TLS 1.3 connections successfully. Almost all<br>
unit tests are passing, too. Yesterday I pushed some patches to fix 2.7,<br>
3.6, 3.7, and master.<br>
<br>
Of course, there is a catch. While TLS 1.0 to 1.2 were just gradual<br>
improvements over SSLv3, TLS 1.3 behaves differently on several levels.<br>
The article [2] from Nick Sullivan explains the biggest changes well.<br>
Most improvements like 1-RTT handshake, enforced perfect forward secrecy<br>
and improved cryptography are not visible to applications. However some<br>
changes and new features are going to need additional work and new APIs.<br>
<br>
I'm open to discuss the matter at the core dev sprints in Seattle next<br>
month.<br>
<br>
I'm still in the process of reviewing and assessing changes. OpenSSL<br>
1.1.1's APIs are not finalized yet, too. I'm working closely with Red<br>
Hat's crypto team and OpenSSL devs on the topic. I'll walk you through<br>
some changes and possibly new APIs that I have identified so far.<br>
<br>
<br>
New cipher suites<br>
=================<br>
<br>
Old ciphers suites in TLS 1.2 and earlier looked like<br>
<br>
   TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384<br>
<br>
The parameters are key agreement/key exchange (ECDHE), authentication<br>
(RSA), bulk encryption (AES-256) with block and/or authenticated<br>
encryption mode (GCM) and finally a pseudo random function for MAC.<br>
<br>
In TLS 1.3, the cipher suites only specify bulk encryption and PRF. The<br>
parameters for key agreement and authentication are configured<br>
differently. TLS 1.3 uses dedicated TLS extensions for that, too. This<br>
allows more fine grained control to specific supported EC curves,<br>
signature algorithms (RSA PKCS#1.5, RSASSA-PSS) and so on. Some settings<br>
also apply to TLS 1.2 already.<br>
<br>
Further more, OpenSSL has introduced new APIs to configure TLS 1.3<br>
cipher suites. SSLContext.set_ciphers() cannot be used to disable TLS<br>
1.3 suites. For now, that is fine. All default algorithms are secure and<br>
state-of-the-art.<br>
<br>
For 3.8, I'm planning to make some of the settings configurable. I might<br>
need to backport the new APIs to 3.7 and 3.6, though.<br>
<br>
<br>
post handshake authentication<br>
=============================<br>
<br>
TLS 1.3 introduced the concept of post handshake authentication (PHA). A<br>
server can either request a client to provide client cert authentication<br>
during the handshake, directly after the handshake, or at any later<br>
point. It makes optional authentication for HTTP much more sane. For<br>
example a server may only require authentication for POST requests and<br>
GET requests to /secure/* path. In TLS 1.2, optional client cert auth<br>
requires a complete renegotiation of the handshake.<br>
<br>
OpenSSL 1.1.1-pre9 will most likely disable PHA by default [3], because<br>
PHA breaks some assumptions of TLS 1.2 clients and servers. But PHA<br>
might be required for path specific authentication. I need to wait and<br>
see how mod_ssl implements the feature.<br>
<br>
I might have to add SSL_VERIFY_POST_HANDSHAKE,<br>
SSL_verify_client_post_handshake(), and<br>
SSL_CTX_set_post_handshake_auth() from [3][4] to Python 2.7, 3.6, 3.7<br>
and master.<br>
<br>
<br>
session handling<br>
================<br>
<br>
TLS 1.3 uses a different approach to handle sessions. Simple speaking,<br>
session data is exchanged after the handshake, there can be more than<br>
one ticket, tickets must not be reused, and session resumption involved<br>
DHE. ssl.SSLSession [5] feature only applies to TLS 1.2 and earlier. I<br>
need to come up with a different approach here. For the time being, TLS<br>
1.3 won't be compatible with manual session control. It's not a big deal<br>
since it is an advanced feature any way.<br>
<br>
The new session system also seems to break FTP over TLS. FTP uses two<br>
different TCP connections (control channel, data channel). For FTP over<br>
TLS, the data channel must reuse a session of the control channel. For<br>
now, I'm plannung to restrict FTP to TLSv1.2.<br>
<br>
<br>
0-RTT resumption<br>
=================<br>
<br>
0 round trip time handshake on session resumption is an optional and<br>
advanced feature. I might expose the feature in Python 3.8.<br>
<br>
Regards,<br>
Christian<br>
<br>
<br>
[1] <a href="https://tools.ietf.org/html/rfc8446" rel="noreferrer noreferrer" target="_blank">https://tools.ietf.org/html/rfc8446</a><br>
[2] <a href="https://blog.cloudflare.com/rfc-8446-aka-tls-1-3/" rel="noreferrer noreferrer" target="_blank">https://blog.cloudflare.com/rfc-8446-aka-tls-1-3/</a><br>
[3] <a href="https://github.com/openssl/openssl/issues/6933" rel="noreferrer noreferrer" target="_blank">https://github.com/openssl/openssl/issues/6933</a><br>
[4] <a href="https://www.openssl.org/docs/man1.1.1/man3/SSL_CTX_set_verify.html" rel="noreferrer noreferrer" target="_blank">https://www.openssl.org/docs/man1.1.1/man3/SSL_CTX_set_verify.html</a><br>
[5] <a href="https://docs.python.org/3/library/ssl.html#ssl-session" rel="noreferrer noreferrer" target="_blank">https://docs.python.org/3/library/ssl.html#ssl-session</a><br>
<br>
_______________________________________________<br>
Python-Dev mailing list<br>
<a href="mailto:Python-Dev@python.org" target="_blank" rel="noreferrer">Python-Dev@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/python-dev" rel="noreferrer noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/python-dev</a><br>
Unsubscribe: <a href="https://mail.python.org/mailman/options/python-dev/arj.python%40gmail.com" rel="noreferrer noreferrer" target="_blank">https://mail.python.org/mailman/options/python-dev/arj.python%40gmail.com</a><br>
</blockquote></div>