alex_aldo - Fotolia
Google is coming out with its own OpenSSL fork called BoringSSL, and OpenBSD has done the same with LibreSSL. How do these compare to other cryptography libraries available? Are they safe OpenSSL alternatives? Is there anything new enterprises should know about them?
Every Internet user relies on the quality and security of the cryptography software libraries used to protect their online data and communications. However, confidence in the most widely used cryptography library OpenSSL has been severely dented following the exposure of the Heartbleed flaw and revelations about the poor state of funding for the development team that maintain its code.
Within weeks of the flaw being made public, OpenBSD founder Theo de Raadt started LibreSSL, a fork of the OpenSSL project -- and a potential replacement. It is supported financially by the OpenBSD Foundation and OpenBSD Project. Google has also announced its own fork of OpenSSL dubbed BoringSSL. This means there are now three separate versions of OpenSSL, and security teams need to appreciate the differences between them in order to choose the best library for their specific needs.
Until recently Google used OpenSSL in its products, including Android and Chrome, but added more than 70 of its own patches applied on top of the OpenSSL code. While some of its patches have been accepted into the main OpenSSL repository, many are unsuitable because of OpenSSL's commitment to application programming interface (API) and application binary interface (ABI) stability. Google's patchwork version started to become unwieldy and difficult to maintain, so by forking OpenSSL, Google can now import changes from OpenSSL into BoringSSL instead of having to rebase and reapply them on top of its patched version.
BoringSSL is a much lighter-weight version of OpenSSL with no guarantees of API or ABI stability since Google requires far less legacy application support. BoringSSL will be ideal for those developing for the Chrome and Android platforms, but note that it's not a straight replacement for OpenSSL. LibreSSL, on the other hand, specifically has the goal of maintaining API and ABI compatibility so can be treated as a drop-in replacement for OpenSSL. The aim is to develop a cleaner version of OpenSSL and maintain compatibility with tools such as Coverity and Valgrind that are used for memory debugging and leak detection and help locate bugs in reams of code. Plenty of defunct code has already been removed and other areas rewritten using modern C programming practices such as safer memory allocation and integer overflow avoidance.
Enterprises should wait until stable versions of these OpenSSL alternatives have been released before experimenting or swapping between them. The Internet will certainly benefit from having three sets of development teams working such critical cryptography software, as bugs may well come to light that wouldn't be detected by a single party; as all three projects are open source there is the ability to share bugs and patches. Google is also continuing to provide funding for the OpenBSD Foundation and the Core Infrastructure Initiative, which is providing $100,000 in funding for two full-time OpenSSL developers.
Ask the Expert!
Have a question about application security? Send it via email today! (All questions are anonymous.)
Don't miss Michael Cobb's advice on the reality of open source software security after Heartbleed.