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. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssl in Ubuntu. https://bugs.launchpad.net/bugs/1797386 Title: [SRU] OpenSSL 1.1.1 to 18.04 LTS Status in openssl package in Ubuntu: Fix Released Status in libio-socket-ssl-perl source package in Bionic: Incomplete Status in libnet-ssleay-perl source package in Bionic: Incomplete Status in nova source package in Bionic: New Status in openssl source package in Bionic: Fix Committed Status in python-cryptography source package in Bionic: Fix Committed Status in python2.7 source package in Bionic: Fix Committed Status in python3.6 source package in Bionic: Fix Committed Status in python3.7 source package in Bionic: Fix Committed Status in r-cran-openssl source package in Bionic: Fix Committed Status in ruby-openssl source package in Bionic: Fix Committed Status in ruby2.5 source package in Bionic: New Bug description: [Impact] * OpenSSL 1.1.1 is an LTS release upstream, which will continue to receive security support for much longer than 1.1.0 series will. * OpenSSL 1.1.1 comes with support for TLS v1.3 which is expected to be rapidly adopted due to increased set of supported hashes & algoes, as well as improved handshake [re-]negotiation. * OpenSSL 1.1.1 comes with improved hw-acceleration capabilities. * OpenSSL 1.1.1 is ABI/API compatible with 1.1.0, however some software is sensitive to the negotiation handshake and may either need patches/improvements or clamp-down to maximum v1.2. [Test Case] * Rebuild all reverse dependencies * Execute autopkg tests for all of them * Clamp down to TLS v1.2 software that does not support TLS v1.3 (e.g. mongodb) * Backport TLS v1.3 support patches, where applicable [Test cases for the python updates] python3.7 is a preview in bionic as a non-supported/non-default version of python3. Passing it's own autopkgtests is sufficient validation for python3.7. It includes a point release update, with OpenSSL 1.1.1 compat and features. python3.6 not only has OpenSSL 1.1.1 compat and features patches, but also includes a point release update to 3.6.8. It has been part of the full-archive rebuild and regression analysis. Autopkgtests were triggered for python3.6 and python3-defaults with regressions already fixed in the individual packages as appropriate. python2.7 has the update from .15~rc1 to .15 final, with OpenSSL 1.1.1 compat only. It has been part of the full-archive rebuild and regression analysis. Autopkgtests were triggered for python2.7 and python-defaults with regressions already fixed in the individual packages as appropriate. The archive rebuilds done, were commulative with OpenJDK 11, OpenSSL 1.1.1 and python point releases as seen in: http://people.canonical.com/~doko/ftbfs-report/test-rebuild-20181222-bionic.html http://people.canonical.com/~doko/ftbfs-report/test-rebuild-20181222-test-bionic.html And analyzed in https://docs.google.com/spreadsheets/d/1tMIwlwoHH_1h5sbvUbNac6-HIPKi3e0Xr8ebchIOU1A/edit#gid=147857652 [Regression Potential] * Connectivity interop is the biggest issues which will be unavoidable with introducing TLS v1.3. However, tests on cosmic demonstrate that curl/nginx/google-chrome/mozilla-firefox connect and negotiate TLS v1.3 without issues. * Mitigation of discovered connectivity issues will be possible by clamping down to TLS v1.2 in either server-side or client-side software or by backporting relevant support fixes * Notable changes are listed here https://wiki.openssl.org/index.php/TLS1.3 * Most common connectivity issues so far: - client verifies SNI in TLSv1.3 mode, yet client doesn't set hostname. Solution is client change to set hostname, or to clamp down the client to TLSv1.2. - session negotiation is different in TLSv1.3, existing client code may fail to create/negotiate/resume session. Clients need to learn how to use session callback. * This update bundles python 3.6 and 3.7 point releases [Other Info] * Previous FFe for OpenSSL in 18.10 is at https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1793092 * TLS v1.3 support in NSS is expected to make it to 18.04 via security updates * TLS v1.3 support in GnuTLS is expected to be available in 19.04 * Test OpenSSL is being prepared in https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/3473 [Autopkgtest Regressions] dovecot/armhf - flakey libnet-ssleay-perl - awaiting sru accept into proposed of libnet-ssleay-perl and libio-socket-ssl-perl due to fixes and versioned breaks. linux* - rebuild testcases passes (for some edge flavours the build fails in non-ssl portions of the build), ubuntu-regression-suite testcase fails for a few variants but should have been skipped (in progress to be fixed in https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1823056) openvswitch/i386 - extremely flakey, errors out or fails mostly To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1797386/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
