Hacker News new | past | comments | ask | show | jobs | submit login
GnuTLS: TLS 1.3 session resumption works without master key, allowing MITM (gitlab.com)
139 points by doener 27 days ago | hide | past | favorite | 50 comments

The HN title is currently "TLS 1.3 session resumption works without master key, allowing MITM" which only mentions TLS 1.3, while the CVE description mentions TLS 1.2 as well:

> GnuTLS 3.6.x before 3.6.14 uses incorrect cryptography for encrypting a session ticket (a loss of confidentiality in TLS 1.2, and an authentication bypass in TLS 1.3).


According to this tweet, "For TLS 1.2, this enables passive decryption of traffic to/from GnuTLS servers when the client supports session tickets (which is common)".


Right. Specifically what's going on here is that for TLS 1.2 resumption your client remembers the secret keys it was using last time, but the server doesn't want to keep secret keys for every single client that might re-connect so it has its own secret Session Ticket Encryption Key (STEK) and it sends any client a "ticket" with the server's state for that client's connection in it, encrypted using the STEK.

The not at all obvious problem in TLS 1.2 is that the state encapsulated in the ticket will work not only in some hypothetical future TLS resumption (which you might never do) but also the session you are in already now. And that ticket is sent over the wire if resumption is permitted, during session setup, before the symmetric encryption for the TLS channel has switched on.

So what that means is that if you know the STEK (which now for affected GnuTLS servers you do) you can read any session you captured in which resumption was allowed, including fresh sessions which were never resumed, and passively decrypt the entire thing. Nothing anybody can do about it.

> [T]he [GnuTLS] code is fundamentally broken; most of its external and internal APIs are incapable of passing binary data without mangling it. The code is completely unsafe for handling binary data, and yet the nature of TLS processing is almost entirely dependent on secure handling of binary data.

-Howard Chu (2007)


Different versions of TLS should not interact with each other. There are too many behavioral permutations to audit.

They don't. It's always the same version server and client negotiate.

The vulnerability is in the way session tickets are encrypted (or rather the lack of it), which is present in both versions, but in different formats; for example in TLS 1.3, the session ticket is sent _after_ change cipher command.

It's vulnerable in 1.2 and 1.3 because the way session ticket is encrypted. GnuTLS used effectively an all-zero key until it's rotated in the next tick.

Thanks, I must have misread the post:

> "The issue applies to TLS 1.3, when using TLS 1.2 resumption fails as expected. Because the ticket can be used for resumption without knowledge of the master key I assume (but haven't tested yet) that it can also be used for passive decryption of early data."

I assumed that the server was using a ticket generated using TLS 1.2 to somehow resume a TLS 1.3 connection.

The bug report downplays the severity of the problem. This comment comes the closest to explaining the severity:

> ticket encryption key and decryption key are all-zero [...] in TLS 1.2, it may allow attackers to recover the previous conversations


This is your weekly reminder that There Is No Such Thing As Computer Security. Treat your computing devices appropriately.

This needs a "GnuTLS:" or CVE reference in the title.

Indeed otherwise this might look like the SSLv3 Poodle issue to some.

Thanks for the heads up.

It's crucial to point out that this is a GnuTLS bug not a TLS one.

Thanks for the hint, fixed.

I was wondering how commonly used gnutls was.

Gnutls is required by (among others) ffmpeg, emacs, vlc and wget.

This bug is on the TLS server code, so the relevant question would be how commonly used gnutls is as a TLS server. Luckily, gnutls seems to be more popular as a client library than as a server library.

I use it on a server. Way easier to use than opennsl, to my taste.

In terms of where it is used, here is a related tweet by Filippo Valsorda:


For scale, this GnuTLS vulnerability is considerably worse than Heartbleed. If you use Linux distributions with GNU tendencies, you might want to check your dependency trees.

(He is a cryptographer on the Go project, who also happened to win the CloudFlare Heartbleed Challenge).

As he says, that thread is a good starting point for potentially vulnerable uses.

Some sample quotes from that thread:


The good news is that this is a server-side issue


For obvious reasons, systemd ships a custom http server with client auth via GnuTLS.


On Fedora "dnf repoquery --whatrequires gnutls" lists: Samba NetworkManager pacemaker qemu / libvirt wget rdesktop tigervnc gnupg

Apache mod_gnutls ...

>For obvious reasons, systemd ships a custom http server with client auth via GnuTLS.

I can't tell if that's a joke poking fun at systemd's bloat or a genuine comment. What does systemd need an HTTP server for? Is it enabled by default on most distros?

It's probably systemd-journal-gatewayd (https://www.freedesktop.org/software/systemd/man/systemd-jou...) or systemd-journal-remote (https://www.freedesktop.org/software/systemd/man/systemd-jou...), and I don't think I've ever seen either enabled, by default or otherwise (and at least on this machine, they don't even seem to be installed; they might be on another package, or they might not be compiled by default).

I searched their wikipedia page (https://en.wikipedia.org/wiki/GnuTLS) and there are many applications that rely on gnutls: GNOME, CenterIM, Exim, Weechat, Mutt, Wireshark, slrn, Lynx, CUPS, gnoMint, GNU Emacs, Synology DiskStation Manager, OpenConnect

Claws Mail uses it as well: https://www.claws-mail.org/downloads.php

So this isn't a vulnerability inherent to TLS 1.3 that we need to start designing TLS 1.4?

Edit: The title has since been fixed.

No, just a GnuTLS bug that was fixed in its recent release

The words "GnuTLS" or "mbedTLS/PolarSSL" strike fear into my heart. When picking a TLS library written by amateur cryptographers, make sure it is the one used by everyone else (OpenSSL).

GnuTLS has a non-crazy well documented API with loads of good quality examples, which is why we chose it for libvirt. (It was impossible for us to understand how to use OpenSSL for basic stuff like opening a connection at the time we made that choice - I sure hope it's improved now.) The lesson is if you want adoption you need to have a clear API with no foot-guns, lots of examples and documentation.

Also I would dispute that GnuTLS is somehow written by "amateurs". I know people who contribute at Red Hat and they are very much professionals, and experts in math and crypto engineering.

Yes, a good API with good documentation is important. Fortunately, OpenSSL has improved significantly in the last few years.

Unfortunately, I've talked with crypto experts about GnuTLS's bizarre session ticket key rotation system and nobody can figure out what the heck GnuTLS was trying to accomplish with it. It doesn't rotate anything important, and by implementing it they accidentally introduced this critical all-zero key bug. This is the hallmark of amateurs.

>Fortunately, OpenSSL has improved significantly in the last few years.

After Heartbleed was discovered. I think it's the TLS specification itself that's the problem. It's ridiculously complex and difficult to implement correctly to the point even the experts struggle with it.

This statement is basically the reason why we use GnuTLS as well. In fact, we've basically universally migrated our applications away from OpenSSL to GnuTLS because it's a much better library to use and ship.

Additionally, the licensing for GnuTLS is a lot clearer than OpenSSL's, and that made it easier to understand how we could use it.

Unfortunately, OpenSSL is only in alpha right now. And they didn't do an LLVM-style exception to resolve the issues with GPLv2 software.

And improved licensing doesn't fix the horrible API, nor the lack of discipline to prevent API/ABI repeated breakages within the same version series. We'll see if they do better with this in OpenSSL 3.x...

It doesn't seem like a lot of people contribute though: https://github.com/gnutls/gnutls/graphs/contributors

Seems like a 2-people project, where 1 dropped off, and 2 new devs recently joined.

Because there are 2 people who contribute massively more than the others, it's rather hard to see the regular work done by other contributors by looking at the graphs.

Also gnutls is "just" an API and a framework for TLS, all the crypto primitives work happens in libgcrypt: https://github.com/gpg/libgcrypt/graphs/contributors

EDIT: not libgcrypt, libnettle:


Still, that means if there's any new change, there's maybe one other person to review it in gnutls and ... none in nettle. Seems like if niels-moller makes a mistake, we won't know until a CVE.

GnuTLS doesn't use libgcrypt. Or at least it's not required. It uses nettle.

Yes you're completely right, I updated my comment.

Isn't mbedTLS part of ARM now? For microcontrollers / bare metal devices that need to connect via Ethernet, it is probably one of the more reputable ones - unless there's another major library I haven't heard of?

It's "part of ARM" like random Java projects become "part of the Apache foundation". Its reputation is the unmistakable ability to always fall on the side of broken/unmitigated whenever someone discovers another TLS protocol problem, apart from a history of the usual code execution and memory safety issues (the latter, of course, extremely difficult to mitigate on anything that has the name "embedded").

And if that doesn't scare you, think about how these libraries are used on embedded devices. People who think they can seed the CSPRNG of their TLS library with rand() and if it connects to google, everything is ok, ship it.

Do you know a better library to use for bare-metal purposes then? Because with mbedTLS at least you can get security updates and the code is scrutinised publicly. Way better than some proprietary crypto stacks I have seen where they charge you money for updates.

I'm not disagreeing with you here, I just want to prevent the stuff I made on from being features on @internetofshit twitter and similar places

BearSSL (https://bearssl.org/) works great. It is written by someone who both understands the cryptography at depth and how to write secure C code for embedded environments.

Yes - it's part of ARM Holdings from November 2014.


"Arm welcomes feedback on the design of the API. If you think something could be improved, please open an issue on our Github repository. Alternatively, if you prefer to provide your feedback privately, please email us at mbed-crypto@arm.com. All feedback received by email is treated confidentially."

Yeah. I recall OpenSSL used to have issues of lack of contributors. [1]

Anyone have any reasons why it wouldn't be crazy to use a small project's solution?


OpenSSL has licensing issues when linking with GPL applications (without an explicit exception in the GPL-licensed application, which is not uncommon). [1]

Debian in particular does not allow distributing such packages, and the common workaround is to use GnuTLS instead. Unfortunately I can't find any good reference for this policy...

Interestingly, it seems like OpenSSL 3.0 is going to be Apache v2 licensed. [2]

[1] https://people.gnome.org/~markmc/openssl-and-the-gpl

[2] https://www.openssl.org/source/license.html

Unfortunately Apache v2 is still not compatible with GPLv2-only, so OpenSSL 3.0 will not solve all of the licensing issues, but some of them it will.

Incidentally, an OpenSSL 3.0 alpha just reached Debian experimental.

OpenSSL WAS good library in past. Today it's bloatware.

But since it's have lot of DEAD code that left there for compatibility reasons. Just like SSL2/SSL3 and their "encryptions".

Google also start fork project - BoringSSL in order to separate their patches between mainline OpenSSL.

You'll have to substantiate these assertions. When was it good? Why is it bloatware today?

If anything IMHO it's significantly cleaner today than it used to be ~10 years ago. It still feel like the code quality is not up to the standard I'd hope for in such a critical piece of software but I don't think it's really worse now.

Back around the time of Heartbleed, there was a bunch of childish[1,2] attention given to OpenSSL's warts, mostly centered around the OpenBSD fork called LibreSSL, which stripped out a lot bad, old code and code for non-Unix platforms.

Unsurprisingly, the childish attention faded into nothing because it's much harder to write good code than it is to tear apart someone else's. But the smear on the OpenSSL volunteers' reputation remains, as seen by GP's comment.

[1] https://opensslrampage.org/page/49

[2] https://opensslrampage.org/post/83555615721/the-future-or-la...

I have previously characterized OpenSSL as "Stamp collector cryptography". Here's an implementation of IDEA. Should you use IDEA? No. So why is this even here?

Compare the Go crypto reaction when somebody wants to add ECB mode: https://github.com/golang/go/issues/5597

OpenSSL is better now than it was then, it might even be the least worst option for a lot of people in low-level languages who want to spin up a TLS client or server. But that is deliberately faint praise.

It's the opposite, really. It improved a lot after the heartbleed issue.

It's hard to know exactly how bloated SSL/TLS libraries have become without actually taking the time to research them but some of the folks behind `LibreSSL` seem to know crypto well enough.

In a way, maybe this is an (inadvertent) throwback to early GNU ideals: > "[When] passwords first appeared at the MIT AI Lab I [decided] to follow my belief that there should be no passwords," Stallman would later say. "Because I don't believe that it's really desirable to have security on a computer, I shouldn't be willing to help uphold the security regime."


Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact