The latest OpenSSL vulns were added fairly recently
twitter.com
twitter.com
Here's a recent presentation about LibreSSL and some of those points: https://www.youtube.com/watch?v=bF1d_aCSzS0
Years ago there was also a big article from Alpine, one of the distros that tried to switch to it and had to switch back. The now-outdated article seems to be the main citation for those opposed to even giving LibreSSL a chance now. In fact Alpine is reconsidering a switch back from OpenSSL after the 3.x branch was shown to be such a disaster.
One of the LibreSSL developers summarized this recent OpenSSL issue in a commit message worth reading: https://marc.info/?l=openbsd-ports-cvs&m=166731803502387&w=2
I've suggested in the past that the OS should handle transport encryption. People moan "oh no then we can't fix anything! oh no we can't innovate!". But adding encryption routines to the OS does not remove the ability to use OpenSSL. People will continue to invent their own userland tcp/ip stacks regardless. But having the OS team handle the encryption at least gives one large well-funded organization the burden of doing it right or being really embarrassed. The upshot is every application can simply pick up encryption functionality without depending on a 3rd party library. A new flag to existing syscalls could wrap opening any socket with some standard encryption method, so the application would never need to bother with "doing encryption", unless it wanted to. And the system keychain can manage credentials. The whole point of the OS is to make life easier for apps and users; why not let it do more of the heavy lifting?
But, depending on the OS you're using, the organization is not necessarily well-funded. Even those who are and use OpenSSL (Red Hat) haven't caught this one.
I assume that you're not mixing up "OS" and "kernel", because adding more attack surface to a monolithic kernel is never a good idea.
At any rate, I don't see why you think that tying TLS to the kernel is required to improve the security posture. OpenSSL can remain a library, and the same companies that fund the Linux kernel can fund OpenSSL. Hell, the people who maintain the existing crypto functionality in the kernel can work on OpenSSL if they so choose.
Then there's the matter of adoption: the main reason that LibreSSL has failed on Linux is because developers don't seem to want to move to it in their applications, despite it having very few differences from OpenSSL. What makes you think developers will adopt a completely different Linux-specific API that doesn't work on any other OS?
The rest of the ecosystem would simply follow, as maintaining an alternative is extra work, and, as openssl is simply worse, pointless.
Wikipedia claims that (as of 2019) they have 2 FTE's worth, plus a dozen or so volunteers...who are a big overlap with their management committee. And their total budget is < $1M/year.
Not to suggest that volunteer coders are automatically lesser coders...but for widely-used, uber-critical, uber-complex code, that sounds pretty profoundly under-resourced.
Edit: Adding the full quote from Wikipedia: "As of May 2019,[7] the OpenSSL management committee consisted of 7 people[8] and there are 17 developers[9] with commit access (many of whom are also part of the OpenSSL management committee). There are only two full-time employees (fellows) and the remainder are volunteers."
https://github.com/openssl/openssl/graphs/contributors?from=...
They might be every bit as competent, but it's unreasonable to expect volunteers to put in as much time as someone who does it as a job.
We should not reward bad practices with funding.
I've always been somewhat skeptical that funding (or rather, the lack thereof) is main reason for OpenSSL's problems. The whole funding thing is mainly a question of fairness, rather than security or quality.
Certainly heartbleed was IMHO not really caused by a lack of funding. It was an experimental extension that no one really used and no one really needed either that was nonetheless enabled by default. That was just a bad call, which happens – live and learn – but no amount of monetary units can protect you from mistakes like that. The entire heartbeat code ended up being removed in 2019 as no one used it.
[1]: https://www.openssl.org/blog/blog/2021/11/24/hiring-manager-...
[2]: https://www.openssl.org/blog/blog/2022/05/18/hiring-business...
Heartbleed was partially because they hadn't fully adopted techniques like fuzzing in regular use, so when researchers started fuzzing everything, out popped heartbleed. Now OpenSSL does fuzzing on (every PR, IIRC?) The author is a bit unfair in calling the project out as if they don't do it.
There still aren't a lot of developers on it relative to the complexity of the project though. Frankly there are large parts of the codebase that are pretty intimidating to touch, like the X.509 stuff implicated here.
Sounds like the old problem of "Well, the hospital might have enough surgeons overall...but this case is gonna need a real good pediatric brain surgeon or two, and that's a different story..."
It was never meant to be, it's only providing a subset of the features openssl has.
>The OpenBSD people forked to LibreSSL which looked very promising (coming from people who make their main obsession about security) but seemed to quickly burn out at least on Linux hosts
In the beginning yes it was, they moved fast on cleaning up OpenSSL codebase. The problems began because it's not explicitly a goal to maintain OpenSSL compatibility, so distros had a huge maintenance burden patching things to work with it. Eventually the distros that were maintaining it (Void and Gentoo?) got tired of it and decided OpenSSL had gotten through the worst of its problems.
Then OpenSSL 3 dropped, once again making it annoying to patch for and introducing issues like this CVE. I think Alpine was discussing looking at LibreSSL again but I think that ship has sailed.
I suppose a Linux distro could hypothetically take the same approach and use a mixture of both, but realistically most people don't want to bother with that.
Personally I'd love a Linux distro with a BSD-style base system and extra packages kept separately, but the closest to that would be ... Slackware with pkgsrc or something I guess.
Theo Buehler talked about the current status of LibreSSL compatibility at EuroBSDcon last week. To take some quotes:
“> 2000 OpenBSD ports link against libcrypto or libssl” [i.e., LibreSSL]
“< 100 of these need patches (< 5%)”
“6 ports link against OpenSSL”
Some years ago, I have reproduced Hanno Böcks fuzzing to find Heartbleed "again". It wasn't that hard to do and I was completely new to the whole thing. Everybody had time to get up to speed with that as I did and implement it in the workflow.
The manpower problem becomes worse over time when you do poor quality work, because things are not really done and you cannot fully concentrate on further work because there is so much maintenance and rework. Stellar work doesn't have to cost much. Good, reliable software can get built extremely cheaply.
Of course, OpenSSL and many other projects face many typical problems. Protocols are under specified, sometimes extremely complicated or the way the protocol is described is extremely unreadable and for all these reasons the specifications are not crystal clear. Then you have practical implementations that can vary a lot, if the standard is poorly written/ thought out or one implementing party has a monopoly and can do whatever they want they tend to diverge. Then of course, there are protocols which originally were simple but got extended over time with things that are used everywhere but not really standard and such. Also, you can have wrong tools or use your tools badly. C and many other languages require a lot more discipline than some viable alternatives that would in many cases cream at you or handle the situation for you. C is like a table saw without safety. Yes, it does get the job done but you might loose a finger or a hand in the process and even the best do at some point. Parsing anything in C seems to me to be a clear "danger" zone, where you tripple check everything.
Unless I missed something he claims that, he doesn’t show it.
With the rate he is showing (38/second) it'd take just under 5 minutes (~254 seconds).
Isn't this a time claim?
https://github.com/google/oss-fuzz/blob/master/projects/open...
I would consider the alternatives before going to OpenSSL.
Considering OpenBSD's reputation for proactive security, I'd say LibreSSL might be the best alternative out there.
On the BSD's I've used, LibreSSL is a standard kernel configuration option. I'll note on FreeBSD, LibreSSL lacks the in-kernel fast path, last I checked.
Google uses BoringSSL[1], which is another OpenSSL fork. I believe AWS uses a mix of OpenSSL and Boring SSL (someone can correct me!).
So it's "their own encryption stack," but that stack is at least originally comprised of OpenSSL's code. They've probably done an admirable job of refactoring it, but API and ABI constraints still apply (it's very hard to change the massive body of existing code that assumes OpenSSL's APIs).
Seems like the big players came, saw, borrowed, and then did their own thing without contributing back.
If this were my project, I would be inclined to archive it and do a GPL fork.
Otherwise, couldn't some openssl contributors just crib fixes from the forks?
> Otherwise, couldn't some openssl contributors just crib fixes from the forks?
They do! But I assume it gets balanced with their own feature development time, and it becomes harder as the codebases drift. OpenSSL probably hasn't done itself many favors with the recent (3.x) "providers" refactor.
Apple uses LibreSSL, not OpenSSL.
@Ytterbium ~ % uname -a
Darwin Ytterbium.local 22.1.0 Darwin Kernel Version 22.1.0: Sun Oct 9 20:15:52 PDT 2022; root:xnu-8792.41.9~2/RELEASE_ARM64_T8112 arm64
@Ytterbium ~ % openssl version
LibreSSL 3.3.6Adoption is the default for a few BSDs, OpenSSH on Windows, macOS.
From a usage standpoint, you're probably correct (I honestly don't know) -- I only use it to generate web server certificates.
Taking a look at x509.c[1] which I believe is the most likely to be able to reach the punnycode parser. (I am not at all familiar with the codebase). You can see that the OpenSSL fuzzer is basically doing a holistic fuzz (I assume the i2d* and d2i* functions exercise the parser), that is its just invoking key entrypoints that in theory can exercise all the rest of the functionality with the correct inputs.
Hanno's fuzzer on the other hand, is explicitly only testing the `ossl_punnycode_decode` function[3].
Given the breadth of the fuzzer, I think its very possible OSS-Fuzz just didn't hit it.
[0] https://github.com/openssl/openssl/blob/master/fuzz/
[1] https://github.com/openssl/openssl/blob/master/fuzz/x509.c
[2] https://twitter.com/hanno/status/1587775675397726209/photo/2
That is why OpenSSL is so extremely important, and I seriously wonder why the industry bigwigs haven't stepped up and created a foundation/trust flush with cash to make sure that continuous development of these libraries, regular audits, certifications and testing is paid for.
Out of the big names in tech, I think the only people not depending on Linux at all is Netflix, they're famous for running a massive FreeBSD shop (but that doesn't mean they're not using OpenSSL in their application infrastructure, never read anything about that side of their business). Not sure about Google, they do a lot of yak shaving and reinventing wheels. MS and Amazon run Linux as part of their clouds at the very least.
I'm curious: in what role was this? In the short exposure I had to federal contracting, I saw few efforts along these lines. It would have been a good idea!
https://www.microsoft.com/en-us/research/blog/project-everes...
This is the future.