OpenSSL has not had the greatest year. Fortunately, there haven’t been many Heartbleed-scale incidents, but we have seen an almost constant stream of vulnerabilities and problems, the most recent impacting the certificate validation process. OpenSSL is a hugely important piece of the web’s security infrastructure, and its developers have a very difficult job.
Because OpenSSL is a reference implementation, it tends to include a variety of features — like the heartbeat function that caused Heartbleed — that aren’t relevant to the majority who use TLS for providing secure connections to websites and applications. Because of that, OpenSSL is a ferociously complex piece of software.
The more complex software is, the more difficult it becomes to reason about. It can be hard to predict how changes will impact existing code, which makes vulnerabilities more likely. Large complex codebases are also more difficult to inspect and audit, making it harder to find any problems in the code. Any one can look at the OpenSSL code, but I’d put money on there being very few people who actually understand the full codebase.
OpenSSL isn’t the only game in town. As you’re probably aware, no major browser manufacturer uses OpenSSL, largely because of its complexity and unwieldiness. For this reason, among others, there are several implementations available to system administrators who want to provide TLS-encrypted connections. It’s a complex landscape, but I’d like to give a brief review of the alternatives, how they came about, and how they differ from OpenSSL.
NSS is a set of libraries developed by Mozilla that, among other things, provide cryptographic tools that include a complete open-source implementation of TLS. As you might expect, NSS is used in Mozilla’s own products, including Firefox, as well as an array of other products from organizations like Google (Chrome), Red Hat, and AOL.
NSS also provides mod_nss which makes for relatively easy Apache integration.
LibreSSL came about in direct response to Heartbleed. After Heartbleed, the team behind OpenBSD audited the code of OpenSSL and decided that they would prefer to fork it rather than continue contributing to the original project.
As an indication of how complex OpenSSL is, the OpenBSD team were able to strip 90,000 lines of C from a project intended to function as a complete replacement for OpenSSL. LibeSSL is developed primarily for the OpenBSD platform before being packaged for other operating systems, including Linux and Microsoft Windows.
LibreSSL provides a compatible implementation of the openssl utility, libssl, and libtls.
BoringSSL is Google’s take on OpenSSL. Unlike the two projects we’ve mentioned already, it should be noted that BoringSSL makes no promises of API stability or compatibility with OpenSSL. The aim is to provide a much leaner implementation that provides only the functionality it requires without the legacy cruft that constitutes the bulk of OpenSSL.
Originally, Google used OpenSSL with a set of patches developed in-house, but managing dozens of patches across many different applications became burdensome and so Google forked OpenSSL and stripped out a significant proportion of the tool’s APIs.
S2N is the youngest of the TLS implementations we’ll look at. Announced this June by Amazon, S2N is — and you’ve heard this one before — a radically simplified TLS implementation when compared to OpenSSL.
Part of the challenge is that the TLS protocol, including all of its optional extensions, has become very complex. OpenSSL, the de facto reference implementation, contains more than 500,000 lines of code with at least 70,000 of those involved in processing TLS. Naturally with each line of code there is a risk of error, but this large size also presents challenges for code audits, security reviews, performance, and efficiency.
S2N is just an implementation of TLS without all the other crypto tools that come with OpenSSL — it does what libssl does in OpenSSL, making it more suitable for web encryption than its more unwieldy ancestor. Rather than half a million lines of code, S2N is just 6000 lines, making it much easier to maintain and audit.
The practice of forking OpenSSL is a contentious one. Many would rather see developer effort and financial resources focused on building one implementation, rather than spread over four or more projects. But, whatever you think about the multiplying TLS implementations, there’s no doubt that simpler, safer, and more modern implementations are no bad thing for online security.