Comment 31 for bug 1797386

libnet-ssleay-perl 1.86 is currently at beta9 and that version implements more comprehensive support for tls 1.3, including for example exposing APIs needed to implement post-handshake-authentication (changing client/server certs, post establishing a session, without establishing a new session/connection)

In libio-socket-ssl-perl support for tls 1.3 / openssl 1.1.1 is implemented with caveats - session resume is not available, and post-handshake-authentication is not available either. Meaning, one should establish a new session, instead of able to use faster code paths and use post-handshake-authentication or key update APIs.

The extra guards are due to changes in the runtime expectations / autopkgtests, since when the stack is built against 1.1.1, rather than just 1.1.0, tls1.3 becomes available. It is true that strictly the run time dep of 1.1.0 is sufficient.

npn is the old and withdrawn extension. It is superseeded by ALPN, published in 2014. npn is ill-defined, is neither widely used nor deployed anymore. The npn extension is obsolete, and will not be implemented with tls1.3. http/2 and ALPN is the future. Existing users on tls v1.2 can however continue to use it, as support for this extension is not removed with older tls.

Wrt. ecdhe test, the change is correct. TLS 1.3 specifies a small list of ECDHE and DHE supported groups, which are client-side authoritatitve instead of server side. Although server is allowed to send/advertise these, client must not act upon such information until after a completed handshake. Thus there is no point in testing whether or not the server advertises ECDHE curves, since with TLS 1.3 it is pointless. https://tools.ietf.org/html/rfc8446#section-4.2.7

In terms of regression risk, most of it is mitigated for the application - all existing APIs continue to work, but may result in different behavior when operating on an TLS1.3 connection. For example, calls to SSL_get1_session() continue to work, but upon resume instead of resuming a session, a new session is established because TLS1.3. See for example https://wiki.openssl.org/index.php/TLS1.3#Sessions for discussion around what the existing APIs did, and what the net effect is on a TLS1.3 connection. On the server side, one may observe a higher number of tls sessions from clients that attempt to reuse sessions "tls1.2-style" whilst operating on tls1.3 connections.

In terms of testing, autopkgtests are ok, but only test 1-2 level of dependencies, and do not end up triggering things that depend on for example libwww-perl which is what in fact would be interesting to see the results for. I am looking at reverse dependencies, but I don't see good client/server perl apps to test tls1.3 connectivity with in the archive.

Please note that these -perl packages were part of the full archive rebuild, along with the new openssl 1.1.1 and the new pythons.