GnuTLS audit: passive cleartext recovery attack | Hacker News Reader

GnuTLS audit: passive cleartext recovery attack

anarc.at

146 pointsmasklinn25 comments

> 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

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

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

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... [2] https://www.gnu.org/licenses/license-list.en.html#apache2

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.

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

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

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

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

It doesn’t.

apt (dpkg) binaries need to be anyway PGP signed, so HTTPS is just a another layer of security, which is mostly redundnant. Not too long ago, apt in fact predominantly used HTTP. However, then this MITM vulnerability was found that would've been avoided by using HTTPS, and I think they pretty much switched to using HTTPS from then on: https://justi.cz/security/2019/01/22/apt-rce.html

I thought apt repos are just usual web servers.

I don't think it's common to use gnutls for a web server.

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.

Too-few-eyeballs is a sad reality for much security-sensitive code, isn't it?

Serious security audits aren't cheap.

I am not commenting on being nervous or not, but the reason I use gnutls is the documentation. Getting started with gnutls is so much easier than the competition that I just didn't bother with anything else for my hobby projects.

I am happy that they are getting audits. I don't know whether I would use it if someone paid me to write something secure, but I hope that the audits will result in a future where it would be a good option.

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.

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

rustls recently received a third party security audit and seemed to do quite well, if you're looking for an alternative:

http://jbp.io/2020/06/14/rustls-audit.html

I recently saw this paper which describes several ways in which OpenSSL is better than it was: "The impact of Heartbleed on openssl's development practices" https://arxiv.org/abs/2005.14242

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

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

Tired I guess, I misread.

> Is it 2 years, or 10 years? I don't understand how they arrive to 10 years here.

2 years, 10 releases. More than one release per year.[1]

1. https://gnutls.org/news.html

Erf, I was too slow to edit my comment when I noticed that I misread, my bad.

If editing a comment to be completely different from the original, it's good form to leave the original and write an "EDIT:", or at least refer to the original mistake, especially when several people have replied to that original comment.

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?

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.

Reply on news.ycombinator.com