Emergency Response

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

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.