If you're like me, the last time you gave your SSL configuration much thought was a few years ago when you regenerated some certs to use SHA1 instead of MD5. I'll even cop to having been a little behind the curve and waiting until January 2009 to get around to doing this. What else is there to check? You just dump the cert and key in the appropriate directory and add some lines to your http server config and restart right?

Events involving Apple in these last days gave me pause and I took some time to go over my configuration (and my browsers) and make some changes, hopefully for the better. It turns out that relying upon the default behavior of web servers isn't a good thing and if you are, you might want to proactively button things up a little bit tighter. If your user community is small and clueful, or you don't mind leaving folks who can't be bothered to upgrade their browsers for years on end out in the cold, there are ciphers like 3DES that can be turned off with impunity.

As good a place to start as any is to make sure that you, personally, are not That Guy. Sure you upgrade your browser whenever patches come out, but admit it, you're also one to change the settings to better suit you, and since the regression testing was not done with your personal settings it can't hurt to take a quick peek to see what an appropriately wired web server thinks when it's confronted with your browser.

Fortunately someone's already made that site. Actually there's more than one. To check and see if you are vulnerable to the aforementioned Apple bug, check out https://gotofail.com. For the more general case, though, and for a deeper look at your browser's behavior, go to https://www.howsmyssl.com

All sorts of cool data here including the TLS version. TLS is what we used to call SSL, the S in https://, but to be pedantic SSL is hopelessly old-school, and everyone runs TLS 1.0, 1.1, or 1.2 these days. You want to be running 1.1 or 1.2. Anything older is problematic. Anything called SSL is seriously problematic. You want ephemeral key support and cipher suites with numbers like 128 and 256 as well as acronyms like ECDHE and ECDH in them. Finding additional acronyms like RSA, RC4, and 3DES is not bad; it means that your browser will work OK with old servers run by people who are behind the times.

Surely there's an equivalent web site/tool for your server right? Something that you can point at your https server and it will tell you some stuff. Indeed there is. The folks at Qualys have done a nice little tester which is free. It takes a couple of minutes to run. It's at https://www.ssllabs.com/ssltest/

What does all this mean? Time to do some reading.

I'm a bit wary of things that claim to be "best practices" documents, in no small part because I'm periodically confronted in my professional life with someone who's read a "best practices" document of dubious provenance and now fancies him an expert and tries to override my carefully-thought-out engineering judgement on how to attack a problem. I do my best to not let those prejudices get in the way when looking over published documents with a critical eye, but the SSL/TLS deployment best practices document from Qualys (again!) seems pretty proper. It's also kept fairly up to date; the last update was September 2013.

https://www.ssllabs.com/downloads/SSL_TLS_Deployment_Best_Practices_1.3. pdf

Now that you've read that and are up to speed on how things ought to be (and probably aren't on your https servers; they weren't on mine) it's time to think a bit about Forward Security (FS).

Why do you want it? Well, briefly, if you're not using FS for your session key exchange and your SSL certificates get compromised, all of your intercepted communications can be decrypted, going back for the entire lifetime of the certificate. FS and Ephemeral Key Support are different ways of describing the same phenomenon - namely, session keys that are created anew for each session and then discarded. They can't be tied back to the X.509 certificate after the fact, nor can they be derived from the cert. In short, new private keys every time the socket opens. Yes, a little computationally heavier, but here in the future in 2014 a shortage of CPU cycles is not our biggest problem. A very reasonable trade-off.

Remember Ladar Levison from Lavabit (an anonymous email provider known for, inter alia, being the home of Edward Snowden's mailbox)? He was told to hand over his SSL certs or face being held in contempt of court. Think you're immune to break-ins and getting your certificates compromised by nogoodniks? Ask the folks at Target how well that worked out for them.

http://blogs.computerworld.com/encryption/22366/can-nsa-see-through-encrypted-web-pages-maybe-so

http://security.stackexchange.com/questions/3638/security-of-pki-certificates-certificate-authorities-forward-secrecy

OK, so now you're sold on paring down your ciphers and supporting FS. What's a quick and dirty recipe for doing this on, say, nginx? Glad you asked. Here are some trimmed down stanzas (from inside my vhost declaration for the 443 listener) that did well for me. Have a better idea or corrections? Send email!

{% raw %} ssl_protocols TLSv1.2 TLSv1.1 TLSv1; ssl_prefer_server_ciphers on; ssl_ciphers ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:RSA+AESGCM:RSA+AES:!aNULL:!MD5:!DSS:!AES128;

OK, some more random links to tools and such. Happy server securing!

https://www.ssllabs.com/ssltest/viewMyClient.html

https://www.ssllabs.com/projects/index.html

http://www.net-security.org/secworld.php?id=16421

EDIT: In response to a question posed in AIM, yes, I had a "wide stance". It's narrower now and I don't expect to get into any trouble for my indiscretions. Thanks for asking.