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.

Figure 1: The bleeding heart: Heartbleed hit the security and open source community so hard that the bug was even given its own logo.

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).

Figure 2: At FOSDEM 2014, BSD developer Poul-Henning Kamp had already described the problems of OpenSSL and the possible consequences under the title "NSA operation ORCHESTRA Annual Status Report." He turned out to be correct.

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.

Figure 3: In 1998, OpenSSL was still called SSLeay, as shown by an ancient HowTo.

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).

Figure 4: The FIPS logo can only be used by those who adhere to the crypto instructions and organizational requirements of 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.

Figure 5: Theo de Raadt (here with Jon "maddog" Hall) is one of the most outspoken BSD developers who continues to criticize OpenSSL.

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.

Figure 6: Dirty work – Bob Beck's presentation is evidence of the anger felt by many participants after the Heartbleed disaster.

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).

Figure 7: Kamp pointed to the problem with malloc() at FOSDEM 2014.

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.

Figure 8: The PolarSSL library is designed to be lean, fast, and secure, and it is very popular in the defense and military area.

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.

Figure 9: The Dutch Offspark B.V. is driving the development 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.