> 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
OpenSSL isn't perfect but it has improved considerably since Heartbleed and has the resources (funding and competent people) that a crypto project needs.
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).
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.
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 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.
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.
> 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".
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!).
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.
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.