Hopefully LibreSSL is safe - but you cannot be sure due to a lack of information:
It will be interesting to see as time goes on, how many issues in openssl end up being already fixed and/or non-issues in libressl and/or boringssl. Maybe a few incidents where that is the case will finally get people to moving to something better.
I’ve always wondered what the OpenSSL folks thought of being forked. Question answered.
Looks like there has been some progress: link to my other comment on
email to firstname.lastname@example.org
Why does anyone trust these people anymore?
Infrastructure Lock. Downtime for upgrades are dangerous, doubly so if you are switching underlying things like SSL. Also in a lot of entities eyes, there is nothing to replace OpenSSL currently. LibreSSL is there, but said entities aren’t going to jump that ship until it has been “vetted”.
I’d imagine for many of those entities the lack of FIPS 140 support will be a dealbreaker for LibreSSL. This isn’t a bad thing, by the way: look at all the BS OpenBSD would have to do to support FIPS 140 which is nothing more than security theatre anyhow.
I agree, of course, on all of that. The further implication is that there will, soon, be a much more obvious choice between compliance and security. Of course there has always been one, but soon it will be far more difficult for anyone to block out that knowledge. When that comes to a head, it should be interesting…
People in the know (Mark Cox, RedHat security team) seem to think it won’t be as bad as some previous issues and the high severity vulnerability only affects the 1.0.2 branch only.
So what will it take to get a OpenSSL with a C API written in a safe language? Is Rust our best hope as things stand right now?
Wasn’t it already demonstrated that a “safe” language wouldn’t have prevented Heartbleed?
Depends on your definition of “safe”. Considering it is accessing a buffer outside a correct bounds, and this information can be encoded into an expressive type system, then I’m not sure how it wouldn’t have prevented it. That is not to say that a safe language prevents all bugs, of course.
According to wikipedia:
The affected versions of OpenSSL allocate a memory buffer for the message to be returned based on the length field in the requesting message, without regard to the actual size of that message’s payload. Because of this failure to do proper bounds checking, the message returned consists of the payload, possibly followed by whatever else happened to be in the allocated memory buffer.
But even if it wouldn’t fix Heartbleed, Heartbleed is hardly the first or last hole to hit OpenSSL as a result of using C or C++. It’s no secret that these languages are inherently unsafe and difficult to audit.
Perusing the OpenSSL vulnerabilities list, I would classify the following as the result of using an unsafe language:
My hand is getting tired though…
This is the discussion I was thinking of:
The post by Tony Arcieri claims it’s not Heartbleed, but a security hole in its own right. But this demonstrates that the semantics of Rust are not “safe” enough. Not that a “safe” language would not prevent Heartbleed (or @tedu’s bug).
And the issue @tedu is pointing out should be clear: it’s not using construction to create safety. It’s an optimisation, using a mutable buffer. Mutability being a known cause of many bugs in a sufficiently complicated program. If the code was structured in such a way that construction guaranteed correctness then this particular bug would not be present.
I think people really undervalue the benefits of using construction as a tool for safety.
One thing that I would love to know is: it’s clear that using a safer language prevents various forms of errors, buffer overflows, some kinds of memory leaks, using freed memory, etc. But does using a safer language reduce the total bug count or do we introduce a new class of bugs to replace the ones we saved? My guess is that the total bug count is reduced. For one, we remove all those unsafe bugs. But two, while we introduce a new set of bugs, I believe the way we have to construct code in a safe language is probably going to remove bugs that are not directly related to the safe language bugs. For example, if I have to use construction-for-safety everywhere, it’s quite possible I will remove a whole bunch of other bugs that are not directly related to memory safety. tedu’s bug being an example. I have no evidence for this, I am aware of that, nor am I saying that a safe language makes programs bug free. My experience has been using a more restrictive language results in fewer total bugs, however, both logic bugs and memory bugs.