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.
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?
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.
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.
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.
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...
http://directory.fedoraproject.org/wiki/Mod_nss#What_feature...
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?