GnuTLS: TLS 1.3 session resumption works without master key, allowing MITM

https://gitlab.com/gnutls/gnutls/-/issues/1011

by doener • 6 years ago

139 50 6 years ago

gitlab.com

caf• 6 years ago

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

dogma1138• 6 years ago

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

mytailorisrich• 6 years ago

Thanks for the heads up.

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

doener• 6 years ago

Thanks for the hint, fixed.

taspeotis• 6 years ago

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).

https://nvd.nist.gov/vuln/detail/CVE-2020-13777

dbrgn• 6 years ago

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)".

https://twitter.com/__agwa/status/1270054738344792070

tialaramex2• 6 years ago

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.

billpg• 6 years ago

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.

Deukhoofd• 6 years ago

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

stefan_3• 6 years ago

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).

Jonnax• 6 years ago

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?

[1]https://arstechnica.com/information-technology/2014/04/tech-...

terom• 6 years ago

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

ssfivy2• 6 years ago

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?

mobilio2• 6 years ago

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

https://github.com/ARMmbed/mbedtls

"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."

stefan_3• 6 years ago

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.

rwmj3• 6 years ago

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.

Conan_Kudo2• 6 years ago

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.

viraptor2• 6 years ago

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.

agwa2• 6 years ago

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.

mobilio2• 6 years ago

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.

lsofzz• 6 years ago

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.

shinigami• 6 years ago

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

simias2• 6 years ago

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.

davidhyde2• 6 years ago

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

Ayesh• 6 years ago

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.

davidhyde2• 6 years ago

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.

mijoharas• 6 years ago

I was wondering how commonly used gnutls was.

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

cesarb2• 6 years ago

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.

SomeoneFromCA• 6 years ago

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

typical182• 6 years ago

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

https://twitter.com/FiloSottile/status/1270115515378384897

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 ...

simias2• 6 years ago

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?

eddieoz• 6 years ago

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

smnthermes• 6 years ago

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

microtherion• 6 years ago

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."

https://www.oreilly.com/openbook/freedom/ch07.html#86161

coldpie2• 6 years ago

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

bmurray7jhu• 6 years ago

[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)

https://www.openldap.org/lists/openldap-devel/200802/msg0007...

GnuTLS: TLS 1.3 session resumption works without master key, allowing MITM

Related Stories