Subscribe to Email Updates

This month, Fiona Klute disclosed a vulnerability in GnuTLS, CVE-2020-13777. It can either enable on-path attackers for TLS 1.3, or facilitate passive decryption of traffic between servers running GnuTLS for TLS 1.2. Either way, it’s not great!

Why it’s cool: Attackers could exploit this vuln to recover previously captured network traffic, like conversations (for servers using TLS 1.2), which is pretty bad. Even in the TLS 1.3 case, allowing on-path attackers to gain control over resumed sessions isn’t ideal. 

The underlying cause of the bug is attention-grabbing, too: the encryption and decryption key used to restore session state were all-zero. An all-zero key basically means that anyone listening in on the conversation can read the key used to encrypt the conversation after the initial full handshake. Unpredictable keys are essential to properly encrypt plaintext, and a key that’s all zeros is about as far from unpredictable as you can get. Thus spake Zarathustra: “Encryption is hard.”

Digging deeper: Session Tickets were designed with stateless servers in mind, including the need for scalability. By using Session Tickets, there are fewer round trips required for clients to resume a TLS connection with a server with which they’ve already communicated. This makes reconnecting faster and saves bandwidth on both the client and server side.

Let’s explore by way of metaphor — you’re attending a concert. You present your ticket receipt and photo ID to the venue staff, which is like initiating a new session and performing all the necessary verification between a client and server. In exchange for presenting your receipt, you receive a wristband that allows you to come and go during that evening. The wristband is like a server using Session Tickets, which are protected with the Session Ticket Encryption Key (STEK), to show that the necessary checks were previously performed.

You realize you forgot earplugs, so you walk out of the venue to buy some at the bodega on the corner. When you come back to the venue, you present your wristband to enter without having to present your receipt or photo ID again. This is akin to the client asking the server to re-initiate a session by presenting the Session Ticket. 

Unfortunately, this ticket exchange presents ample opportunity for bamboozling. As Filippo Valsorda noted in 2017, the encrypted ticket is sent in plaintext at the beginning of the handshake, because the cipher negotiation didn’t happen until after the key exchange and ticket issuance. This, of course, means the ticket is just chillin’ in the middle of the network highway waiting to be picked up by an attacker. The attacker would need to decrypt it with the STEK, of course — but when the STEK is all-zero, it makes that hurdle trivial to surmount. And then, all your chats are belong to attacker.

Yes, but: GnuTLS is seldom used, Exim (with its own problems) being one of the few packages using it. OpenSSL, in contrast, is basically Big Crypto (i.e. the widespread incumbent in TLS), so thankfully this particular vulnerability is likely to have a minimal footprint in most enterprises. Debian has fixed it in buster (version 3.6.7-4+deb10u4), and it’s fixed in Fedora 32, too. RHEL versions <8 are unaffected, but there’s isn’t yet a patch for RHEL 8 — though you can always upgrade GnuTLS manually. 

The bottom line: You don’t need to hit the panic button on this one. This vulnerability is certified juicy — one could even say it’s like a rare STEK — and any client that supports session ticket resumption is vulnerable. But, it’s unlikely that you’re using GnuTLS too widely in your own environment. It’s already patched in most distros, so you should upgrade when you can.

The Capsule8 Labs team conducts offensive and defensive research to understand the threat landscape for modern infrastructure and to continuously improve Capsule8’s attack coverage.

Scroll to Top