I was actually surprised to see this announcement in the newer 3.x codebase… the whole idea of 3.x was to improve upon the problematic areas of 1.x that were a constant source of vulnerabilities. Though I guess the code is too complex at this point to make it any simpler, or simply has too many features used by too many people which could not be deprecated and continue as huge technical baggage.
LibreSSL is an excellent alternative, though lack of any FIPS 140-2 (and soon -3) validation makes it a no-go for many commercial use cases where Government/Federal customers.
It was just a matter of time. Back when Gentoo dropped LibreSSL, I was saddened, as I used it personally in my tree and like the spirit behind the project a lot.
Maybe a better approach would have been to really start with a fresh API (and new name!) based on the OpenSSL-codebase. The main source of problems I noticed in porting-compatibility was that functions would silently break or do something differently, leading to subtle bugs. No one questions that LibreSSL has a higher code quality than OpenSSL, but I totally understand when someone burns their fingers once or twice and simply drops the code completely or, for some reason, is nostalgic about FIPS-support.
Maybe a change of language is also adequate. I’m not talking about Rust, but Ada with SPARK, which provides even more guarantees than Rust ever will and is an industry standard. There used to be libadacrypt, but the project seems to be dormant.
But, as a conclusion: For something as vital as a crypto library, we need a diversity of implementations. There will always be bugs, and it can’t be that we’re all using one implementation that leads to the entire technology-stack begin affected by it.
If I had to choose a crypto-library right now, I’d definitely give BearSSL a chance. What a great project!
If I had to choose a crypto-library right now, I’d definitely give
BearSSL a chance. What a great project!
I’ve heard good things about it.
I think libtls from libressl is a great high-level API for TLS. It can
be built standalone from the libressl codebase, which is what Void Linux
does. I know of at least one third-party implementation:
https://git.causal.agency/libretls/about/
There will also be a bug fix release of OpenSSL 1.1.1s at the same time as they still need to release the fixed fixes from the retracted 1.1.1r version. However, the 1.1.1 branch is not affected by the critical issue.
It’s a widely used library implementing both new and legacy algorithms, where almost every line has security implications. Why would you not expect a significant issue with it periodically?
They’re not doing the same thing though. Libre started with removing a lot of code and rarely used cyphers. It’s a good thing of course, but they did limit the scope so the issue rate fell.
Then openssl adopted some of the generic improvement ideas from libre, so they are getting closer as well.
Yes, that’s a very valid method of getting to a more secure library. That’s like saying “you can’t compare an SUV’s mileage to a hybrid car’s mileage because they’re different weights” - they are indeed different weights, but that’s the point and that’s why they’re being compared.
But even setting that aside, a lot of the code LibreSSL removed was not just rarely used ciphers. It was stuff like, an internal, bespoke malloc() implementation that defeated tools like Valgrind and OpenBSD’s hardened malloc() implementation (OpenSSL would call libc malloc() once at startup to allocate what essentially amounts to an arena and then divvy up the arena to callers with an OpenSSL function). Things like, support code targeting the lowest common denominator so OpenSSL could run on e.g. VMS (except that even when there were better platform APIs, they wouldn’t be used over the lowest common denominator stuff). All of this stuff is complexity that increases the likelihood of bugs, security or otherwise, but does not impact what ciphers/APIs/whatever other properties you care about as a consumer are available.
I was actually surprised to see this announcement in the newer 3.x codebase… the whole idea of 3.x was to improve upon the problematic areas of 1.x that were a constant source of vulnerabilities. Though I guess the code is too complex at this point to make it any simpler, or simply has too many features used by too many people which could not be deprecated and continue as huge technical baggage.
LibreSSL is an excellent alternative, though lack of any FIPS 140-2 (and soon -3) validation makes it a no-go for many commercial use cases where Government/Federal customers.
Typo: “…many commercial use cases for Government/Federal customers”
This is what we get for not switching to libressl the first chance we had.
It’s confirmed that LibreSSL is not vulnerable: https://www.openwall.com/lists/oss-security/2022/10/29/2
So much for the effort to remove it from CPython: https://peps.python.org/pep-0644/
It was just a matter of time. Back when Gentoo dropped LibreSSL, I was saddened, as I used it personally in my tree and like the spirit behind the project a lot.
Maybe a better approach would have been to really start with a fresh API (and new name!) based on the OpenSSL-codebase. The main source of problems I noticed in porting-compatibility was that functions would silently break or do something differently, leading to subtle bugs. No one questions that LibreSSL has a higher code quality than OpenSSL, but I totally understand when someone burns their fingers once or twice and simply drops the code completely or, for some reason, is nostalgic about FIPS-support.
Maybe a change of language is also adequate. I’m not talking about Rust, but Ada with SPARK, which provides even more guarantees than Rust ever will and is an industry standard. There used to be libadacrypt, but the project seems to be dormant.
But, as a conclusion: For something as vital as a crypto library, we need a diversity of implementations. There will always be bugs, and it can’t be that we’re all using one implementation that leads to the entire technology-stack begin affected by it.
If I had to choose a crypto-library right now, I’d definitely give BearSSL a chance. What a great project!
I’ve heard good things about it.
I think libtls from libressl is a great high-level API for TLS. It can be built standalone from the libressl codebase, which is what Void Linux does. I know of at least one third-party implementation: https://git.causal.agency/libretls/about/
Yes, I can’t believe I forgot libtls. It’s a great piece of software!
It sounds like it’s only going to impact v3.x. If it also applied to v1.x they’d have announced a patch release for that too right?
There will also be a bug fix release of OpenSSL 1.1.1s at the same time as they still need to release the fixed fixes from the retracted 1.1.1r version. However, the 1.1.1 branch is not affected by the critical issue.
Thanks for the link mate! 💙
Another OpenSSL CVE, what a surprise!
It’s a widely used library implementing both new and legacy algorithms, where almost every line has security implications. Why would you not expect a significant issue with it periodically?
Because LibreSSL proved that the same thing can be done with a far lower rate of vulnerabilities.
They’re not doing the same thing though. Libre started with removing a lot of code and rarely used cyphers. It’s a good thing of course, but they did limit the scope so the issue rate fell.
Then openssl adopted some of the generic improvement ideas from libre, so they are getting closer as well.
Yes, that’s a very valid method of getting to a more secure library. That’s like saying “you can’t compare an SUV’s mileage to a hybrid car’s mileage because they’re different weights” - they are indeed different weights, but that’s the point and that’s why they’re being compared.
But even setting that aside, a lot of the code LibreSSL removed was not just rarely used ciphers. It was stuff like, an internal, bespoke malloc() implementation that defeated tools like Valgrind and OpenBSD’s hardened malloc() implementation (OpenSSL would call libc malloc() once at startup to allocate what essentially amounts to an arena and then divvy up the arena to callers with an OpenSSL function). Things like, support code targeting the lowest common denominator so OpenSSL could run on e.g. VMS (except that even when there were better platform APIs, they wouldn’t be used over the lowest common denominator stuff). All of this stuff is complexity that increases the likelihood of bugs, security or otherwise, but does not impact what ciphers/APIs/whatever other properties you care about as a consumer are available.
Look at virtually anything on this (admittedly snarky) blog for more.