Can open source cryptography libraries be trusted?

After the whole Heartbleed fiasco, the question has to be asked: Can OpenSSL ever be considered secure again? Should we be more wary of applications that use it? Would it be advisable -- where possible -- to move to something like LibreSSL?

OpenSSL is widely used by millions of servers and organizations both large and small around the world, and it is one of the two main established cryptography libraries (Windows Crypto library being the other).

However, the Heartbleed flaw has shaken confidence in this open source software. More than half a million SSL certificates have been potentially compromised as a result of the Heartbleed vulnerability. The exploitation of this bug does not leave any trace of anything abnormal occurring in server logs, making vulnerable versions of OpenSSL an attractive target for hackers. Enterprises with affected certificates should check with their certificate authority about how compromised keys can be revoked and new certificates reissued. Those who issue self-signed certificates should revoke and reissue them as soon as they have upgraded their OpenSSL software.

Over the long term, enterprises need to assess whether using an alternative cryptography library is the best way forward or not. Very few organizations are likely to have the in-house skills necessary to develop their own cryptography libraries, but using any third-party library -- open source or proprietary -- means relying on others to correctly implement and deliver security. Many times, open source cryptography software relies heavily on part-time volunteers who have full-time day jobs -- people the HR department is never going to meet or vet. Despite this, the open source model has proven to be the best approach for developing robust cryptographic code. For example, the OpenSSL Foundation reacted to news of the flaw by promptly providing a fix, whereas software vendors often drag their feet.

But, as everyone now knows, open source projects need to be properly funded and have a large active development community, otherwise coding errors and vulnerabilities remain unnoticed -- the same as in any poorly resourced or developed commercial software. OpenSSL has suffered from a lack of funding and code contributions; this is the reason that OpenBSD Founder Theo de Raadt has started a fork of OpenSSL as a potential replacement. LibreSSL is supported financially by the OpenBSD Foundation and the OpenBSD Project, and it is part of the very active OpenBSD developer community, which has a clear policy about how contributions are evaluated and included, as well as a reliable regime in place to handle errors or problems. LibreSSL is initially being developed for the OpenBSD operating system -- its first inclusion will be in OpenBSD 5.6 -- but will support multiple operating systems once the code and a stable commitment of further funding are in place.

Although LibreSSL may become the de facto library used to implement SSL/TLS services, enterprises must understand that they can't rely on someone else's assurances that software securing key data is safe. Security teams need to conduct their own due diligence and test to ensure the code or component is secure against the most common and pertinent threats their infrastructure faces. Bugs in software are a fact of life, so enterprises that make use of open source libraries should strongly consider contributing to the projects that maintain them, as there is a direct correlation between the speeds with which new or existing vulnerabilities are discovered or prevented, and the quality of technical resources devoted to the project. Also, taking time to do this would be a lot cheaper than funding an in-house team of cryptographers or recovering from vulnerabilities such as Heartbleed.

Ask the Expert!
Want to ask Michael Cobb a question about application security? Submit your questions now via email! (All questions are anonymous.)