Curl linked against GnuTLS doesn't use TLS 1.3

[Dirkjan Bussink]

Ubuntu 20.04 ships a recent version of GnuTLS which supports TLS 1.3. Git uses GnuTLS for TLS through libcurl, so I had expected that it also uses TLS 1.3 for Git. Since early last year, I added TLS 1.3 on GitHub.com as announced in https://github.blog/changelog/2019-01-15-tls13-rollout/.

Testing shows it's not used though:

dirkjan@x:~/curl$ cat /etc/os-release
NAME="Ubuntu"
VERSION="20.04 LTS (Focal Fossa)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu Focal Fossa (development branch)"
VERSION_ID="20.04"
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
VERSION_CODENAME=focal
UBUNTU_CODENAME=focal
dirkjan@x:~$ GIT_CURL_VERBOSE=1 git ls-remote https://github.com/torvalds/linux.git
* Couldn't find host github.com in the .netrc file; using defaults
* Trying 192.30.255.113:443...
* TCP_NODELAY set
* Connected to github.com (192.30.255.113) port 443 (#0)
* found 384 certificates in /etc/ssl/certs
* ALPN, offering h2
* ALPN, offering http/1.1
* SSL connection using TLS1.2 / ECDHE_RSA_AES_128_GCM_SHA256
* server certificate verification OK
* server certificate status verification SKIPPED
* common name: github.com (matched)
* server certificate expiration date OK
* server certificate activation date OK
* certificate public key: RSA
* certificate version: #3
* subject: businessCategory=Private Organization,jurisdictionOfIncorporationCountryName=US,jurisdictionOfIncorporationStateOrProvinceName=Delaware,serialNumber=5157550,C=US,ST=California,L=San Francisco,O=GitHub\, Inc.,CN=github.com
* start date: Tue, 08 May 2018 00:00:00 GMT
* expire date: Wed, 03 Jun 2020 12:00:00 GMT
* issuer: C=US,O=DigiCert Inc,OU=www.digicert.com,CN=DigiCert SHA2 Extended Validation Server CA
* ALPN, server accepted to use http/1.1
> GET /torvalds/linux.git/info/refs?service=git-upload-pack HTTP/1.1
Host: github.com
User-Agent: git/2.25.1
Accept: */*
Accept-Encoding: deflate, gzip, br
Accept-Language: en-US, *;q=0.9
Pragma: no-cache

* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Server: GitHub Babel 2.0
< Content-Type: application/x-git-upload-pack-advertisement
< Transfer-Encoding: chunked
< Expires: Fri, 01 Jan 1980 00:00:00 GMT
< Pragma: no-cache
< Cache-Control: no-cache, max-age=0, must-revalidate
< Vary: Accept-Encoding
< X-GitHub-Request-Id: E01C:5AF3:3377B9:45B65F:5E959D1B
< X-Frame-Options: DENY

As can be seen here with the "* SSL connection using TLS1.2 / ECDHE_RSA_AES_128_GCM_SHA256" bit, only TLS 1.2 is used.

After further investigation, I found the problem in Curl, and submitted a fix: https://github.com/curl/curl/pull/5223. The fix was merged & I also manually tested this by patching the version of Curl shipping with 20.04 and testing there:

dirkjan@x:~/curl$ ./src/curl --version
curl 7.68.0-DEV (x86_64-pc-linux-gnu) libcurl/7.68.0-DEV GnuTLS/3.6.13 zlib/1.2.11 brotli/1.0.7 libidn2/2.2.0 libpsl/0.21.0 (+libidn2/2.2.0) libssh/0.9.3/openssl/zlib nghttp2/1.40.0 librtmp/2.3
Release-Date: [unreleased]
dirkjan@x:~/curl$ ./src/curl -v https://github.com > /dev/null
  % Total % Received % Xferd Average Speed Time Time Time Current
                                 Dload Upload Total Spent Left Speed
  0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0* Trying 140.82.118.3:443...
* TCP_NODELAY set
* Connected to github.com (140.82.118.3) port 443 (#0)
* found 128 certificates in /etc/ssl/certs/ca-certificates.crt
* ALPN, offering h2
* ALPN, offering http/1.1
* SSL connection using TLS1.3 / ECDHE_RSA_AES_128_GCM_SHA256
* server certificate verification OK
* server certificate status verification SKIPPED
* common name: github.com (matched)
* server certificate expiration date OK
* server certificate activation date OK
* certificate public key: RSA
* certificate version: #3
* subject: businessCategory=Private Organization,jurisdictionOfIncorporationCountryName=US,jurisdictionOfIncorporationStateOrProvinceName=Delaware,serialNumber=5157550,C=US,ST=California,L=San Francisco,O=GitHub\, Inc.,CN=github.com
* start date: Tue, 08 May 2018 00:00:00 GMT
* expire date: Wed, 03 Jun 2020 12:00:00 GMT
* issuer: C=US,O=DigiCert Inc,OU=www.digicert.com,CN=DigiCert SHA2 Extended Validation Server CA
* ALPN, server accepted to use http/1.1
> GET / HTTP/1.1
> Host: github.com
> User-Agent: curl/7.68.0-DEV
> Accept: */*
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< date: Tue, 14 Apr 2020 11:42:39 GMT
< content-type: text/html; charset=utf-8

My question here is if you all are willing to consider including the patch I sent to curl to also be applied to curl in 20.04. I don't think it has any immediate urgency before the upcoming 20.04 release, but including this fix would be a huge help, not only for us at GitHub.com but also all other Git hosting sites. Git is a significant user of curl with GnuTLS, but also all other users are affected there as well.

Why is this helpful for Git hosting sites you might ask? The world of TLS is ever evolving, and even today we see a practical example where Git on 14.04 is a limiting factor in making improvements to GitHub.com's TLS setup. The older linked GnuTLS used with libcurl in 14.04 doesn't support ECDHE ciphers, so enforcing only ciphers with forward secrecy is affected by the still large usage of 14.04.

We would love to not have a similar problem in the future in a few years if it turns out TLS 1.2 needs to be deprecated and everyone needs to switch to TLS 1.3. By reporting this now I hope that within the 20.04 lifetime, TLS 1.3 can be used for Git as well.

[Sebastien Bacher (seb128)]

Thanks for the report, sounds like a good one to get into focal indeed

[Launchpad Janitor (janitor)]

This bug was fixed in the package curl - 7.68.0-1ubuntu2

---------------
curl (7.68.0-1ubuntu2) focal; urgency=medium

  * debian/patches/git_tls13_gnutls.patch:
    - Ensure TLS 1.3 works with GnuTLS, thanks Dirkjan Bussink for writting
      the patch and pointing it out on launchpad! (lp: #1872698)

 -- Sebastien Bacher <email address hidden> Wed, 15 Apr 2020 08:27:03 +0200

[Dirkjan Bussink (dbussink)]

Can confirm that the issue is indeed fixed after I updated to the latest released version. Thanks for the quick turnaround!