
GnuTLS: TLS 1.3 session resumption works without master key, allowing MITM - doener
https://gitlab.com/gnutls/gnutls/-/issues/1011
======
taspeotis
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](https://nvd.nist.gov/vuln/detail/CVE-2020-13777)

~~~
dbrgn
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](https://twitter.com/__agwa/status/1270054738344792070)

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

------
bmurray7jhu
> [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...](https://www.openldap.org/lists/openldap-
devel/200802/msg00072.html)

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

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

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

~~~
agwa
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

[https://gitlab.com/gnutls/gnutls/-/issues/1011#note_35383063...](https://gitlab.com/gnutls/gnutls/-/issues/1011#note_353830633)

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

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

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

------
mijoharas
I was wondering how commonly used gnutls was.

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

~~~
cesarb
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
I use it on a server. Way easier to use than opennsl, to my taste.

------
billpg
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
No, just a GnuTLS bug that was fixed in its recent release

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

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

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

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

------
microtherion
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](https://www.oreilly.com/openbook/freedom/ch07.html#86161)

