git gnutls_handshake() failed: A TLS packet with unexpected length was received.

Bug #1397685 reported by Erez Hadad
26
This bug affects 5 people
Affects Status Importance Assigned to Milestone
git (Ubuntu)
Confirmed
Undecided
Unassigned
gnutls26 (Ubuntu)
Confirmed
Undecided
Unassigned
gnutls28 (Ubuntu)
Confirmed
Undecided
Unassigned

Bug Description

Platform: Ubuntu 14.04, ppc64le (Power 8 LE), git version: 1:1.9.1-1
When accessing a public repository over HTTPS, I get the following error:
$ git clone --no-checkout https://git.fedorahosted.org/git/lvm2.git lvm2
Cloning into 'lvm2'...
fatal: unable to access 'https://git.fedorahosted.org/git/lvm2.git/': gnutls_handshake() failed: A TLS packet with unexpected length was received.

Accessing the same public repository from a different machine running in a different network - also Ubuntu 14.04, but running on x86-64, the commands executed with no errors. Both platforms have the same git version (dpkg -l | grep git)

I checked online for an explanation. Found this:
http://askubuntu.com/questions/186847/error-gnutls-handshake-falied-when-connecting-to-https-servers

According to that, Gnu TLS may have some issues when proxies (firewalls?) are present on the network path to the repositories. The recommended solution is to rebuild git using OpenSSL instead of TLS. I tried it and got to a different error ("Unknown SSL protocol error").

Can you please fix git to make it work correctly?

Erez Hadad (erezh)
no longer affects: pycurl (Ubuntu)
Revision history for this message
Dimitri John Ledkov (xnox) wrote :

This will need further investigations / tests as to what is the problem in the TLS protocol.

It's most likely not git specific but rather TLS implementation specific - that is one can recompile curl utility against (openssl, gnutls, nss) to verify with each one that lts access works.

We cannot recompile git against openssl, as git & openssl licenses are believed to be incompatible (and git does not have openssl link exception).

I'm assigning this bug report against gnutls for now.

Based on the description it should be reproducible simply by trying to retrieve https://git.fedorahosted.org/git/lvm2.git/info/refs

(Which is the first URL git fetches over HTTPS when trying to clone a repository over https)

Revision history for this message
Dimitri John Ledkov (xnox) wrote :

Performing https configuration verfication on git.fedorahosted.org:

On Trusty 14.04 LTS, the default gnutls implementation is old 2.6 based:

$ gnutls-cli -V --print-cert -p 443 git.fedorahosted.org </dev/zero | certtool --verify-chain
Certificate[0]: C=US,ST=North Carolina,L=Raleigh,O=Red Hat Inc.,CN=*.fedorahosted.org
 Issued by: C=US,O=DigiCert Inc,OU=www.digicert.com,CN=DigiCert SHA2 High Assurance Server CA
 Verifying against certificate[1].
 Verification output: Verified.

Certificate[1]: C=US,O=DigiCert Inc,OU=www.digicert.com,CN=DigiCert SHA2 High Assurance Server CA
 Issued by: C=US,O=DigiCert Inc,OU=www.digicert.com,CN=DigiCert SHA2 High Assurance Server CA
certtool: the last certificate is not self signed

$ echo $?
1

It does not appear to verify the published chain.

Utopic 14.10 uses gnutls 3.x series by default:

# gnutls-cli -V --print-cert -p 443 git.fedorahosted.org </dev/zero | certtool --verify-chain
*** Fatal error: Error in the certificate.
*** Handshake has failed
GnuTLS error: Error in the certificate.
Loaded 2 certificates, 1 CAs and 0 CRLs

 Subject: C=US,O=DigiCert Inc,OU=www.digicert.com,CN=DigiCert SHA2 High Assurance Server CA
 Issuer: C=US,O=DigiCert Inc,OU=www.digicert.com,CN=DigiCert High Assurance EV Root CA
 Output: Not verified. The certificate is NOT trusted. The certificate issuer is unknown.

 Subject: C=US,O=DigiCert Inc,OU=www.digicert.com,CN=DigiCert SHA2 High Assurance Server CA
 Issuer: C=US,O=DigiCert Inc,OU=www.digicert.com,CN=DigiCert High Assurance EV Root CA
 Checked against: C=US,O=DigiCert Inc,OU=www.digicert.com,CN=DigiCert SHA2 High Assurance Server CA
 Output: Verified. The certificate is trusted.

 Subject: C=US,ST=North Carolina,L=Raleigh,O=Red Hat Inc.,CN=*.fedorahosted.org
 Issuer: C=US,O=DigiCert Inc,OU=www.digicert.com,CN=DigiCert SHA2 High Assurance Server CA
 Checked against: C=US,O=DigiCert Inc,OU=www.digicert.com,CN=DigiCert SHA2 High Assurance Server CA
 Output: Verified. The certificate is trusted.

Chain verification output: Verified. The certificate is trusted.

(utopic-amd64)root@djledkov-mobl1:/tmp# echo $?
0

Which appears to be trusted. This looks odd, but not fatal as fresh trusty-amd64 in a chroot does seem to be operating correctly.

Revision history for this message
Dimitri John Ledkov (xnox) wrote :

@Erez Hadad can you please try to reproduce this problem in 14.10 Utopic as well? This will then rule-out whether gnutls 3.x is affected as well or not.

This can be done from a Trusty 14.04 host like so:

$ mk-sbuild utopic
$ schroot -u root -c utopic-ppc64el
$ apt-get install git
$ cd /tmp; git clone --no-checkout https://git.fedorahosted.org/git/lvm2.git lvm2

Revision history for this message
Erez Hadad (erezh) wrote :

@xnox I followed your procedure. Here is the result of the last command. Seems worse than before..
(utopic-ppc64el)root@ubuntu14ppcel:/tmp# git clone --no-checkout https://git.fedorahosted.org/git/lvm2.git lvm2
Cloning into 'lvm2'...
fatal: unable to access 'https://git.fedorahosted.org/git/lvm2.git/': gnutls_handshake() failed: Error in the pull function.
(utopic-ppc64el)root@ubuntu14ppcel:/tmp#

Any debug / verbose flags I can activate to give you more info?

Revision history for this message
Nikos Mavrogiannopoulos (nmavrogiannopoulos) wrote :

There are several issues with TLS connections and the F5 firewall, and that looks like the case. That firewall terminates a TLS session if the client hello is between 256 and 512 bytes. If that is the case you can verify using wireshark.

The solution we adopted in later versions of gnutls is to add padding:
https://gitlab.com/gnutls/gnutls/commit/b6d29bb1737f96ac44a8ef9cc9fe7f9837e20465

Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in git (Ubuntu):
status: New → Confirmed
Changed in gnutls26 (Ubuntu):
status: New → Confirmed
Changed in gnutls28 (Ubuntu):
status: New → Confirmed
Revision history for this message
chenzero (chenzero) wrote :

I also encountered similar problem when run:

$ git clone -v https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
Cloning into 'linux-firmware'...
* Couldn't find host git.kernel.org in the .netrc file; using defaults
* Hostname was NOT found in DNS cache
* Trying 199.204.44.194...
* Trying 2620:3:c000:a:0:1991:8:25...
* Immediate connect fail for 2620:3:c000:a:0:1991:8:25: Network is unreachable
* Trying 2001:4f8:1:10:0:1991:8:25...
* Immediate connect fail for 2001:4f8:1:10:0:1991:8:25: Network is unreachable
* Connected to git.kernel.org (199.204.44.194) port 443 (#0)
* found 173 certificates in /etc/ssl/certs/ca-certificates.crt
* gnutls_handshake() failed: Handshake failed
* Closing connection 0
fatal: unable to access 'https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/': gnutls_handshake() failed: Handshake failed

OS: Ubuntu 14.04 64bits.

I checked "apt-get update"
and ensure that packages: git and libcurl3-gnutls are latest.
Installed version:
git: 1:1.9.1-1ubuntu0.3
libcurl3-gnutls: 7.35.0-1ubuntu2.9

If change git clone URL from https to http, git clone successful.

Thank you very much!

Revision history for this message
Nikos Mavrogiannopoulos (nmavrogiannopoulos) wrote :

git.kernel.org is configured to only allow TLS with elliptic curve ciphersuites. Given that gnutls 2.12.x doesn't support elliptic curves, it cannot connect to that site.

Revision history for this message
chenzero (chenzero) wrote :

Thanks!
I also tried on another machine, that also error.
It looks like a server configuration issue.
I will report to kernel.org later.

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

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.