GnuTLS: TLS 1.3 session resumption works without master key, allowing MITM

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.

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.

I use it on a server. Way easier to use than opennsl, to my taste.

>For obvious reasons, systemd ships a custom http server with client auth via GnuTLS.

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?

Claws Mail uses it as well: https://www.claws-mail.org/downloads.php

OpenSSL has licensing issues when linking with GPL applications (without an explicit exception in the GPL-licensed application, which is not uncommon). [1]

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. [2]

[1] https://people.gnome.org/~markmc/openssl-and-the-gpl

[2] https://www.openssl.org/source/license.html

Yes - it's part of ARM Holdings from November 2014.

https://github.com/ARMmbed/mbedtls

"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 mbed-crypto@arm.com. All feedback received by email is treated confidentially."

It's "part of ARM" like random Java projects become "part of the Apache foundation". Its reputation is the unmistakable ability to always fall on the side of broken/unmitigated whenever someone discovers another TLS protocol problem, apart from a history of the usual code execution and memory safety issues (the latter, of course, extremely difficult to mitigate on anything that has the name "embedded").

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.

This statement is basically the reason why we use GnuTLS as well. In fact, we've basically universally migrated our applications away from OpenSSL to GnuTLS because it's a much better library to use and ship.

Additionally, the licensing for GnuTLS is a lot clearer than OpenSSL's, and that made it easier to understand how we could use it.

It doesn't seem like a lot of people contribute though: https://github.com/gnutls/gnutls/graphs/contributors

Seems like a 2-people project, where 1 dropped off, and 2 new devs recently joined.

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.

It's hard to know exactly how bloated SSL/TLS libraries have become without actually taking the time to research them but some of the folks behind `LibreSSL` seem to know crypto well enough.

It's the opposite, really. It improved a lot after the heartbleed issue.

You'll have to substantiate these assertions. When was it good? Why is it bloatware today?

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.