GnuTLS bug in https method from apt-1.0.1ubuntu2.15 package

[deehefem]

** NOTE **
Marking this as security vulnerability as it has the potential to exclude security updates from repositories using HTTPS protocol on Ubuntu 14.04 (perhaps when only going through a proxy).

I have four Ubuntu 14.04 boxes which have either Phusion Passenger, or Jenkins software installed. The repositories for these software packages are served over HTTPS protocl, rather than the customary HTTP:

:: # cat /etc/apt/sources.list.d/passenger.list
:: deb https://oss-binaries.phusionpassenger.com/apt/passenger trusty main
::
:: # cat /etc/apt/sources.list.d/jenkins.list
:: deb https://pkg.jenkins.io/debian-stable binary/

When going through a Blue Coat proxy system (https://www.bluecoat.com/products-and-solutions/on-premise-secure-web-gateway), running `apt-get update` results in the following error message snippets:

:: Hit http://security.ubuntu.com trusty-security/main Translation-en
:: Err https://oss-binaries.phusionpassenger.com trusty/main amd64 Packages
:: gnutls_handshake() failed: A TLS packet with unexpected length was received.
::
:: W: Failed to fetch https://oss-binaries.phusionpassenger.com/apt/passenger/dists/trusty
:: /main/binary-amd64/Packages gnutls_handshake() failed: A TLS packet with unexpected length was :: received.

I've noticed the Ubuntu 14.04 https method (/usr/lib/apt/methods/https) is compiled against libcurl-gnutls.so.4 (libcurl4-gnutls-dev). This package is also reported as being problematic in Python (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=515200) as well as git (http://askubuntu.com/questions/186847/error-gnutls-handshake-failed-when-connecting-to-https-servers).

To test, I've checked the original /usr/lib/apt/methods/https is indeed linked to libcurl4-gnutls:

:: # ldd /usr/lib/apt/methods/https
:: linux-vdso.so.1 => (0x00007ffe2ff43000)
:: libapt-pkg.so.4.12 => /usr/lib/x86_64-linux-gnu/libapt-pkg.so.4.12 (0x00007f2399cc6000)
:: libcurl-gnutls.so.4 => /usr/lib/x86_64-linux-gnu/libcurl-gnutls.so.4 (0x00007f2399a64000)
:: ...

I installed apt-1.0.1ubuntu2.15 source package using `apt-get source` and proceeded to build using the configure options shown here: https://launchpad.net/ubuntu/+source/apt/1.0.1ubuntu2.15/+build/10959579

This indeed produced a binary linked against libcurl-gnutls.so.4. I copied the new https binary over to /usr/lib/apt/methods/ and ran `apt-get update` with the same failure message above. I then ran `apt-get purge libcurl4-gnutls-dev` and then `apt-get install libcurl4-openssl-dev`. I the removed my build directory and installed the apt-1.0.1ubuntu2.15 source package again. Building with the same configure options as before resulted in a https binary linked against openssl. I copied the resulting binary over to /usr/lib/apt/methods/https.openssl and verified:

:: # ldd /usr/lib/apt/methods/https.openssl
:: ...
:: libcurl.so.4 => /usr/lib/x86_64-linux-gnu/libcurl.so.4 (0x00007f28c1d3f000)
:: ...
:: libssl.so.1.0.0 => /lib/x86_64-linux-gnu/libssl.so.1.0.0 (0x00007f28c0362000)
::
:: # cp /usr/lib/apt/methods/https.openssl /usr/lib/apt/methods/https
::
:: # apt-get update
:: Get:1 http://us.archive.ubuntu.com trusty-backports InRelease [65.9 kB]
:: Hit http://ppa.launchpad.net trusty InRelease
:: Hit http://security.ubuntu.com trusty-security InRelease
:: Hit http://us.archive.ubuntu.com trusty Release.gpg
:: Hit http://us.archive.ubuntu.com trusty-updates/main Sources
:: Hit http://us.archive.ubuntu.com trusty-updates/restricted Sources
:: Hit http://ppa.launchpad.net trusty/main amd64 Packages
:: Hit http://security.ubuntu.com trusty-security/main Sources
:: Hit http://ppa.launchpad.net trusty/main i386 Packages
:: Hit http://security.ubuntu.com trusty-security/restricted Sources
:: Hit http://ppa.launchpad.net trusty/main Translation-en
:: Hit http://security.ubuntu.com trusty-security/universe Sources
:: Hit http://security.ubuntu.com trusty-security/multiverse Sources
:: Get:2 https://oss-binaries.phusionpassenger.com trusty InRelease
:: Ign https://oss-binaries.phusionpassenger.com trusty InRelease
:: Hit https://oss-binaries.phusionpassenger.com trusty Release.gpg
:: Hit https://oss-binaries.phusionpassenger.com trusty Release
:: Hit https://oss-binaries.phusionpassenger.com trusty/main amd64 Packages
:: Hit https://oss-binaries.phusionpassenger.com trusty/main i386 Packages
:: Get:3 https://oss-binaries.phusionpassenger.com trusty/main Translation-en
:: Ign https://oss-binaries.phusionpassenger.com trusty/main Translation-en
:: ...

This appears to resolve the issue of trying to contact HTTPS repositories while going through a Blue Coat proxy (perhaps any proxy?). Would it be possible to have a package made available in Ubuntu 14.04 repos which is compiled against openssl instead of libcurl4-gnutls?

[Julian Andres Klode (juliank)]

OK, Launchpad lost the comment, so let me repeat it:

No, we cannot legally link APT's https method against OpenSSL, the licenses are not compatible.

[deehefem (deehefem)]

Interesting. I had no idea (https://people.gnome.org/~markmc/openssl-and-the-gpl.html).

Any thoughts/links as to why the SSL handshake fails with gnutls? Perhaps there is a fix which could be integrated into gnutls.

[Nikos Mavrogiannopoulos (nmavrogiannopoulos)]

I believe you are referring to the 2.12.x branch of gnutls. This has several issues relating to its TLS 1.2 support, and due to the ABI break in 3.x releases, fixes related to TLS 1.2 never entered into that branch. I'm preparing a final release for this branch, including fixes for all known issues.

https://gitlab.com/gnutls/gnutls/milestones/9
https://gitlab.com/gnutls/gnutls/tree/gnutls_2_12_x

[deehefem (deehefem)]

Thank you for the information. Yes, Ubuntu 14.04 uses the 2.12 branch (2.12.23-12ubuntu2.5). Pardon my curiosity, but do you have any idea which issue is the cause of "A TLS packet with unexpected length was received." when going through a proxy? It may be helpful to pin-point the problem and pass the information along to our proxy vendor.

Thank you for all your time and effort on GnuTLS!

[Nikos Mavrogiannopoulos (nmavrogiannopoulos)]

No idea. If you have the problematic server available and you can verify the issue using gnutls-cli, I'd recommend to use git bisect on gnutls_2_12_x branch to detect the commits that fix it.

[Launchpad Janitor (janitor)]

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