Hacker News Reader

Comment by stefan_ | Hacker News Reader

The words "GnuTLS" or "mbedTLS/PolarSSL" strike fear into my heart. When picking a TLS library written by amateur cryptographers, make sure it is the one used by everyone else (OpenSSL).

View on HN

GnuTLS has a non-crazy well documented API with loads of good quality examples, which is why we chose it for libvirt. (It was impossible for us to understand how to use OpenSSL for basic stuff like opening a connection at the time we made that choice - I sure hope it's improved now.) The lesson is if you want adoption you need to have a clear API with no foot-guns, lots of examples and documentation.

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.

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.

OpenSSL fixed their licensing issues: https://wiki.openssl.org/index.php/OpenSSL_3.0#License_Chang...

Unfortunately, OpenSSL is only in alpha right now. And they didn't do an LLVM-style exception to resolve the issues with GPLv2 software.

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

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.

Because there are 2 people who contribute massively more than the others, it's rather hard to see the regular work done by other contributors by looking at the graphs.

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:

https://github.com/gnutls/nettle/graphs/contributors

GnuTLS doesn't use libgcrypt. Or at least it's not required. It uses nettle.

Yes you're completely right, I updated my comment.

Still, that means if there's any new change, there's maybe one other person to review it in gnutls and ... none in nettle. Seems like if niels-moller makes a mistake, we won't know until a CVE.

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.

>Fortunately, OpenSSL has improved significantly in the last few years.

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.

Isn't mbedTLS part of ARM now? For microcontrollers / bare metal devices that need to connect via Ethernet, it is probably one of the more reputable ones - unless there's another major library I haven't heard of?

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.

Do you know a better library to use for bare-metal purposes then? Because with mbedTLS at least you can get security updates and the code is scrutinised publicly. Way better than some proprietary crypto stacks I have seen where they charge you money for updates.

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

BearSSL (https://bearssl.org/) works great. It is written by someone who both understands the cryptography at depth and how to write secure C code for embedded environments.

Yeah. I recall OpenSSL used to have issues of lack of contributors. [1]

Anyone have any reasons why it wouldn't be crazy to use a small project's solution?

[1]https://arstechnica.com/information-technology/2014/04/tech-...

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

Unfortunately Apache v2 is still not compatible with GPLv2-only, so OpenSSL 3.0 will not solve all of the licensing issues, but some of them it will.

Incidentally, an OpenSSL 3.0 alpha just reached Debian experimental.

OpenSSL WAS good library in past. Today it's bloatware.

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.

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.

Back around the time of Heartbleed, there was a bunch of childish[1,2] attention given to OpenSSL's warts, mostly centered around the OpenBSD fork called LibreSSL, which stripped out a lot bad, old code and code for non-Unix platforms.

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.

[1] https://opensslrampage.org/page/49

[2] https://opensslrampage.org/post/83555615721/the-future-or-la...

I have previously characterized OpenSSL as "Stamp collector cryptography". Here's an implementation of IDEA. Should you use IDEA? No. So why is this even here?

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.

Reply on news.ycombinator.com