From https://www.openbsd.org/papers/eurobsdcon2014-libressl.html
> Heartbleed can't even be considered the worst OpenSSL vuln. Previous bugs have resulted in remote code execution. Anybody remember the Slapper worm? That worm exploited an OpenSSL bug (which was apparently titled the SSLv2 client master key buffer overflow) which revealed not only encrypted data or your private key, but also gave up a remote shell on the server, and then it propogated itself. Yeah, I'd say that's worse. But no headlines.
> I mention this just to reinforce that LibreSSL is not the result of "the worst bug ever". I may call you dirty names, but I'm not going to fork your project on the basis of a missing bounds check.
> why fork
> Instead, libressl is here because of a tragic comedy of other errors. Let's start with the obvious. Why were heartbeats, a feature only useful for the DTLS protocol over UDP, built into the TLS protocol that runs over TCP? And why was this entirely useless feature enabled by default? Then there's some nonsense with the buffer allocator and freelists and exploit mitigation countermeasures, and we keep on digging and we keep on not liking what we're seeing. Bob's talk has all the gory details.
You can see "Bob's talk" here: https://www.openbsd.org/papers/bsdcan14-libressl/ though I think there is a YouTube video somewhere.
Also I would like to point out that Google also forked OpenSSL. So it seems that the LibreSSL folks are not the only ones who thought a fork was necessary.
"LibreSSL with Bob Beck" at https://www.youtube.com/watch?v=GnBbhXBDmwU
I think I actually got grey hairs from that...
Then I realised that OpenSSL is quite entrenched, I'm still running it to this day, in production.
A lot of that uglyness seems to come from the fact that OpenSSL wants to support all environments (even DOS). I wonder why distributions haven't switched since LibreSSL was made to be API/ABI compatible with openSSL and target a POSIX OS. This would be much more justified than the ffmepg / libav thing imo.
LibreSSL is neither API compatible with newer OpenSSL versions, nor is it ABI compatible. In fact, they break ABI every six months. Furthermore LibreSSL upstream only targets OpenBSD, with the portable version existing as an afterthought.
The only linux distribution using LibreSSL is Void Linux (Alpine switched to OpenSSL some time ago). Even Void is considering switching to OpenSSL: https://github.com/void-linux/void-packages/issues/20935 .
The slides came out in 2014 so the API / ABI thing was probably true then but not anymore.
Maybe things would have been different if LibreSSL was backed by a major Linux distribution and OpenBSD. Even then Unix/Linux is not the only target of a lot of software and I doubt a lot of developer would have put the time to support both.
[Edit] I just saw in an other comment that LibreSSL is used in MacOSX and windows for openSSH. Maybe developers will consider it if it becomes available on major platforms
1. It's a ton of packaging work even if the API/ABI were compatible (Calling it compatible is a bit of a stretch IMO).
2. One of the things LibreSSL removes is the FIPS validated stuff. Distributions that harbor ambitions of being used in large US corporate and government installations want that.
3. By the time the portable LibreSSL build system came out, there were already significant improvements afoot within the OpenSSL project.
I'm sure there are other reasons, but those are the big ones I'm aware of.
Sounds like it could have happened if someone went to bat for it. Red Hat deciding to include it (even if they didn't replace OpenSSL with it immediately) and pushing to get it certified and the portability stuff more stable would have done this.
> 3. By the time the portable LibreSSL build system came out, there were already significant improvements afoot within the OpenSSL project.
That's probably the real reason. Although, given the stuff mentioned in that bug/talk and how much seems to have been based on extreme portability, unless OpenSSL decided to just give up on some aspects of that (I doubt it), then some of the problems (code complexity, not to mention ROP helpers) probably survive (not that I know).
Someone correct me if I'm wrong, but I seem to remember either BoringSSL or LibreSSL (or both?) saying that their fork removed support for DOS because not only did almost nobody use it, but it didn't even work anyways.
OpenSSL implemented its own memory management system instead of using malloc. It would allocate one pool of memory and then manipulate into that. This meant that static analysis, runtime analysis, fuzzers were incapable of finding memory bugs. Because all pointers into that pool were "valid". LibreSSL stripped out OpenSSL's memory system and replaced it with malloc() and free() as provided by libc. Suddenly, static analysis, valgrind, and fuzzers found something like 3 dozen memory errors.
That is bad on so many levels.
OpenSSL supports big endian x86_64. OpenSSL supports EBDIC paths, certs, encodings, etc. OpenSSL supports DOS and Windows for Workgroups 3.11. It had a config -D NO_OLD_ASN1 and NO_ASN1_OLD. These defs performed different things. Having more eyeballs on a project didn't help OpenSSL, because all of those eyeballs glazed over immediately and/or had forks stabbed into them.
In something like the first month, the LibreSSL project deleted something like 90,000 LOC and 60,000 lines of comments/whitespace. Not changed: deleted. Removed useless cruft like mentioned above, and dangerous cruft like SSL 3.0 support. The latest OpenSSL tarball is 9.4MB, the latest LibreSSL tarball is 3.6MB. It has fewer eyeballs, sure, but it's an order of magnitude easier to audit.
https://valgrind.org/docs/manual/mc-manual.html#mc-manual.me...
I believe the state of the art in generic malloc implementations has improved since this sort of thing was commonplace, though.
That doesn't sound like an accurate description of LibreSSL, what with it being a part of OpenBSD.
...so even more people are looking at it? not sure what problem you think is happening here.
/usr/bin/openssl version
LibreSSL 2.8.3Example: "“Do you really want to build OpenSSL for 16-bit Windows? Well, we don’t.”"
https://opensslrampage.org/post/83952304402/do-you-really-wa...