I think unfortunately by now it's high time that we get a complete replacement written in a safer language and one that doesn't carry so much old baggage. And no, LibreSSL is no such thing.
There is a lot of room for improvement in the current OpenSSL code base. Simple cleanups, for one. Code formatting. Removing duplicate code. Static analysis. Unit tests.
The OpenSSL maintainers seem to be doing something other than all that. The historical defence for this was that they had minimal funding (which is no longer true), and that the funding they did have was for adding new features.
That's just not an acceptable excuse. And it never was an acceptable excuse.
Cleaning up code should be part of normal software development. Re-factoring code, adding unit tests, etc. Adding static analysis builds (clang is free, and Coverity is free for open source projects).
It's 2016. Why are some people still using software practices from 1992?
They are cleaning up the code, which I noticed when porting PostgreSQL to OpenSSL 1.1 and things were broken all over the place. I just think the code base is very bad to start with and the cleanup just start very recently.
Unfortunately that website doesn't load for me. Times out trying to connect to port 443. And the travis build bot says that the tls lib fails to build since about a month.
Looks like we're on a different Interweb, works for me; and travis was a spurious reporting problem, compiles fine (and is now green just to make you happy) :)
The more the merrier, thanks to it systems programing in memory safe languages is picking up support, from Ada getting more visibility in High Integrity Systems, Microsoft talking about their Midori research results[0] or Apple stating their goal with Swift is " Swift is intended as a replacement for C-based languages"[1].
Eventually we get the safety we had in the 90's back and improved.
The trouble with this isn't the lack of available options (indeed one may argue there are too many). But rather having everyone agree on something with a common API. Also has anything else seen heavy prolonged production usage?
I've read other people make this point. There are a lot of TLS implementations out there but OpenSSL was so synonymous with SSL/TLS for so long that it became a fundamental building block. If an API could be established that lets the-thing-that-does-TLS become a minor detail that's easily configured we'd all be better off.
Removing the dependency on OpenSSL is going to be a challenging, messy job. OpenBSD has mostly transitioned over to their LibTLS API but even they had difficulty moving some projects over.
A simpler, focused protocol framework and reference implementation with only necessary, useful options... something like that needs actual security people, users in embedded, enterprise, client/server apps would need to agree on it without falling into the trap of being hijacked by special interests, vague edge-cases and feature-creep. The issue would be that it's yet another/different standard, and TLS has most of the de-facto "market-share." That aside, OpenSSL and TLS are terrible because they're so poorly-managed, poorly-tested, poorly-validated, arbitrarily-featured and unplanned.
If SSL/TLS is a kitchen-sink, OpenSSL is Home Depot.
What features from those safer languages you want, that cannot be applied to existing OpenSSL code base? Pretty much everything they have is possible to implement for C without massive rewrites.
And don't forget "use-after-free" avoidance. (Although technically "undefined behavior" covers a lot.)
Also, couldn't distros just provide a version of the library built with the AddressSanitizer[0] enabled as well? It would be slower, but should be much safer. Let the user choose? Not the ultimate solution, but for the short term.
If they really wanted to make memory-safe C happen, there are already SoftBound+CETS [1] and SAFECode [2] and other approaches. Rewriting all of the C libraries is just not a viable solution.
Yeah, apparently the Tor project considered those first but they weren't able to compile Firefox [1]. And they seem to be abandonware at this point. I didn't immediately find any indication of their performance costs.
I see. Interesting that the Tor project and others had the same idea though. I wonder how feasible it would be to derive an "AddressHardener" from the AddressSanitizer.
miTLS is a stack written in annotated F# and definitely a promising step in that direction https://github.com/mitls Unfortunately it doesn't offer a C-compatible ABI as far as I know, so not usable by native code applications.
I'm not sure at a glance how easy it will be to use F star programs in C applications via Ocaml. We'd be better off if there was a compiler from F star to annotated/safe C, Ada/SPARK, or Rust. All of these can integrate more easily into the legacy apps.
I am not volunteering because while being fluent in C, I am not very knowledgeable in the realm of crypto. I'd be stupid to do otherwise. I can still point out that there is a big need for such a project.
This is a piece of software that is so core to our computer ecosystem that I am sure plenty of companies would contribute financially and with developer time. Heck, if this couldn't get enough funding for at least 5 fulltime devs plus external audits then we're in a sad state of an ecosystem. IMHO this actually should receive public funding. It would be more useful than many other things that get public funds.
Sigh. Please improve your reading comprehension. I didn't "shit on the LibreSSL developers". Anyways, you sound not like someone one can have a sensible conversation with. So I wont be replying further.
Okay, let's have a sensible conversation about your completely idle suggestion to create a new library in some other language, that would have to maintain compatibility with the OpenSSL API otherwise no one will use it, or rewrite everything that currently uses OpenSSL.
To me your "LibreSSL is no such thing" came across as dismissing the efforts of LibreSSL, even though it's not vunerable to this latest one, because it doesn't use Erlang.
Just a quick note that LibreSSL is not impacted by either
of the issues mentioned in the latest OpenSSL security
advisory - both of the issues exist in code that was
added to OpenSSL in the last release, which is not
present in LibreSSL.
Also: thanks to Google for finding the bug, via honggfuzz.