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

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)

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.

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.

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

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

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

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

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!

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!

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!

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

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

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.

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.

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

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.

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.

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

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

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

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

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.

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

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

@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 ;)

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.

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.

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.

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.

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?

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

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.

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.

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

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.

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.

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

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.

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

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?

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

closing this one