
GnuTLS audit: passive cleartext recovery attack - masklinn
https://anarc.at/blog/2020-06-10-gnutls-audit/
======
agwa
> Also, because it relies on session tickets, there's a time window after
> which the ticket gets cycled and properly initialized. But that is
> apparently 6 hours by default so it is going to protect only really long-
> lasting TLS sessions, which are uncommon, I would argue.

I'm the author of the Tweet which this paragraph links to. The author of this
blog post is misinterpreting the problem. It's not the session _ticket_ which
is rotated after 6 hours, but the session ticket encryption _key_ (STEK). This
has nothing to do with the length of the TLS session, but rather the lifetime
of the process using GnuTLS. For the first 6 hours, connections made to the
GnuTLS server are vulnerable. After the process has been running for 6 hours,
new connections are safe (assuming there's no other GnuTLS vulnerability).
This reduces the impact of the vulnerability considerably (although it's still
really bad).

> It is likely that people don't have OpenSSL in mind when they suggest moving
> away from GnuTLS

No, OpenSSL is exactly what we have in mind, including Filippo:
[https://twitter.com/FiloSottile/status/1270130358634283008](https://twitter.com/FiloSottile/status/1270130358634283008)

OpenSSL isn't perfect but it has improved considerably since Heartbleed and
has the resources (funding and competent people) that a crypto project needs.

~~~
gioele
> > It is likely that people don't have OpenSSL in mind when they suggest
> moving away from GnuTLS

> No, OpenSSL is exactly what we have in mind, including Filippo:
> [https://twitter.com/FiloSottile/status/1270130358634283008](https://twitter.com/FiloSottile/status/1270130358634283008)

Please note that the next version of OpenSSL (version 3) will be licensed
under the Apache 2.0 license [1], making it incompatible with GPL v2 libraries
and applications [2].

GPL v2 applications will be stuck with OpenSSL 1.x (or GnuTLS or other libs).

[1]
[https://wiki.openssl.org/index.php/OpenSSL_3.0#License_Chang...](https://wiki.openssl.org/index.php/OpenSSL_3.0#License_Change)
[2] [https://www.gnu.org/licenses/license-
list.en.html#apache2](https://www.gnu.org/licenses/license-
list.en.html#apache2)

~~~
agwa
To be clear, it will be incompatible with GPLv2- _only_ software. Projects
which use the default GPLv2 license notice will be able to link with OpenSSL 3
without problem, since the notice permits the software to be re-licensed under
newer versions of the GPL.

Also note that the old OpenSSL license was incompatible with both GPLv2 and
GPLv3 (unless the project provided an exception for OpenSSL). So OpenSSL 3's
license change _increases_ compatibility with GPL software.

------
resfirestar
This post is misleading I think, the problem as described in [1] is with the
TLS server in gnutls, regardless of the client software. How does that impact
packages like apt and mutt, which aren’t serving anything?

To be fair, the post does mention this, but I’m struggling to see why the
author would mention those packages in the first place except for
sensationalism.

[1]
[https://gitlab.com/gnutls/gnutls/-/issues/1011](https://gitlab.com/gnutls/gnutls/-/issues/1011)

~~~
nine_k
No idea about mutt, but it does affect apt _repos_ if they are served via
GnuTLS, though not the client apt software.

~~~
resfirestar
If the repos were served with GnuTLS (not likely), it wouldn’t matter if the
apt client used GnuTLS or not.

~~~
lmm
They're talking about the debian package called "apt", not the binary called
"apt", so it's possible that it includes a server?

~~~
resfirestar
It doesn’t.

------
_-___________-_
I always feel a bit nervous when software uses GnuTLS. Far less usage and far
fewer eyeballs on the source code mean this probably isn't the only serious
vulnerability hiding in plain sight. On the other hand, having multiple
implementations of TLS seems like a good thing for finding bugs (or areas of
risk) in the standards, and for ensuring interoperability.

~~~
dijit
On the flip side: I’m really not happy with the state of OpenSSL- it hasn’t
improved markedly since libreSSL began either.

Eyeballs mean nothing when the code is a dense ball of mud.

~~~
psanford
> it hasn’t improved markedly since libreSSL began either

That's not really true. Pre-heartbleed there were very few contributors to
OpenSSL. After heartbleed the management of the project was overhauled. There
was also a large inflow of funding (Linux Foundation’s Core Infrastructure
Initiative) and new contributors.[0]

In 2018 the OpenSSL team was one of the winners of the Levchin prize "for
dramatic improvements to the code quality of OpenSSL".

[0]: [https://www.securityweek.com/evolution-openssl-security-
afte...](https://www.securityweek.com/evolution-openssl-security-after-
heartbleed)

------
dgellow
In case you're asking yourself, this article is from June 10th. And the CVE
has been published June 4th. So that's already one month and a half ago
(please display publishing date in your blog posts!).

~~~
detaro
How do you get from a quote saying "past 10 releases" to "10 years"?

~~~
dgellow
Tired I guess, I misread.

------
mlichvar
Do most TLS-based protocols and applications use session tickets? From the
gnutls documentation it looks like it's something that needs to be supported
in the code, on both servers and clients. Is a client that cannot resume a
session vulnerable to this issue?

~~~
tialaramex
In TLS 1.2 a client is vulnerable _if_ a session ticket is issued, regardless
of whether it was ever used. The ticket contains enough information to decrypt
everything from your session if an adversary knows or subsequently learns the
STEK to decrypt the ticket.

In TLS 1.3 it matters whether you use the ticket, if you just discard tickets
they can't hurt you, if you use the ticket while an on-path adversary knows
the STEK they could MITM you.

As a result in TLS 1.2 it matters whether the TLS client implementation
reports willingness to accept tickets, not on whether you've written code to
actually ever use the resulting tickets. If your library says "Sure, send me a
ticket" then in TLS 1.2 the only thing protecting your session is the STEK
inside the server, if that leaks or isn't actually random you lose regardless
of what you do with the tickets including throwing them away.

