Is OpenSSL secure... in its dominance?
There are few software libraries as important to the everyday proper function of the Internet as OpenSSL, and yet it is no longer respected. Now that a legitimate free and open source competitor seems to be in the offing, the possibility exists that developers will abandon OpenSSL like rats from a sinking ship.
OpenSSL is not just used for SSL by web sites. All sorts of software with cryptographic needs use it for basic functions. For instance, OpenSSH — written by the same OpenBSD group that is now forking OpenSSL into LibreSSL — uses the OpenSSL libcrypto APIs for basic cryptographic functions that are also used by OpenSSL's libssl, the more famous part.
With so much code using OpenSSL, what they are really dependent upon is not the OpenSSL library itself, but the API. This is why LibreSSL's implementers, while cutting out large parts of the OpenSSL implementation, plan to keep what remains of the APIs compatible. Just put the LibreSSL files where the OpenSSL files were and the program will compile and link properly with the new library.
What does OpenSSL have to save itself, other than inertia?
So, in theory, even a major Linux distribution or VPN could just plug in the new library and should work. The reason they might do this is that OpenSSL has long been known to be a mess, and Heartbleed has given cover to efforts to do something about it.
Look back through the history of open source software and it's not easy to find examples of a code form supplanting a significant program. I asked around among my colleagues and the best example I heard is LibreOffice, the productivity application suite which forked off of OpenOffice and which has passed it in popularity. In fact, many of you who think you are using OpenOffice are actually using LibreOffice.
LibreOffice doesn't provide much guidance for the example of Open/LibreSSL. The users of LibreOffice are users; the users of OpenSSL are programmers. The benefits and detriments of switching office suites may be immediately obvious to the user, while the benefits of switching crypto libraries will be, at least at first, completely theoretical.
Featured
And there are cases of software that need the features being stripped out for LibreSSL; software designated for US governmental functions that require FIPS 140-2 support, for example. But Theo de Raadt, the head OpenBSD guy, insists that few inside the US and nobody outside cares about FIPS.
But for the overwhelming majority of applications which don't need the missing functionality, and where the developers appreciate the improvement in quality and security in a simpler, better-written library, LibreSSL may be an easy decision.
If a major program which currently uses OpenSSL were to switch to LibreSSL, that might count as permission for others to follow suit. A major Linux distribution would qualify.
Some of the major developers at issue here, like Red Hat and IBM, are among the few who might actually care about FIPS and the other missing features. But there's no reason they can't include both libraries and a configuration option or linker switch to allow a choice.
A lot of testing needs to be done before any major project takes such a risk, but it makes sense that it would work. What does OpenSSL have to save itself, other than inertia?