> 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).
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.
-Howard Chu (2007)
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.
> "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.
> ticket encryption key and decryption key are all-zero [...] in TLS 1.2, it may allow attackers to recover the previous conversations
It's crucial to point out that this is a GnuTLS bug not a TLS one.
Gnutls is required by (among others) ffmpeg, emacs, vlc and wget.
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:
qemu / libvirt
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?
Edit: The title has since been fixed.
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.
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.
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.
Additionally, the licensing for GnuTLS is a lot clearer than OpenSSL's, and that made it easier to understand how we could use it.
And improved licensing doesn't fix the horrible API, nor the lack of discipline to prevent API/ABI repeated breakages within the same version series. We'll see if they do better with this in OpenSSL 3.x...
Seems like a 2-people project, where 1 dropped off, and 2 new devs recently joined.
Also gnutls is "just" an API and a framework for TLS, all the crypto primitives work happens in libgcrypt: https://github.com/gpg/libgcrypt/graphs/contributors
EDIT: not libgcrypt, libnettle:
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.
I'm not disagreeing with you here, I just want to prevent the stuff I made on from being features on @internetofshit twitter and similar places
"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 firstname.lastname@example.org. All feedback received by email is treated confidentially."
Anyone have any reasons why it wouldn't be crazy to use a small project's solution?
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. 
Incidentally, an OpenSSL 3.0 alpha just reached Debian experimental.
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.
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.
Unsurprisingly, the childish attention faded into nothing because it's much harder to write good code than it is to tear apart someone else's. But the smear on the OpenSSL volunteers' reputation remains, as seen by GP's comment.
Compare the Go crypto reaction when somebody wants to add ECB mode: https://github.com/golang/go/issues/5597
OpenSSL is better now than it was then, it might even be the least worst option for a lot of people in low-level languages who want to spin up a TLS client or server. But that is deliberately faint praise.