Creating cryptographic agility with alternatives to OpenSSL
Emergency Response
When dangerous security flaws are discovered, being able to switch to alternative software can be crucial.
If you haven't heard by now, a recent kerfuffle was caused by an information leak in OpenSSL that could result in private keys being disclosed to a remote attacker. The majority of vendors got OpenSSL [1] updates out within a few hours of the issue going public, and many sites rolled out the updates not too long afterward. However, cryptographically agile sites willing to invest some time and effort in advance could swap cryptographic protocols and software suites within minutes or even seconds.
What exactly is cryptographic agility? Simply put, the idea is that you have a plan B ready to go in case plan A fails. For example, most SSL/TLS software suites support more than one algorithm for hashing, encryption, and so on. If a flaw is found in one (e.g., RC4), you can switch to another (e.g., AES).
However, the software suites themselves have problems. OpenSSL, GnuTLS, PolarSSL, and the like all have their share of CVEs for various security flaws. So, for example, if you use the Apache HTTPD web server, you can use mod_openssl and have mod_gnutls ready to switch to in case a flaw is found in mod_ssl or OpenSSL itself.
Alternatives to OpenSSL
The good news is that several mature alternatives to OpenSSL are available. Some of these are commonly shipped, such as GnuTLS [2] and NSS [3], and some are not commonly shipped but are open source licensed, such as PolarSSL [4]. If you want to support multiple crypto libraries properly, you will need to abstract the support. For example, some libraries check hostnames and certificates by default, and some do not. (See also the "A Note on LibreSSL" box.)
A Note on LibreSSL
LibreSSL [5] is an OpenBSD-based project; in typical OpenBSD fashion, the developers have begun by stripping down the code (e.g., removing all the bits not needed for OpenBSD) and addressing known security flaws. At this time, it is not clear whether LibreSSL will support Linux any time soon, if ever. Even with a code cleanup, LibreSSL will still have the same design flaws and cryptographic flaws as OpenSSL, so I'm not sure it will gain much; however, I'd love to be wrong.
Apache HTTPD is a good example of how to abstract this properly, you can use mod_ssl, mod_gnutls, or mod_nss to name a few. The only configuration changes you should need to make are simply enabling the appropriate module in httpd.conf
and then swapping the configuration files (e.g., mod_nss uses the directive SSLCipherSuite
and mod_nss uses NSSCipherSuite
). You can even make this step conditional on which module is loaded and keep a single configuration file that supports both modules.
So, why don't more people and applications use the alternatives to OpenSSL? The economics of this question are simple. Writing software to use a single crypto library is a lot cheaper in terms of resources needed than supporting multiple crypto libraries. Most applications that provide or use SSL/TLS compile OpenSSL directly into the app, although some will support using other libraries. If, however, your emergency response plan involves recompiling software and then swapping it and hoping it works because you did not have time to test it, chances are it won't go very well.
The economics of running two copies are similarly expensive. Maintaining two copies of your software – one with OpenSSL and one with GnuTLS – and either running both actively or swapping over once in a while to ensure everything is working is obviously more work than simply running one type of SSL/TLS software. That, and the fact that almost no proxy software supports anything but OpenSSL, is why almost no one actually does it.
SSL and TLS proxies
There might, however, be cheaper ways to maintain crypto agility than replacing the entire application or maintaining two copies of it. As seen with Apache HTTPD, if the SSL/TLS support is abstracted out, it is much easier to replace. So, why not remove SSL/TLS entirely? Several SSL and TLS proxies are available and, by using one of these, you can move any complexity related to SSL and TLS to one relatively simple application (e.g., simple compared with a mail server).
The other advantage lies in simplification. If you have five applications that provide SSL/TLS, that can mean five different sets of code, but using a proxy lets you use a single SSL/TLS package to handle it. Obviously, placing all your eggs in one basket can be dangerous, but if you have a second basket of eggs ready to go, this approach can be safer in the long run. About the only downside to using SSL/TLS proxies is that, if you use client certificates for authentication, you'll have to get the proxy to pass information to the back end. With a web server, this could be done using a special X header, for example.
Stunnel and Stud
Stunnel is one of the oldest SSL/TLS proxies available, whereas Stud is a more recent startup, but the code hasn't been updated in two years. Both, however, have a major downside: They use OpenSSL and, as far as I'm aware, can't use GnuTLS without significant modifications to the code. I figured, however, that someone must have written some proxy software that uses GnuTLS.
I looked at more than a dozen SSL/TLS proxies and was unable to find a major or even minor one that supports anything but OpenSSL, so I guess that's another reason why so few people invest in crypto agility outside of OpenSSL. In the open source world, your choices are OpenSSL, and stuff that uses OpenSSL.
Buy this article as PDF
(incl. VAT)
Buy Linux Magazine
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs
Subscribe to our ADMIN Newsletters
Support Our Work
Linux Magazine content is made possible with support from readers like you. Please consider contributing when you’ve found an article to be beneficial.
News
-
AlmaLinux 10.0 Beta Released
The AlmaLinux OS Foundation has announced the availability of AlmaLinux 10.0 Beta ("Purple Lion") for all supported devices with significant changes.
-
Gnome 47.2 Now Available
Gnome 47.2 is now available for general use but don't expect much in the way of newness, as this is all about improvements and bug fixes.
-
Latest Cinnamon Desktop Releases with a Bold New Look
Just in time for the holidays, the developer of the Cinnamon desktop has shipped a new release to help spice up your eggnog with new features and a new look.
-
Armbian 24.11 Released with Expanded Hardware Support
If you've been waiting for Armbian to support OrangePi 5 Max and Radxa ROCK 5B+, the wait is over.
-
SUSE Renames Several Products for Better Name Recognition
SUSE has been a very powerful player in the European market, but it knows it must branch out to gain serious traction. Will a name change do the trick?
-
ESET Discovers New Linux Malware
WolfsBane is an all-in-one malware that has hit the Linux operating system and includes a dropper, a launcher, and a backdoor.
-
New Linux Kernel Patch Allows Forcing a CPU Mitigation
Even when CPU mitigations can consume precious CPU cycles, it might not be a bad idea to allow users to enable them, even if your machine isn't vulnerable.
-
Red Hat Enterprise Linux 9.5 Released
Notify your friends, loved ones, and colleagues that the latest version of RHEL is available with plenty of enhancements.
-
Linux Sees Massive Performance Increase from a Single Line of Code
With one line of code, Intel was able to increase the performance of the Linux kernel by 4,000 percent.
-
Fedora KDE Approved as an Official Spin
If you prefer the Plasma desktop environment and the Fedora distribution, you're in luck because there's now an official spin that is listed on the same level as the Fedora Workstation edition.