Unable to use TLSv1.1 or 1.2 with OpenSSL compat layer

[Simon Déziel]

[Impact]

Applications using GnuTLS OpenSSL compat layer [1] are be unable to use modern TLS versions (1.1 and 1.2) when relying on the SSLv23_{client,server}_method functions.

There is an industry-wide push to use modern TLS versions, see [2] and [3] for example.

The proposed fix changes the compat layer to use GnuTLS' "NORMAL" priority [4] instead of hard-coding which protocol versions and ciphers to enable.

[Test Case]

1) Setup a mail submission server that uses StartTLS
2) Setup sSMTP (uses GnuTLS OpenSSL compat layer) to relay
   through the mail relay using StartTLS
3) Send an email while capturing with tcpdump/tshark
4) Inspect the submission connection (TCP/587) and look for the protocol
   version negotiated by the client.

Without the fix, you should see TLSv1.0. With the fix, it should be TLSv1.2.

Please see the original issue description for more details.

[Regression Potential]

Regression risk should be low since it's a backport of a simple fix that landed in Debian in April 2017.

[References]

1: $ apt-cache rdepends libgnutls-openssl27
libgnutls-openssl27
Reverse Depends:
  libgnutls-dev
  libgnutls-dev
  zoneminder
  yaskkserv
  tf5
  ssmtp
  snowdrop
  sngrep
  slrnpull
  slrn
  sipsak
  macopix-gtk2
  gnss-sdr
  gkrellm
  freewheeling
  boinctui
  iputils-ping

2: https://lists.debian.org/debian-devel-announce/2017/08/msg00004.html
3: https://blog.pcisecuritystandards.org/migrating-from-ssl-and-early-tls
4: https://gnutls.org/manual/html_node/Priority-Strings.html

[Original issue description]

sSMTP is limited to using TLSv1.0 and the "old" ciphers that come with it. Here's a packet capture when ssmtp connects to smtp.sdeziel.info:587 that offers TLSv1.0 and higher:

$ tshark -ta -Vr submission.pcap | sed -n '/^Frame 14:/,/^Frame 15:/ p' | grep -E '^[[:space:]]+(Version|Cipher|Handshake Protocol)'
        Version: TLS 1.0 (0x0301)
        Handshake Protocol: Client Hello
            Version: TLS 1.0 (0x0301)
            Cipher Suites Length: 30
            Cipher Suites (15 suites)
                Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)
                Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035)
                Cipher Suite: TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (0x0041)
                Cipher Suite: TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (0x0084)
                Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a)
                Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033)
                Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039)
                Cipher Suite: TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (0x0045)
                Cipher Suite: TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (0x0088)
                Cipher Suite: TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (0x0016)
                Cipher Suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA (0x0032)
                Cipher Suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA (0x0038)
                Cipher Suite: TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA (0x0044)
                Cipher Suite: TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA (0x0087)
                Cipher Suite: TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA (0x0013)

I would expect ssmtp to use TLSv1.2 and a recent cipher like the openssl s_client is able to do:

$ echo | openssl s_client -connect smtp.sdeziel.info:587 -starttls smtp 2>/dev/null | grep -E '^[[:space:]]+(Protocol|Cipher)'
    Protocol : TLSv1.2
    Cipher : ECDHE-RSA-AES128-GCM-SHA256

Additional information:

$ lsb_release -rd
Description: Ubuntu 16.04.3 LTS
Release: 16.04
$ apt-cache policy ssmtp libgnutls-openssl27
ssmtp:
  Installed: 2.64-8ubuntu1
  Candidate: 2.64-8ubuntu1
  Version table:
 *** 2.64-8ubuntu1 500
        500 http://archive.ubuntu.com/ubuntu xenial/universe amd64 Packages
        100 /var/lib/dpkg/status
libgnutls-openssl27:
  Installed: 3.4.10-4ubuntu1.3
  Candidate: 3.4.10-4ubuntu1.3
  Version table:
 *** 3.4.10-4ubuntu1.3 500
        500 http://archive.ubuntu.com/ubuntu xenial-updates/main amd64 Packages
        500 http://security.ubuntu.com/ubuntu xenial-security/main amd64 Packages
        100 /var/lib/dpkg/status
     3.4.10-4ubuntu1 500
        500 http://archive.ubuntu.com/ubuntu xenial/main amd64 Packages

ProblemType: Bug
DistroRelease: Ubuntu 16.04
Package: ssmtp 2.64-8ubuntu1 [modified: etc/ssmtp/revaliases]
ProcVersionSignature: Ubuntu 4.4.0-89.112-generic 4.4.76
Uname: Linux 4.4.0-89-generic x86_64
ApportVersion: 2.20.1-0ubuntu2.10
Architecture: amd64
Date: Mon Aug 7 18:13:33 2017
ProcEnviron:
 TERM=xterm
 PATH=(custom, no user)
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: ssmtp
UpgradeStatus: No upgrade log present (probably fresh install)
modified.conffile..etc.ssmtp.revaliases: [modified]
mtime.conffile..etc.ssmtp.revaliases: 2017-08-05T13:44:06.274302

[Simon Déziel (sdeziel)]

There is a Debian patch (debian/patches/01-374327-use-gnutls.patch) that changed ssmtp to link with GnuTLS OpenSSL compat layer. If I drop this patch and link with "-lssl -lcrypto", ssmtp has no problem using TLSv1.2 and AES GCM:

$ tshark -ta -Vr submission-openssl.pcap | sed -n '/^Frame 11:/,/^Frame 12:/ p' | grep -E '^[[:space:]]+(Version|Cipher|Handshake Protocol)'
        Version: TLS 1.0 (0x0301)
        Handshake Protocol: Client Hello
            Version: TLS 1.2 (0x0303)
            Cipher Suites Length: 170
            Cipher Suites (85 suites)
                Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)
                ...
                Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)
                ...
                Cipher Suite: TLS_EMPTY_RENEGOTIATION_INFO_SCSV (0x00ff)

[Simon Déziel (sdeziel)]

After some research, I found this GnuTLS bug https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=857436 and it's accompanying changelog:

   * OpenSSL wrapper: SSLv23_*_method translates to NORMAL GnuTLS priority,
     which includes TLS1.2 support. Closes: #857436

Maybe it's more an GnuTLS issue than a ssmtp one.

[Simon Déziel (sdeziel)]

I'm attaching a debdiff for gnutls28 from Xenial. It worked in my tests to have ssmtp use TLSv1.2.

I'll try to provide a debdiff for Artful as well.

[Ubuntu Foundations Team Bug Bot (crichton)]

The attachment "lp1709193-16.04.debdiff" seems to be a debdiff. The ubuntu-sponsors team has been subscribed to the bug report so that they can review and hopefully sponsor the debdiff. If the attachment isn't a patch, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are member of the ~ubuntu-sponsors, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issue please contact him.]

[Marc Deslauriers (mdeslaur)]

ACK on the artful debdiff. I've uploaded it now with a slight adjustment to put the bug numbers in the patch tags. Thanks!

[Marc Deslauriers (mdeslaur)]

ACK on the trusty, xenial and zesty debdiffs. Uploaded for processing by the SRU team. Thanks!

[Launchpad Janitor (janitor)]

This bug was fixed in the package gnutls28 - 3.5.8-6ubuntu2

---------------
gnutls28 (3.5.8-6ubuntu2) artful; urgency=medium

  * use_normal_priority_for_openssl_sslv23.diff by Andreas Metzler:
    OpenSSL wrapper: SSLv23_*_method translates to NORMAL GnuTLS priority,
    which includes TLS1.2 support. (LP: #1709193)

 -- Simon Deziel <email address hidden> Thu, 10 Aug 2017 00:34:06 +0000

[Brian Murray (brian-murray)]

Hello Simon, or anyone else affected,

Accepted gnutls28 into zesty-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/gnutls28/3.5.6-4ubuntu4.2 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed.Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-zesty to verification-done-zesty. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-zesty. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

[Brian Murray (brian-murray)]

Hello Simon, or anyone else affected,

Accepted gnutls28 into xenial-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/gnutls28/3.4.10-4ubuntu1.4 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed.Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-xenial to verification-done-xenial. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-xenial. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

[Brian Murray (brian-murray)]

Hello Simon, or anyone else affected,

Accepted gnutls26 into trusty-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/gnutls26/2.12.23-12ubuntu2.9 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed.Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-trusty to verification-done-trusty. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-trusty. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

[Simon Déziel (sdeziel)]

Verified on Xenial with:

$ apt-cache policy libgnutls-openssl27:amd64
libgnutls-openssl27:
  Installed: 3.4.10-4ubuntu1.4
  Candidate: 3.4.10-4ubuntu1.4
  Version table:
 *** 3.4.10-4ubuntu1.4 500
        500 http://archive.ubuntu.com/ubuntu xenial-proposed/main amd64 Packages
        100 /var/lib/dpkg/status
     3.4.10-4ubuntu1.3 500
        500 http://archive.ubuntu.com/ubuntu xenial-updates/main amd64 Packages
        500 http://security.ubuntu.com/ubuntu xenial-security/main amd64 Packages
     3.4.10-4ubuntu1 500
        500 http://archive.ubuntu.com/ubuntu xenial/main amd64 Packages

[Simon Déziel (sdeziel)]

Verified on Zesty with:

$ apt-cache policy libgnutls-openssl27:amd64
libgnutls-openssl27:
  Installed: 3.5.6-4ubuntu4.2
  Candidate: 3.5.6-4ubuntu4.2
  Version table:
 *** 3.5.6-4ubuntu4.2 500
        500 http://archive.ubuntu.com/ubuntu zesty-proposed/main amd64 Packages
        100 /var/lib/dpkg/status
     3.5.6-4ubuntu4.1 500
        500 http://archive.ubuntu.com/ubuntu zesty-updates/main amd64 Packages
        500 http://security.ubuntu.com/ubuntu zesty-security/main amd64 Packages
     3.5.6-4ubuntu4 500
        500 http://archive.ubuntu.com/ubuntu zesty/main amd64 Packages

[Simon Déziel (sdeziel)]

The trusty-proposed version (2.12.23-12ubuntu2.9) doesn't work and introduces a regression preventing successful TLS/SSL connections. I'll check if there is an easy fix for gnutls26.

[Simon Déziel (sdeziel)]

On Truty with 2.12.23-12ubuntu2.9, the sSMTP client would abort the StartTLS connection complaining it didn't support the signature algorithm in use.

When validating I used a mail relay with a RSA-SHA256 cert signed by CAcert.org. CAcert.org is (self-signed) RSA-MD5. It turned out that Trusty also needed the GnuTLS priority string to include %VERIFY_ALLOW_SIGN_RSA_MD5 to support that use case and avoid the regression. It's unclear to me why only gnutls26 needed this since I used the exact same test case for all 3 distro versions.

The version 2 of the debdiff for Trusty was tested with certificates chains including MD5, SHA1 and SHA256 certificates and revealed no problem and fixed the regression previously found.

[Launchpad Janitor (janitor)]

This bug was fixed in the package gnutls28 - 3.5.6-4ubuntu4.2

---------------
gnutls28 (3.5.6-4ubuntu4.2) zesty; urgency=medium

  * use_normal_priority_for_openssl_sslv23.diff by Andreas Metzler:
    OpenSSL wrapper: SSLv23_*_method translates to NORMAL GnuTLS priority,
    which includes TLS1.2 support. (LP: #1709193)

 -- Simon Deziel <email address hidden> Thu, 10 Aug 2017 12:47:14 +0000

[Andy Whitcroft (apw)]

The verification of the Stable Release Update for gnutls28 has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

[Julian Andres Klode (juliank)]

So, I believe the proposed 2nd trusty might accidentally allow MD5 everywhere, when the problem only is root certificates with MD5 self signatures. I believe this might be related:

https://gitlab.com/gnutls/gnutls/commit/b93ae1abf1b84fdc094f2474f1b2e4848081810e

But I'm not sure if it fixes the issue and if any other patches are needed from 2.12.24.

[Andy Whitcroft (apw)]

@ubuntu-security -- could we have an oppinion on this patch which is enabling %VERIFY_ALLOW_SIGN_RSA_MD5 for trusty. Looking to understand if this is overly broad and therefore a security issue.

[Simon Déziel (sdeziel)]

It's been a while since the Xenial -proposed package have been successfully validated. Is there anything preventing it from entering -updates?

[Tyler Hicks (tyhicks)]

@sdeziel ubuntu-security was asked to comment on it a few days ago. I've just freed up enough to take a look.

[Tyler Hicks (tyhicks)]

Ignore my last comment. You were asking about Xenial but it was the Trusty SRU that was blocked on ubuntu-security review.

[Simon Déziel (sdeziel)]

The Xenial fix is identical to what went in Artful and Zesty so it shouldn't be subject to any more review.

The review was requested to check if the different fix proposed for Trusty was OK.

[Julian Andres Klode (juliank)]

@sdeziel we just hurried the zesty one up yesterday to make place for a new SRU in zesty. And now it is weekend, and I'm not sure, but I don't think updates are released during weekends. You could try pinging in #ubuntu-release on Monday.

[Julian Andres Klode (juliank)]

@sdeziel One problem here probably being that the updates are stuck due to reverse dependencies failing autopkgtest and you not convincing people that these failures are unrelated. If you don't push hard on that kind of stuff, nothing really happens.

[Simon Déziel (sdeziel)]

@juliank, thanks for the update. I wasn't aware of the autopkgtest failing for some reverse dependencies. Any pointers to those? I'm determined to see this one though, but on Monday ;)

[Julian Andres Klode (juliank)]

If you look at http://people.canonical.com/~ubuntu-archive/proposed-migration/xenial/update_excuses.html#gnutls28 you'll see that aria2 failed on armhf, and network-manager on amd64.

network-manager looks like a temporary failure, I just retried that; and aria2 - well, it fails to read CA certificates, I'm not sure why, but that seems unrelated too. I just retried it, maybe it works now; but maybe it's a bug in aria2 missing a test dependency.

[Julian Andres Klode (juliank)]

You can also look at http://people.canonical.com/~ubuntu-archive/pending-sru.html of course, that lists all SRUs in any -proposed suite and mention regressions in autopkgtest in the left column.

[Simon Déziel (sdeziel)]

I see the NM one passes now, thanks for retrying it. The aria2 armhf problem reliably fails though. I guess I'll have to setup a QEMU VM for that arch and manually run the test to see what's going on.

[Tyler Hicks (tyhicks)]

I agree with juliank's assessment in comment #22. The 2nd Trusty debdiff allows md5 to be used throughout the entire cert chain which is apparently not what Simon intended. I don't think it is the right approach.

[Robie Basak (racb)]

Driving through with my SRU hat.

Regression Potential of "None" or "Low" is unacceptable. Please review https://wiki.ubuntu.com/StableReleaseUpdates#Procedure.

How will you test that this doesn't impact protocol negotiation unrelated to this bug (ie. unaffected users)?

Is Tyler's comment 34 a -1 for the SRU upload sitting in the Trusty queue? Any response to that? If I'm not mistaken, that should mean that I should reject this upload?

[Simon Déziel (sdeziel)]

I couldn't reproduce/address the problems found by autopkgtests so please reject the Trusty/Xenial uploads, thanks.

[Julian Andres Klode (juliank)]

Not the xenial one, that should be fine IIRC (unrelated autopkgtest failures) . We ship the same patch in zesty, and Debian ships it in stretch.

[Julian Andres Klode (juliank)]

Regarding regressions: I believe that the "soak testing" of the fix in stretch and zesty gives a reasonable indication that this works fine for normal users (or nobody uses it...). There can be regressions of course, but this essentially makes the behaviour of the compat bindings equivalent to the normal gnutls behaviour.

In any case, regressions could happen for TLS 1.0 servers. That said, any regression should be very limited considering that servers often do not negotiate that any more and that TLS 1.0 is horribly insecure.

[Julian Andres Klode (juliank)]

For xenial we shoulf just need to add ca-certificates to the test reps of aria2 to make it workm

[Simon Déziel (sdeziel)]

Julian, that sounds promising as the other arches seem to have ca-certificates installed due to other dependencies which could well explain the armhf-only failure.

[Simon Déziel (sdeziel)]

I've been experimenting with aria2's httpfile test and not having ca-certificates logs an error but that's not fatal. What I think is the problem is that armhf is just too slow to start the python HTTP server which explains the "Exception: [AbstractCommand.cc:869] errorCode=1 Failed to establish connection, cause: Connection refused". I can reproduce this error by removing the "sleep 2" in the test on amd64 Xenial.

[Simon Déziel (sdeziel)]

I reported my finding and proposed a patch to aria2 in Debian [1]. Since aria2 has no delta with Debian, I'd like to know what to do from here, assuming that my theory of armhf being too slow is sound.

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=878253

[Łukasz Zemczak (sil2100)]

I see your patch got approved and released in Debian. I would propose syncing it into bb when it opens and then backporting to xenial. I ran an autopkgtest of aria2 without the new gnutls28 and the failure is not present there on armhf, so I'd prefer having it fixed if possible before releasing to -updates.

[Launchpad Janitor (janitor)]

This bug was fixed in the package gnutls28 - 3.4.10-4ubuntu1.4

---------------
gnutls28 (3.4.10-4ubuntu1.4) xenial; urgency=medium

  * use_normal_priority_for_openssl_sslv23.diff by Andreas Metzler:
    OpenSSL wrapper: SSLv23_*_method translates to NORMAL GnuTLS priority,
    which includes TLS1.2 support. (LP: #1709193)

 -- Simon Deziel <email address hidden> Mon, 07 Aug 2017 23:04:43 +0000

[Simon Déziel (sdeziel)]

Version 2.12.23-12ubuntu2.9 in trusty-proposed introduced regressions in autopkgtests and was marked as verification-failed-trusty. There is no clear way forward and I don't have more time to put into this. As such, would it be possible to drop the package from trusty-proposed, please?

[Timo Aaltonen (tjaalton)]

there's a new upload for trusty, for bug 1444656

closing this one