With the rise of the cloud, now everybody manages a server. I am curious about how many of the admins actually know what are they doing. If I have to speak for myself, I set up my first ssl by following a guide that seemed to written by reasonably well informed stranger. It was my first exposure to the topic so I could not tell what I am doing until I break things and start reading deeper materials so that I can debug the problems by understanding what's going on. Turns out that the stranger who wrote the tutorial I followed was not well informed at all.
Yes, that's the exact problem that made me write this. What's particularly amazing is the amount of magical cipher suite strings shared throughout the web, most of which do not take in account PFS, or still prioritize RC4. All of that was acceptable at some point in time. Other cipher lists just don't make any sense at all, e.g. first removing a cipher (-RC4), then killing it (!RC4), all in one string with no benefit at all.
Thanks for writing this post, I've bookmarked it for reading later as it has plenty of links and I can see I have a lot more reading to do.
If you edit or update your post, I hope you will Mozilla's excellent "Security/Server Side TLS" page at https://wiki.mozilla.org/Security/Server_Side_TLS. This helped me get up to speed quickly and provided clear examples.
As proof of how good the Mozilla docs are, I tested my personal website using the Qualys test you mention and received an A+ rating!
This beat the A- rating for your site (though I freely admit I'm a total noob in this area - I'm copy/pasting and don't understand much about SSL). I guess this reinforces your point that good documentation is critical, and I hope more people find it at the Mozilla site.
That's an excellent reference with good explanations. I'll add it to the list to get away from the strong Ivan bias :-). The reason why I had A- only is that my openssl (Debian) doesn't seem provide all the ciphers required.
Yet Another Test Script: https://github.com/jvehent/cipherscan
It uses openssl to find out the cipher priorities, PFS keys and a few others things from a target site.
I wrote it because, while I love SSLLabs and Ivan's work in general, I find it too slow to scan a setup I'm working on many times. And I like doing stuff in the terminal.
A lot of sys admins are there by default. I would consider myself one of these - I would love to be able off load this work onto someone else who knows more than me, but there just isn't anyone.
Essentially this comes down to pressuring distros and server vendors do their homework finally ship with good examples/defaults. E.g. Microsoft IIS (!) has OCSP stapling enabled by default since ages. Apache? Most people still run 2.2, which isn't capable of OCSP stapling at all. Nginx is in a similar position.
That said, the more sysadmins rely on <s>rotten</s>well-proven "Enterprise Linuxes" and "LTS" versions with old libraries and servers, the more security expertise is required from sysadmins to decide where to deviate from the distros default packages to meet current best practices.
On the other hand, security is a moving target and knowing your (Open)SSL setup is as important as e.g. knowing your RoR setup. It's an inconvenient truth, because it requires learning new stuff. I don't see any alternative though, that's why I compiled this material.
Finally, a remark on the "offloading" part: Security is the single thing where delegation becomes hard because it means delegating trust, as in: your private SSL/TLS keys. And that's quite some trust to delegate.
> knowing your (Open)SSL setup is as important as e.g. knowing your RoR setup
Very true, and yet it's so much harder to know your OpenSSL or other security-related setup.
You learn your Rails setup well enough to make your application work, and hopefully well enough to make it performant. If you miss either of those goals, it's obvious to you. You know something's broken, and you grind away until you fix it.
Not so with security. Your system can be "working" by all outward appearances yet be riddled with vulnerabilities. And you won't know it, so you won't see any reason to go and learn more. Nor would you know what you don't know, or where you need to learn more. That's the scary part.
