4 ms·

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 b

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

Jonnax 6y ago
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-giants-chastened-by-heartbleed-finally-agree-to-fund-openssl/ https://arstechnica.com/information-technology/2014/04/tech-...
- terom 6y ago
  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 https://people.gnome.org/~markmc/openssl-and-the-gpl [2] https://www.openssl.org/source/license.html https://www.openssl.org/source/license.html
  - pabs3 6y ago
    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.
ssfivy 6y ago
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?
- mobilio 6y ago
  Yes - it's part of ARM Holdings from November 2014. https://github.com/ARMmbed/mbedtls 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."
- stefan_ 6y ago
  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.
  - ssfivy 6y ago
    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
    - stefan_ 6y ago
      BearSSL (https://bearssl.org/ 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.
rwmj 6y ago
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.
- Conan_Kudo 6y ago
  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.
  - rrdharan 6y ago
    OpenSSL fixed their licensing issues: https://wiki.openssl.org/index.php/OpenSSL_3.0#License_Change https://wiki.openssl.org/index.php/OpenSSL_3.0#License_Chang...
    - Conan_Kudo 6y ago
      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...
- viraptor 6y ago
  It doesn't seem like a lot of people contribute though: https://github.com/gnutls/gnutls/graphs/contributors https://github.com/gnutls/gnutls/graphs/contributors Seems like a 2-people project, where 1 dropped off, and 2 new devs recently joined.
mobilio 6y ago
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.
- lsofzz 6y ago
  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.
- shinigami 6y ago
  It's the opposite, really. It improved a lot after the heartbleed issue.
- simias 6y ago
  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.
  - coldpie 6y ago
    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 https://opensslrampage.org/page/49 [2] https://opensslrampage.org/post/83555615721/the-future-or-lack-thereof-of-libressls-fips https://opensslrampage.org/post/83555615721/the-future-or-la...
    - 6y ago

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

Jonnax 6y ago

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-giants-chastened-by-heartbleed-finally-agree-to-fund-openssl/ https://arstechnica.com/information-technology/2014/04/tech-...

terom 6y ago
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 https://people.gnome.org/~markmc/openssl-and-the-gpl [2] https://www.openssl.org/source/license.html https://www.openssl.org/source/license.html
- pabs3 6y ago
  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.

ssfivy 6y ago

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?

mobilio 6y ago
Yes - it's part of ARM Holdings from November 2014. https://github.com/ARMmbed/mbedtls 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."
stefan_ 6y ago
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.
- ssfivy 6y ago
  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
  - stefan_ 6y ago
    BearSSL (https://bearssl.org/ 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.

rwmj 6y ago

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.

Conan_Kudo 6y ago
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.
- rrdharan 6y ago
  OpenSSL fixed their licensing issues: https://wiki.openssl.org/index.php/OpenSSL_3.0#License_Change https://wiki.openssl.org/index.php/OpenSSL_3.0#License_Chang...
  - Conan_Kudo 6y ago
    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...
viraptor 6y ago
It doesn't seem like a lot of people contribute though: https://github.com/gnutls/gnutls/graphs/contributors https://github.com/gnutls/gnutls/graphs/contributors Seems like a 2-people project, where 1 dropped off, and 2 new devs recently joined.

mobilio 6y ago

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.

lsofzz 6y ago
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.
shinigami 6y ago
It's the opposite, really. It improved a lot after the heartbleed issue.
simias 6y ago
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.
- coldpie 6y ago
  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 https://opensslrampage.org/page/49 [2] https://opensslrampage.org/post/83555615721/the-future-or-lack-thereof-of-libressls-fips https://opensslrampage.org/post/83555615721/the-future-or-la...
  - 6y ago