There have been attempts of repairing openssl. Every time it's a big problem due to lack of adoption.
LibreSSL would solve a lot of the surface area problems OpenSSL has, but people cling to OpenSSL under the guise that "a lot has improved" and of course that change is hard.
The point I'm trying to make is that there _are_ better SSL libraries, but none have the adoption of openssl, and adoption has inertia; nobody is going to go out of their way to avoid OpenSSL because a bug in openssl is not their fault.
Just like AWS's availability, people work on the premise that if AWS is down (or OpenSSL has bug!) then everyone is affected and therefore they can't be blamed.
I've been making personal moves towards libressl and openbsd in general. there's just way less friction involved in maintaining those servers vs my linux ones running stuff like this that constantly leaves me hitting up my clients like 'yeah we need to do this at midnight'
If libressl is affected by this too I would be incredibly surprised. They really did do a great job of removing all the bad stuff for something that just works as a drop-in replacement compatible with scripts and everything.
Damn that sucks. Works for me on literally all my client's sites otherwise, I feel happy as a clam... If it doesn't work for you I'm really curious on what's missing though, could you point out specifics?
Serious question: who are the decision makers on "using OpenSSL" vs other stuff? It feels like most application level people will be using whatever gets packaged with whatever framework/HTTP server they use, so shouldn't there be relatively few people to convince here? Or is that a big misread of the situation
It's an integral part of operating systems often pre-installed on there these days, so I think you could probably point out distros who have tried and failed to replace this component that they have to ship. I think a few distros tried libressl and had to end up going back because of reasons I'm not entirely sure of, but I suspect enterprise interests has something to do with anything like this breaking compat and causing them to have to do more work
For most people that’s kinda like asking who’s the decision maker on what brand of bearings get used in your cars engine.
It’s just not even on most people’s radar, it’s just something that comes along with the web hosting/Linux disto/AMI/SaaS they buy.
Most people don’t even think about whether Ford or Toyota make the bearings in their engines (they don’t), a very very few people tear down their engines and replace bearings and most of them will just order new ones from the car’s manufacturer. A tiny percentage of people tearing down engines will actively make decisions about whether Ford/Toyotas bearings are right for their project, and maybe if they’re drag racers or rally car builders they’ll choose different bearings. There’s an even smaller number of people who build engines from scratch, who’ll decide for themselves the right bearings for them. There are maybe a few dozen people on the planet who work at major car manufacturers who specify 99.999+% of all the engine bearings used in current passenger cars.
FAANG are kinda like Formula1 teams here, they work very closely with their engine manufactures to ensure they have the best possible bearings/ssl implementations for their specific use cases. Radha/Cannonical/Microsoft/et al. are the car manufacturers, who choose bearings/ssl libraries most generally suitable for the expected use and lifespans of their products - without optimising fo any one specific use case.
(And most HN commenters, like me, are the armchair quarterbacks second guessing and speculating endlessly about why a particular racer's engine expired during yesterday's race on internet forums every Monday morning... :-) )
> who are the decision makers on "using OpenSSL" vs other stuff?
Since you said you were being serious then I hope you don't find the answer flippant; The decision makers are usually the people who originally wrote the software.
Once software is written it is unusual to alter dependencies unless there is a very solid reason.
For a great example, check how many projects moved from MySQL to PostgreSQL (or vice-versa) despite fundamental issues in MySQL regarding safety and (previously) performance issues in PostgreSQL.
> There have been attempts of repairing openssl. Every time it's a big problem due to lack of adoption.
If the repair is a drop-in replacement then the issue shouldn't be too bad. If new one does prove to be more stable in terms of needing security updates to be rolled out, then people will start to adopt it to save the time.
Of course the problem with that is the new version will need to be entirely feature complete from day one, and surprisingly bug free for something of that size or confidence will be too low, and track changes in OpenSSL for long enough until it becomes the de facto standard instead.
As someone who has used it on a project, once you start trying to do "advanced" things like optimize round trips in conjunction with your application layer on top of it, you have to start poking around some obscure parts of that API, where the only documentation is "read the source code". Even some basic stuff like validating that the certificate corresponds to the domain you connected to (like, pretty important!) was historically not done by default and required interfacing with a bunch of low-level stuff. The things you used to have to do to use the Windows system certificate store were also pretty hideous. I believe these things are handled better in more recent versions, but of course much software was written in the past, including mine, and if you wanted it to work (and continue to work, with older versions), you had to do the hideous things.
So a drop-in replacement is really a tall order, and would also require repeating many of OpenSSL's mistakes to achieve true compatibility. Ironically OpenSSL 1.2 itself broke a lot of these APIs in ways that affected my project (and were not, in my opinion, always strictly better).
LibreSSL hasn't improved anything. Deleting all the code that was #ifdef'd out for old platforms might make you feel good, but it doesn't actually help security because none of the code was compiled anyway.
This does a great disservice to the work done by the OpenBSD guys.
For one thing they removed the home-grown memory allocator, which prevented a lot of issues and allowed debugging tools to notice memory corruption issues.
They did more than that. See e.g. this slide: If you use normal coding patterns, then normal linting tools can notice the bugs. The openssl code was hiding the truth from these tools, for no reason.
They don't appear to be related to me. One is a UAF, the other is a NULL pointer dereference.
[1] The LibreSSL issue was found by HAProxy's continuous integration pipeline: https://github.com/haproxy/haproxy/issues/1115. Disclosure: I'm a community contributor of HAProxy, I help maintain the issue tracker and I took part in debugging the issue.
LibreSSL would solve a lot of the surface area problems OpenSSL has, but people cling to OpenSSL under the guise that "a lot has improved" and of course that change is hard.
The point I'm trying to make is that there _are_ better SSL libraries, but none have the adoption of openssl, and adoption has inertia; nobody is going to go out of their way to avoid OpenSSL because a bug in openssl is not their fault.
Just like AWS's availability, people work on the premise that if AWS is down (or OpenSSL has bug!) then everyone is affected and therefore they can't be blamed.