2. Do you have time for a rewrite? What makes you think anyone else would?
3. The (generally correct) mindset is don't implement your own crypto. This is particularly true of something like TLS, which is complicated and has subtle requirements that are easy to screw up. Unfortunately, this means that even people who have time are discouraged from doing an OpenSSL rewrite.
> The (generally correct) mindset is don't implement your own crypto
That sounds like bad advice. The huge impact of Heartbleed is precisely because of the monoculture in SSL/TLS implementations. Shit happens but this vulnerability is such a catastrophe because an estimated half a million of the top Internet websites have been vulnerable since 2012, including popular services that everybody is using and the vulnerability once discovered, is easy to use and far reaching, allowing one to steal sessions, passwords, the domain's private keys and anything important.
It really can't get any worse than this. At the very least we found out about it, better late than never and we can discuss the source-code, but it does make one wonder ... if SSL/TLS is such an important piece of infrastructure and if we need a monoculture (because apparently it's bad advice to reimplement crypto), why aren't we using a library that's the reference and that's peer reviewed by a standards committee, instead of relying on a library for which commits don't necessarily trigger sounds?
The reason we tell people not to implement their own crypto is that no matter how skilled someone is, no matter what language they program in, it is nearly certain that self-rolled crypto code will have security flaws. Cryptographic security hinges on key, subtle assumptions that are very easy to screw up. World famous cryptographers do not roll their own crypto (except for research code).
When people do implement cryptography they rely on having large numbers of other people review it. That is not a model that scales to having a large number (more than a couple dozen) of competing implementations.
What I don't understand is why there aren't companies around that have an interest in improving this software and pay ~1-5 people ~1 million to rewrite it in a year.
Back in the Linux bubble days (1997-early 2000s), lots of companies employed full time people to work on all kinds of stuff, not just profitable company project, but also needed infrastructure. Even front end projects, like Nautilus and Evolution were created by full paid teams.
I posted the 'public good' link elsewhere, and this goes to the very heart of the problem: why should I pay if someone else might, and then I get it for free?
There might be a bunch of companies willing to chip in a bit, but coordinating that is difficult. Something like kickstarter might be able to help, but that has its own problems: if you spend your time writing a commercial SSL thing, you can go out and sell it right now when it's ready. If some company has to wait around for the results.... it's not as nice for them.
Historically GnuTLS had even more security trouble than OpenSSL (like that bug where it was trusting a self signed root certificate even if not in the certificate store that went undetected for years).
And NSS is pretty light on the server code IIRC...
In my past as professional code auditor, I've seen OpenSSL shipped with products quite a bit, and in 99% of the cases it was openssl the command line tool that was used to access the functionality because yes, the API is that bad and confusing that people would rather pipe to an executable that use library calls...
Today there are alternatives. Once upon a time those alternatives were either not written, not stable, or not free. Now it is just a matter of convincing an enormous number of developers to carefully rewrite large parts of their systems to use a different library instead of new features (or ironically, security fixes).
It was among the first at the time. OpenSSL was probably the dopest shit on the interwebz of crypto (or came close to it) at the time. Furthermore, these days it's too widely used so, everyone is just "fuck it." OpenSSL is the PHP of the cryptography world.
Also, I've see a ton of code just invoke the OpenSSL tool instead of actually use OpenSSL library.
I tried to use the library and was down in spirit, much like the author of the blog post, but I was too disappointed to even care, and just gave in to calling the tool from my code.
An idea: create a fork, call it OpenSSL2 and clean it up, but maintain both codebases, and end support for OpenSSL1 in 2-5 years?
2. Do you have time for a rewrite? What makes you think anyone else would?
3. The (generally correct) mindset is don't implement your own crypto. This is particularly true of something like TLS, which is complicated and has subtle requirements that are easy to screw up. Unfortunately, this means that even people who have time are discouraged from doing an OpenSSL rewrite.