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.

Figure 10: GnuTLS is already installed on many servers. The GnuTLS project was created because of license problems that the developers had with OpenSSL.

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.

The Author

Martin Gerhard Loschwitz is Principal Consultant at hastexo, where he is intensively involved with high-availability solutions. In his spare time, he maintains the Linux cluster stack for Debian GNU/Linux.