GnuTLS TLS 1.2 handshake failure

Bug #1444656 reported by Robert Russo on 2015-04-15
This bug affects 12 people
Affects Status Importance Assigned to Milestone
gnutls26 (Ubuntu)

Bug Description

[ Impact ]
* GnuTLS fails to handshake using TLS 1.2 because of a protocol failure

[ Other info ]
I'm experiencing the same issue as here:

I came across a SSL handshake problem with gnutls-cli when connecting to
some websites, see below. It is somehow specific to gnutls as
openssl/Chrome/Firefox can connect fine.

Is this is a bug in gnutls or do you have any ideas how to troubleshoot it?

$ gnutls-cli --version
gnutls-cli (GnuTLS) 2.12.23
Packaged by Debian (2.12.23-12ubuntu2.1)

[ Test case ]
$ gnutls-cli
Resolving ''...
Connecting to ''...
*** Fatal error: A TLS fatal alert has been received.
*** Received alert [40]: Handshake failed
*** Handshake has failed
GnuTLS error: A TLS fatal alert has been received.

$ gnutls-cli
Resolving ''...
Connecting to ''...
*** Fatal error: A TLS packet with unexpected length was received.
*** Handshake has failed
GnuTLS error: A TLS packet with unexpected length was received.

[ Regression potential ]
* None, this is an upstream commit dated back 6 years ago, that trusty sadly missed

Thank you,

Please back port the latest GnuTLS to Trusty as it is an LTS release and clearly GnuTLS 2.12 is an old branch.

I've also attached packet captures of this.

Launchpad Janitor (janitor) wrote :

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

Micah Gersten (micahg) wrote :

This seems like a bug that should be fixed in the LTS rather than requesting a backport. The 3.2.11 version is available in trusty, but it's only community supported and doesn't have the utilities built since it's not the officially supported version. The version with 5 year support from Canonical is the old 2.12 version gnutls28 (3.2.11) has a lot of reverse dependencies, so a backport is non trivial. Let's see if the bug can be fixed in the older version.

Changed in gnutls26 (Ubuntu):
status: New → Confirmed
Micah Gersten (micahg) on 2015-05-29
affects: trusty-backports → gnutls26 (Ubuntu)
Changed in gnutls26 (Ubuntu):
status: New → Invalid
Changed in gnutls26 (Ubuntu Trusty):
status: New → Triaged
importance: Undecided → High
Robert Russo (rrusso) wrote :

This would be IDEAL if it were fixed in the LTS.

kenorb (kenorb) wrote :

This bug breaks MetaTrader 4 installation process under wine (
This sounds like some regression, as older TLS authentication worked fine.

js1 (sujiannming) wrote :
Download full text (5.0 KiB)

Update to libgnutls26-2.12.23-12ubuntu2.5 broke ldapsearch and Apache Directory Studio for me in particular. Whatever the previous version was worked fine. Now, when trying to connect via TLS or SSL to our ldap server, I get the following with gnutls-cli:

# gnutls-cli --print-cert -p 636
Connecting to ''...
*** Fatal error: A TLS packet with unexpected length was received.
*** Handshake has failed
GnuTLS error: A TLS packet with unexpected length was received.

But, works fine with openssl:

# openssl s_client -connect -CApath /etc/ssl/certs/
depth=3 C = SE, O = AddTrust AB, OU = AddTrust External TTP Network, CN = AddTrust External CA Root
verify return:1
depth=2 C = US, ST = New Jersey, L = Jersey City, O = The USERTRUST Network, CN = USERTrust RSA Certification Authority
verify return:1
depth=1 C = US, ST = MI, L = Ann Arbor, O = Internet2, OU = InCommon, CN = InCommon RSA Server CA
verify return:1
depth=0 C = US, postalCode = MyZip, ST = GA, L = MyTown, street = MyStreetAddress, O = MyOrg, CN =
verify return:1
Certificate chain
 0 s:/C=US/postalCode=MyZip/ST=MyState/L=MyTown/street=MyStreetAddress/O=MyOrg/CN=
   i:/C=US/ST=MI/L=Ann Arbor/O=Internet2/OU=InCommon/CN=InCommon RSA Server CA
 1 s:/C=US/ST=MI/L=Ann Arbor/O=Internet2/OU=InCommon/CN=InCommon RSA Server CA
   i:/C=US/ST=New Jersey/L=Jersey City/O=The USERTRUST Network/CN=USERTrust RSA Certification Authority
 2 s:/C=US/ST=New Jersey/L=Jersey City/O=The USERTRUST Network/CN=USERTrust RSA Certification Authority
   i:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root
Server certificate


js1 (sujiannming) wrote :

FWIW, our ldapserver uses the following, which gnutls26 does not support but gnutls30 in wily does:

- Status: The certificate is trusted.
- Successfully sent 0 certificate(s) to server.
- Description: (TLS1.2)-(ECDHE-RSA-SECP256R1)-(AES-256-CBC)-(SHA384)
- Session ID: 8C:43:00:00:5D:F2:98:2F:60:C7:A1:3A:C4:DA:D3:2D:A3:76:8F:6D:83:AE:AA:D6:6C:E3:90:E4:10:91:C0:AD
- Ephemeral EC Diffie-Hellman parameters
 - Using curve: SECP256R1
 - Curve size: 256 bits
- Version: TLS1.2
- Key Exchange: ECDHE-RSA
- Server Signature: RSA-SHA1
- Cipher: AES-256-CBC
- MAC: SHA384
- Compression: NULL
- Handshake was completed

Marc Deslauriers (mdeslaur) wrote :

It looks like the servers listed in the bug description require SIGN-RSA-SHA384, which gnutls26 doesn't support.

The issue can be reproduced with gnutls28 by disabling the additional signature algorithms:


Fixing this likely requires at least the following commit to be backported:

Samuel Leslie (sdl) wrote :

We encountered this bug today and it has the potential to be pretty nasty if you're unfortunate enough to hit it. In our case we have several systems which perform authentication against a Windows domain using LDAPS. We recently updated the TLS certificate on those systems and all the services which perform LDAPS authentication starting failing with the symptoms described earlier in this bug.

The new TLS certificate we installed had the same key size and hash algorithm, but it turned out the root CA & intermediate certificate were using SHA384 as the signature hash. This in turn caused the LDAPS connections to stop working. Given the CA's certificates were using SHA384 reissuing the certificate wasn't going to help and downgrading the TLS version was not at all desirable given the potential security implications.

I've backported the commit referenced by Marc and confirmed it resolves the problem for us. In my view it'd be wise to push this out to 14.04 users as this issue is going to presumably become more prominent as more certificates start using stronger hash algorithms and TLS 1.2 becomes more prevalent.

Seth Arnold (seth-arnold) wrote :

Hello Samuel, thanks for doing this investigation. This feels like a reasonable change to address through a Stable Release Update; the process is a bit involved, but largely so we're sure we don't break existing users in the process.

Are you in a position where you can prepare a debdiff? There's some guidelines on (it's not a perfect match since that page is for security updates, not SRUs, but it's hopefully helpful.)

See also


Samuel Leslie (sdl) wrote :

Hi Seth,

I've attached a debdiff which is generated off the latest gnutls26 package: 2.12.23-12ubuntu2.7. That said, no changes to my earlier patch were required to apply cleanly. Hopefully this is what you're after?

I should also add that this patch should ideally be reviewed by someone knowledgeable about GnuTLS and C, as I don't consider myself to meet either of those requirements! Particularly given this is a security library.


no longer affects: gnutls26 (Ubuntu)
tags: added: patch trusty
removed: ssl tls
Samuel Leslie (sdl) wrote :

Just wanted to check if there's anything else I can do to assist with this being pushed out as an update? We're pretty eager to have this incorporated as until it is, any updates to GnuTLS need to have the attached patch manually backported by us to avoid breakage on various services we run with affected certificate chains!

Michael (shotoflove) wrote :

I'm also having the same issue as Samuel.

Michael (shotoflove) wrote :

Where can I download this patch? The link doesn't work for me, thanks.

Samuel Leslie (sdl) wrote :

Links to .diff & .debdiff files work fine for me? Tested in Chrome's Incognito mode not logged into the site. I'll email you the patches directly regardless.

Samuel Leslie (sdl) wrote :

Anything we can do to get some activity on this bug? The patch is done to my knowledge and just needs to be reviewed. Am mindful that this is going to continue to break for afflicted users as gnutls is periodically updated.

Samuel Leslie (sdl) wrote :

Somewhat ironically, an update for libgnutls26 was released the same day I made my last comment, which I wasn't aware of at the time. This has broken libgnutls26 on affected systems once again. I confirm the attached patch still applies cleanly with the latest sources.

Simon Quigley (tsimonq2) wrote :

Hello Samuel, apologies for a delay on the review. Here's a couple of things I suggest you do with the patch before it is uploaded:
 1. Please run dch -r and make sure that UNRELEASED now states trusty.
 2. In the changelog, please begin all lines with text with a bullet point or sub-bullet point. I would suggest changing the changelog to the following (also contains some wording changes):
  * Backport an upstream commit for better TLS 1.2 compatibility during handshakes (LP: #1444656):
    - This fixes a handshake failure on TLS 1.2 connections when one or more
      certificates in the chain use the SHA384 or SHA512 signature algorithm.
 3. Please add a DEP-3 header. You can do that by running `quilt header --dep3 -e`. More details are available here: .

Once those packaging changes are done, I will be happy to look more at the content of the patch (but in my opinion that's a separate topic, because packaging the backport is different than checking the validity of the backport). As such, I'm unsubscribing ~ubuntu-sponsors. Please feel free to resubscribe ~ubuntu-sponsors once you have an updated patch, and I will promptly review your patch and upload if it looks good.

Thank you for your contribution to Ubuntu and your help in getting this bug fixed!

Samuel Leslie (sdl) wrote :

Thanks for the feedback Simon. I've uploaded a new debdiff which hopefully correctly incorporates all of your suggested changes. I'll resubscribe ~ubuntu-sponsors to hopefully get this merged. Thanks again.

Samuel Leslie (sdl) wrote :

ok looks good to me, uploaded.

I had to do some little changes in changelog and patch
(you are not the author for the code change, it is upstream)

Please test gnutls26 that will be available in my ppa in a few minutes

description: updated
Changed in gnutls26 (Ubuntu Trusty):
status: Triaged → In Progress
Samuel Leslie (sdl) wrote :

Excellent thanks, I'll test the PPA tonight (after-hours our time). Apologies for the author issue, I wasn't sure if it should reflect the upstream author or the person who submitted the patch.

Samuel Leslie (sdl) wrote :

Can't see the package in your PPA. Something may have gone wrong?

>Apologies for the author issue, I wasn't sure if it should reflect the upstream author or the person who submitted the patch.

I'm not even sure either :) usually the author of the packaging changes is reflected in debian/changelog, this is why I removed it from the patch

>Can't see the package in your PPA. Something may have gone wrong?

Reuploaded, I did remove it by error in my daily ppa cleanup :P

it is called build1 now, because of same versioning can't be reuploaded in the same ppa

Andy Whitcroft (apw) wrote :

It appears that this upload was based on the fix in -proposed for bug #1709193, but that has failed verification and has an updated version in that bug. These two need to be remerged and re-uploaded.

An upload of gnutls26 to trusty-proposed has been rejected from the upload queue for the following reason: "This update is based on a version in -proposed which has since failed verification. See Bug: #1709193.".

I reuploaded the same package with the followup fix for #1709193


ppa:costamagnagianfranco/costamagnagianfranco-ppa <-- please test

Samuel Leslie (sdl) wrote :

Unless I'm going mad it's still not present in your PPA? Can you upload the updated debdiff which incorporates the follow-up fix for #1709193 and I can just compile and test locally if necessary?

We are waiting for security team for this bug...
Please hold on and ping back in one week if nothing changes

Robie Basak (racb) wrote :

Driving through with my SRU hat.

Regression Potential of "None" or "Low" is unacceptable. Please review

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

Since this is particularly security sensitive code, has anyone knowledgeable in the area reviewed the patch in the specific context of this backport, or is this just a blind cherry-pick?

Are you pushing this through the SRU or security process? I'm reviewing it from the SRU queue, but comments here and the bug subscriptions suggest that security is involved?

Samuel Leslie (sdl) wrote :

- Agree the regression potential is likely moderate given the nature of the change. That said, the change is implemented already in newer Ubuntu releases via inclusion of newer GnuTLS releases, which may provide some degree of confidence in the correctness of the fix.
- Unclear how best to test that regressions aren't introduced. Does GnuTLS have an existing appropriate test suite which can be leveraged? I can say we've been running a patched build of GnuTLS per earlier attachment on our servers without issue, but that's obviously not sufficient for any sort of sign-off.
- Very strongly agree that this patch needs to be reviewed by someone suitably knowledgeable about GnuTLS internals and the relevant security topics. The included patch is just a cherry-pick of the relevant commit which fixes the issue upstream.
- The patch does not fix a security issue, but does fix a bug in security sensitive code. In that respect, bugs in the patch could obviously very easily introduce security issues, so careful review is required.

All of the above said, I'm not sure I can contribute much more than I already have. The issue is identified, I've backported the relevant commit, and can confirm it works based on my own testing and internal deployment at my workplace. What's needed now is review of the fix and potentially more testing.

Marc Deslauriers (mdeslaur) wrote :

I have reviewed the debdiff in comment #24. I validated that is indeed a reasonable backport of the commit that was identified in comment #9.

I have successfully tested it with our usual security team test scripts.

While it may be possible for the backport to introduce a bug, I can't see anything that particularly stands out as being problematic and I believe we should go ahead with this SRU.

ACK from the security team.

Marc Deslauriers (mdeslaur) wrote :

I have re-uploaded the package for processing by the SRU team with a slight changelog formatting change. Thanks.

Terje Rafelsen (terjer) wrote :

When will this be assigned and patched to 14.04?

Have several systems affected that needs a patch.

Seth Arnold (seth-arnold) wrote :

If I'm reading the "update excuses" output correctly, this package update is blocked by autopkgtest failures:

ok 14 /tls/connection/simultaneous-sync
GLib-Net:ERROR:connection.c:368:run_echo_server: assertion failed (error == NULL): Error performing TLS handshake: The specified session has been invalidated for some reason. (g-tls-error-quark, 1)
# GLib-Net:ERROR:connection.c:368:run_echo_server: assertion failed (error == NULL): Error performing TLS handshake: The specified session has been invalidated for some reason. (g-tls-error-quark, 1)
Test glib-networking/connection.test failed: Child process killed by signal 6
Running test: /usr/share/installed-tests/glib-networking/file-database.test

That's from

It looks like none of the architectures for glib-networking succeeded:

Since the failures are specifically about TLS handshake failures, it feels unlikely to be transient test failures. Someone needs to investigate this further.


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

Other bug subscribers