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.
[...]
Buy this article as PDF
(incl. VAT)
Buy Linux Magazine
US / Canada
UK / Australia