Defying the Danger

In most corporations, security updates take place without much of a stir. In fact, the lion's share of vulnerabilities remain unnoticed to the public; they fly past admins in the form of security advisories. If a vulnerability makes it into the mainstream media, however, admins can be sure it will be a really big thing. The OpenSSL bug Heartbleed [1] (Figure 1) made it into many major websites, and even into living rooms with news broadcasters reporting on it in prime time.

Heartbleed cannot be assessed negatively enough. Because it is based on a simple function that most clients don't actually use but is enabled as part of the OpenSSL [2], default configuration, keys, certificates, and basically everything that happens in main memory, was freely readable – both in the client-server direction and vice versa. Heartbleed really hurt.

Additionally, the Heartbleed phenomenon seemed to undercut a central mantra of the FOSS movement. The FOSS community likes to claim that open source software is more secure because a large community of developers see the bugs more quickly. However, the code that made Heartbleed possible in OpenSSL found its way into the library in January 2012. How did it remain unnoticed for so long? Actually, warning voices were heard for some time, particularly at the FOSDEM 2014 conference [3] (Figure 2).

Admins and developers are left perplexed by Heartbleed. Is OpenSSL actually still the tool of choice? What alternatives are available, and how do they cope with the complexity of the code and the internal reviews?

This article looks at four leading crypto libraries. You'll learn about OpenSSL, LibreSSL, PolarSSL, and GnuTLS.

OpenSSL: The Oldie

OpenSSL is practically everywhere: Every Android phone has the library installed, every Linux desktop and router. The mod_ssl module for Apache is probably the undisputed standard for teaching web servers SSL; after all, every Linux server seems to be equipped with at least one program that is linked against OpenSSL. SSL implementations of important tools such as Postfix also rely primarily on OpenSSL.

OpenSSL development began in the mid 90s; the trigger for this development was the infamous U.S. export regulation for cryptographic software. At that time, it was forbidden to export good and secure encryption software from the United States to other countries.

Although this seems strange from today's perspective (because the Internet is well-known for not having boundaries), it meant a constant balancing act with an uncertain outcome for developers. The need for an international solution prompted Australian Eric A. Young to start work on SSLeay (Figure 3). Because there was no cryptography-restricting legislation in Australia, the tool suite was available worldwide.

For some time, SSLeay was virtually a one-man show. In the summer of 1998, a team of developers took over maintenance, and the software, which was now called OpenSSL, underwent a breath-taking ascent in the next few years. The Apache plugin mod_ssl was a factor in building the visibility of OpenSSL.

The OpenSSL project was striving for FIPS certification in 2006. FIPS is a provision by and for U.S. authorities designed to ensure the quality of cryptographic software. If a program is able to obtain FIPS certification. The FIPS standard [4] (Figure 4) comes from the National Institute of Standards and Technology (NIST).

The organizational structure of OpenSSL is akin to other FLOSS projects – a "do-ocracy": Those who wish to participate in the work are invited to do so. The OpenSSL Foundation is the official home of OpenSSL development. In the aftermath of the Heartbleed disaster, it was precisely this foundation that pointed out that only one full-time developer is actually working on pushing forward with OpenSSL. In response to Heartbleed, the Linux Foundation announced at the end of April that it would financially support OpenSSL to provide more manpower.

In the eyes of many observers, the disturbing thing is not the fact that a former college student contributed the fatal code as a patch; what is much worse is that a representative of the OpenSSL Foundation simply waved through the code and integrated it into OpenSSL. Shortly before this issue went to press, a message arrived stating that, in a new release, OpenSSL had plugged seven critical vulnerabilities, one of which was traced to the developer associated with the Heartbleed fiasco.

LibreSSL: Manic Rebel

Soon after the first reports of Heartbleed, LibreSSL [5] did the rounds for the first time as a concept. Basically, LibreSSL is a kind of protest gesture by OpenBSD developers directed at the OpenSSL Foundation.

Many OpenBSD developers, led by Theo de Raadt (Figure 5) are chronically undiplomatic in their social interchanges;. OpenBSD enjoys the reputation of being a very secure operating system, and the developers have often boasted that they have not had any security holes in their default installation for years that would allow remote attackers to gain root access.

De Raadt and his team reacted indignantly when they were unsolicitedly imposed upon with critical vulnerabilities caused by others, especially if the problem could have been avoided. (Actually, in the eyes of the OpenBSD developers, every vulnerability is avoidable.)

So, by starting LibreSSL, de Raadt and his team took their SSL fate into their own hands, and they thus donated a better SSL to the world, primarily through consistent cleaning up and clearing out.

What was especially painful about Heartbleed was also the fact that the bug was in a function that hardly anyone uses and was thus completely unnecessary. Bob Beck, a core member of the OpenBSD team, makes clear in a presentation [6] (Figure 6) the amount of unnecessary code that OpenSSL has gathered.

He explains in his slides that 90,000 lines of code have been deleted, without replacement, in the first 30 days as part of the LibreSSL fork. The jettisoned code includes support for various ancient architectures (e.g., Mac OS 9), as well as features that only cover very specific use cases. Slimming the code base should make LibreSSL much more maintainable; the fewer opportunities there are to install security bugs, the fewer the vulnerabilities.

Beck almost blatantly ridicules the FIPS code valued so much by the OpenSSL Foundation, labeling the Foundation as a "FIPS company" whose sole right to exist is through FIPS consulting and not based on its contribution to the development of OpenSSL. The OpenBSD developers, on the other hand, have already removed almost all functions that are unessential for daily life but essential for FIPS.

LibreSSL developers heavily criticize the OpenSSL components that are necessary for daily operation and will therefore remain in LibreSSL. The code is "unmaintainable," they say, simply because OpenSSL developers re-implemented elementary functions such as malloc() instead of using standard types.

What sounds like banter has real consequences: Tools such as Valgrind help developers find security vulnerabilities in the source code, but only if the code uses standard functions. OpenSSL slipped through all the standard tests because it does not use the functions checked by Valgrind and similar tools. As indicated by Poul-Henning Kamp's Orchestra keynote from the FOSDEM 2014, all this was known for some time (Figure 7).

The LibreSSL developers – backed by the OpenStack Foundation – will thus be putting great effort into standardizing the OpenSSL code. In the end, the result should be a "healed" OpenSSL library in the form of LibreSSL, which is far more secure.

To make the migration to LibreSSL easy, the library should always remain compatible with OpenSSL, at least in terms of standard functions. Bob Beck speaks of a "drop-in replacement." Developers will, however, still have a need to adapt their programs; for example, the names of the headers in LibreSSL and OpenSSL differ.

Even if the changes discussed in this article are the only improvements, LibreSSL should make a name for itself as an alternative to OpenSSL.

PolarSSL: The Quiet Little Mouse

In the face of the Heartbleed disaster, the PolarSSL developers must have felt like that were on another planet. Additionally, the team led by Paul Bakker probably only has a tired smile to spare for the LibreSSL people  – because the reason for founding PolarSSL [7] was that OpenSSL was far too big and unclear.

Christophe Devine, who wrote the first version of PolarSSL as an extension of the XySSL library, published this first version (Figure 8) in 2006  – precisely at the time when OpenSSL was boasting about its FIPS library.

XySSL was specifically designed as the exact opposite of OpenSSL: The huge mountains of OpenSSL code are a complete contrast to a lean XySSL library that was easy to maintain and came with very low resource overheads. In 2008, Devine gave up the development of XySSL, and a team led by Paul Bakker took over PolarSSL as a fork of XySSL. The project still exists today.

PolarSSL takes basic functionality seriously. Primarily, the code contains features that are required for handling TLS connections; later versions might have additional features, but today the project still focuses on lean code. It is therefore pleasantly easy for authors of programs to integrate PolarSSL in their own applications; detailed documentation [8] provides an overview of the functionality you can expect.

PolarSSL is quite interesting in terms of license rights. The program is available under the GPLv2; alternatively, licensing through a commercial license is possible at an extra cost. The commercial license allows generous use of the software without having to submit to the restrictions of the GPL, and the package provides additional support goodies.

Offspark B.V., headquartered in the Netherlands (Figure 9), provides the service for a charge of just over 120 Euros per product type per month, that is, just under 1500 Euros per year – if the customer opts for a typical subscription model. A one-time purchase costs about 3000 Euros. The code is all the same, independently of the license, and part of the income royalties are fed back into the development and maintenance of PolarSSL.

What is important for developers is that PolarSSL does not seek to be a drop-in replacement for OpenSSL. Existing applications that work with OpenSSL cannot be linked to PolarSSL in an equivalent way. Anyone who wants to expand a program to support PolarSSL needs to modify it accordingly.

GnuTLS: A Matter of the License

The fact that GnuTLS [9] (Figure  10) does not have the characteristic "SSL" in its name should not cause confusion. TLS is actually just the name for the SSL standard 3.1 and later versions – a detail that might be unknown to many users.

Licensing issues were the incentive for developing GnuTLS: OpenSSL is provided under two licenses, which apply at the same time. Both are basically "BSD-style" licenses that have been equipped with an advertisement clause by the author. In concrete terms, programs that want to use OpenSSL must contain a notice relating to the use of OpenSSL; for example, a separate paragraph in the license. Although this sounds totally unspectacular, it is causing FOSS proponents to break a sweat. In their minds, the advertisement clause is a limitation that affects the distribution of the program.

Anyone who uses OpenSSL is not allowed to release their program if they do add OpenSSL advertising. The GPL, however, explicitly prohibits such restrictions. Anyone who writes GPL code and relies on OpenSSL must check with all the copyright holders of the code to see if the licenses can contain an "SSL exception." Even that is an imposition in the eyes of the GNU developers; they therefore created a GPL-licensed alternative to the OpenSSL library available in the form of GnuTLS. Unfortunately, GnuTLS is at least as bloated as OpenSSL. GnuTLS has almost all the functions that OpenSSL has; the source text is not much more compact either. GnuTLS might not have FIPS certification, but some of the features necessary for it are definitely included.

As with OpenSSL, the developers of GnuTLS are facing a juggernaut. The fact that they have the GNU Project behind them and are not a "one-man project" provides little comfort. Some critics mention that bugs are found just as frequently in GnuTLS as in OpenSSL.

GnuTLS is certainly not a drop-in replacement for OpenSSL, even if most GNU programs prefer it. GnuTLS is probably actually just slightly less popular than OpenSSL; but servers without GnuTLS are likely to be few and far between.

Developers and admins at GnuTLS are, in any case, barking up the wrong tree if they are trying to provide a sleek alternative to OpenSSL. Anyone who needs the OpenSSL full feature scope, however, actually has a good chance of finding it with GnuTLS.

Lean or Feature-Rich

LibreSSL and PolarSSL differ from OpenSSL and GnuTLS, principally by the fact that they are smaller. Anyone looking for basic SSL encryption is in the right place with PolarSSL. Even the LibreSSL approach is attractive – in contrast to PolarSSL, LibreSSL still needs to prove that the project will not run out of breath.

Theo de Raadt and the OpenBSD Foundation have demonstrated their desire to maintain a lasting alternative to OpenSSL. Because LibreSSL works as a drop-in replacement for OpenSSL, the LibreSSL option would certainly be the most attractive alternative for both admins and developers. As of now, however, the number of programs that LibreSSL already supports is quite small.

OpenSSL and GnuTLS are fully-fledged crypto suites. Whether OpenSSL will manage to regain its reputation as a trusted and secure tool is written in the stars. Undoubtedly, the first important steps, such as fundraising and comprehensive audits, have already taken place. Anyone who is an admin or developer will do well to observe the developments in OpenSSL and LibreSSL – some innovations are probably just around the corner.