[SRU] OpenSSL 1.1.1 to 18.04 LTS

Bug #1797386 reported by Dimitri John Ledkov on 2018-10-11
This bug affects 58 people
Affects Status Importance Assigned to Milestone
openssl (Ubuntu)

Bug Description


 * 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

[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.

[Other Info]

 * Previous FFe for OpenSSL in 18.10 is at

 * 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

tags: added: bionic
summary: - SRU OpenSSL 1.1.1 to 18.04 LTS
+ [SRU] OpenSSL 1.1.1 to 18.04 LTS
description: updated
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in openssl (Ubuntu):
status: New → Confirmed
Sven Neuhaus (sven0) wrote :

I'm very much in favor of this.

Does this imply an update to Apache 2.4.37, too? (see https://github.com/apache/httpd/blob/2.4.x/CHANGES)

Giraffe (dodger-forum) wrote :

I would love to be able to Use OpenSSL 1.1.1 (TLS 1.3) with Apache2 on 18.04 LTS.

Marc Peña (pachulo) wrote :

Any news on this? Thanks!

Dimitri John Ledkov (xnox) wrote :

Here is a quick update on this SRU.

Bringing in Apache support is currently not in scope. However, this can be investigated separately and possibly would most likely look like a targetted backport of mod_ssl, rather than a full upgrade of all of the apache2. But again only after OpenSSL 1.1.1 SRU is completed.

It is investigated to bring OpenSSH compiled against libcrypto 1.1.1 support. But again only after OpenSSL 1.1.1 SRU is complete.

The current goal is to SRU OpenSSL 1.1.1 without causing any regressions to the dependent packages, which is quite a large task. In practice that does mean enabling TLS1.3 support in a few packages that are affected by the new handshake.

As stated, this SRU is being staged https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/3473 possibly with a better stage page of the currently expected runtime regressions as shown at this page https://bileto.ubuntu.com/excuses/3473/bionic.html

As you can see there, this upgrade cannot land until after relevant python/perl/ruby/R changes are also brought in. Python stack is mostly ready now, the others will be quite easier to test and land.

If you can, I do urge you to test https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/3473 PPA on bionic with your workloads to spot breakage, incompatibility, and/or any unexpected connectivity issues (client<->server protocol negotiation failures).

My personal goal is to land this in time / well ahead of the next bionic point release (currently penciled in for 7th February). But this is not a guarantee or a firm commitment that one can bank on.

I hope this update helps.

Matt Ruffalo (mruffalo) wrote :

Thank you very much, Dimitri -- I am interested in this also.

I tested that PPA on a test web server running nginx, uwsgi, uwsgi-plugin-python3, Django 1.11(.16), and a Python 3.6 'pyvenv' virtual environment using 'psycopg2' to connect to a PostgreSQL 10 server via the pre-built Python wheel for 'psycopg2_binary' version 2.7.5.

I could immediately connect to nginx over TLS 1.3 without any problems, and the Qualys SSL Labs scan also reported that all was well with TLS 1.3.

However, the web app under uwsgi crashed (segfaulted) on any request, with a stack trace at https://pastebin.com/DLGiuKfR

I was relatively surprised that the 'psycopg2_binary' Python wheel seemed to bundle its own version of libssl-8bb9b3dd.so.1.0.2o -- and it looks like there's some incompatibility with this build of Python and OpenSSL 1.1.1. I removed this Python package and installed 'psycopg2' instead, and saw the same behavior.

I was able to fix this by reinstalling psycopg2 from source with 'pip install --no-binary=":all:" psycopg2', and now everything works well with the web app.

I'm not sure how much of a problem this is at this stage, or who has the responsibility to address it (Ubuntu developers or whoever built the psycopg2 wheel), but I figured I may as well mention this anyway.

It's great that everything was fine with nginx without any effort on my part; thanks!

description: updated
Dimitri John Ledkov (xnox) wrote :


This is about distribution provided packages only, installed system-wide. Not about binaries side installed from wheels from third-party providers. Can you test using
   $ sudo apt install python3-psycopg2

Without any wheels installed from pypi...

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers