[Bug 1797386] Re: [SRU] OpenSSL 1.1.1 to 18.04 LTS

Fri Apr 26 10:42:00 UTC 2019

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
Foundations Bugs, 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