GnuTLS patches huge security hole that hung around for two years – worse than Heartbleed, says Google cryptoboffin

Maybe it's time to get it gone

GnuTLS, a widely used open source library implementing Transport Layer Security, last week fixed a bug that had been hiding in the code for almost two years that made resumed TLS 1.3 sessions vulnerable to attack.

The TLS handshake requires two round-trips between client and server to establish a secure connection. Session tickets provide a way to resume previously established connections with only one round-trip. But this convenience comes at a cost – it's less secure, as described by Google cryptographer Filippo Valsorda.

The flaw allowed GnuTLS servers to use session tickets issued during a previous secure TLS 1.3 session without accessing the function that generates secret keys, gnutls_session_ticket_key_generate(). An attacker capable of exploiting this vulnerability could bypass authentication under TLS 1.3 and could recover previous conversations under TLS 1.2.

The bug, introduced in GnuTLS 3.6.4 (Sep. 24, 2018), was fixed in GnuTLS 3.6.14 (June 3, 2020).

Via Twitter, Andrew Ayer, founder of SSLMate, laid into the GnuTLS code for devising a complicated key rotation system that doesn't actually work.

"All their 'rotation' did was add a vulnerability," he said.

Nikos Mavrogiannopoulos, a security engineer at Red Hat and contributor to GnuTLS, expressed reluctance to engage in a Twitter crypto-fight but came to the defense of the project anyway.

"GnuTLS is a library, and does not set the master key; the master key is set by applications," he explained. "We figured out that not all applications rotate keys, so this mechanism was introduced to protect these applications."

"In that context the rotation protects from the key being reused; it does not protect the key if extracted from the application, which was not our concern," he said.

Ayer has been critical of GnuTLS in the past, referring to it as a "clownish" TLS implementation in a blog post about the expiration of Sectigo's AddTrust legacy root certificate, which affected GnuTLS.

Others echoed his disdain for GnuTLS, with some arguing for its removal as a dependency. "Never use GnuTLS," quipped Thomas H. Ptacek, a security researcher and founder of Matasano Security. "...we are enforcing a strict no GnuTLS policy," said Michael Gebetsroither, founder of consultancy mgIT. And Filippo Valsorda said, "PSA: don't rely on GnuTLS, please."

"For scale, this GnuTLS vulnerability is considerably worse than Heartbleed," Valsorda said in a subsequent post. "If you use Linux distributions with GNU tendencies, you might want to check your dependency trees."

Along those lines, Debian, Fedora, and Gentoo Linux distributions have issued security advisories.

Danny McClanahan, a software engineer at Twitter who works with open source software, fired back at infosec professionals for using his company's social media site to disparage GnuTLS and to discourage people using it rather than contributing to the software project and make it better.

"Everyone’s trying to sell something and nobody cares about free software…" McClanahan lamented, who went on to chide Google for hiring expensive security engineers but not offering financial support to the projects they criticize.

The Register asked Ayer about the harsh assessment he and others have offered for GnuTLS and whether that animus might be motivated by interest in a competing TLS project. He said he doesn't contribute to other TLS libraries and he expressed doubt about the suggestion of ulterior motives among others slamming the software.

"I think this recent vulnerability is a really good example of why security professionals have a distaste for GnuTLS," he said in reply.

"The GnuTLS developers set out to improve session ticket encryption key (STEK) rotation, but they seem to have completely misunderstood the problem with STEKs because they came up with a complicated homebrew solution that doesn't actually solve any problems with STEKs."

"Their design wouldn't have made STEKs worse had they implemented it correctly, but since it's complicated they did make a mistake implementing it, leading to the vulnerability," he explained.

"And while making a mistake implementing something useful is forgivable, making a mistake implementing something useless is completely avoidable. And the fact that they were implementing something useless indicates they don't understand the cryptography, which is a problem for the authors of a TLS library." ®