July 11, 2016 update: Simplify your life and just use Let’s Encrypt. It’s brain dead simple to use and automatically configures everything for you. The default security settings are essentially identical to Mozilla’s intermediate compatibility TLS settings (see options-ssl-apache.conf).
October 18, 2014 update: This information is outdated. Mozilla’s Security/Server Side TLS guide is much more comprehensive and should be used instead. It addresses BEAST, CRIME, BREACH, and POODLE and is consistently updated as new vulnerabilities are discovered.
I maintain a domain that requires SSL. It’s been using the standard 1024-bit keys that OpenSSL generates with standard Apache VirtualHost entries. After the various TLS exploits that have been revealed over the last few years, I spent some time looking into locking down my site.
First, I generate strong RSA keys. Very strong. 2048-bit keys are the current standard, but I opted for 4096-bit keys. No attack has been shown on 2048-bit keys, and 4096-bit keys have slightly more overhead, but I don’t mind; luckily, Linode (my host) just recently upgraded all CPUs. Security is all I care about, and a little CPU overhead is worth it.
First, I create the 4096-bit key/cert that Apache uses for self-signed certs:
sudo mkdir ssl
sudo openssl req -x509 -nodes -days 365 -newkey rsa:4096 -keyout [private_key_name].key -out [certificate_name].pem
sudo chmod 600 *
Then, I instruct Apache to use them. My VirtualHost file looks like this:
<VirtualHost [IPv4_address] [IPv6_address]:80>
Redirect permanent / https://[domain].com/
<VirtualHost [IPv4_address] [IPv6_address]:443>
CustomLog /srv/www/[domain].com/logs/access.log combined
SSLProtocol -ALL +TLSv1
That’s it. Restart Apache, and that’s all it takes. It’s the last few lines that really lock it down:
SSLProtocol -ALL +TLSv1
These lines specify the cipher suite (suite of encryption and authentication algorithms the browser and server are allowed to use) as well as the SSL protocols used.
SSLCipherSuite recommendation comes from http://blog.ivanristic.com/2011/10/mitigating-the-beast-attack-on-tls.html (Ivan Ristić was the original developer of
mod_security and is very active in the SSL world). These lines tell the browser which cipher suites, in order, it should prefer. As browser security improves (most browsers are still lagging behind in TLS 1.2 support, for example), this list/ordering will likely change to support stronger cipher suites.
SSLProtocol line is a common one for only allowing TLS v1 or higher. SSL v2 is flawed in several serious ways and should be disallowed. SSL v3 is considered less secure than TLS v1+. All modern browsers support TLS v1, so I’m not alienating any users here.
SSLCompression line is important for preventing the BREACH and CRIME attacks, which take advantage of SSL compression. This line only affects Apache 2.2+.
Finally, when all is said and done, you can visit Qualys SSL Labs to test the security of your site. If you’re using a self-signed certificate like mine, you’ll always get a failing grade. This is because the certificate isn’t trusted. This isn’t a big deal for my purposes; what’s important are the protocol support, key exchange, and cipher support ratings. Using the configuration above, I currently get at least 90 on these three of these ratings.
Ivan’s recent post, Configuring Apache, Nginx, and OpenSSL for Forward Secrecy, should also be noted here. Of special note is the section on RC4 vs BEAST:
Today, only TLS 1.2 with GCM suites offer fully robust security. All other suites suffer from one problem or another (e.g, RC4, Lucky 13, BEAST), but most are difficult to exploit in practice. Because GCM suites are not yet widely supported, most communication today is carried out using one of the slightly flawed cipher suites. It is not possible to do better if you’re running a public web site.
The one choice you can make today is whether to prioritize RC4 in most cases. If you do, you will be safe against the BEAST attack, but vulnerable to the RC4 attacks. On the other hand, if you remove RC4, you will be vulnerable against BEAST, but the risk is quite small. Given that both issues are relatively small, the choice isn’t clear.
However, the trend is clear. Over time, RC4 attacks are going to get better, and the number of users vulnerable to the BEAST attack is going to get smaller.
The reason I don’t use Ivan’s new suggestions is because these suggestions require Apache 2.4+. I’m using Ubuntu 12.04 LTS, which ships with Apache 2.2. When 14.04 LTS comes out, then I’ll likely transition to his crypto scheme.