Note that rich does not claim anything else. However, there is a fundamental difference between "initiate TLS connection from byte 0" (as used in HTTPS, but also IMAPS or SMTPS) and STARTTLS, where the protocol is plain text until the client issues the STARTTLS command, make makes protocols that were designed to TLS-enable plain text only protocols such as IMAP and SMTP (without the 'S'), while keeping the port number.
That was the point of this note. And of course there are even more use cases for TLS.
Yes, please don't think I'm saying that I think protocols that start off as plain text then upgrade are a good design - I don't. All I mean there is that I've written the code required to fingerprint the implementation those use too, by performing the plain text negotiation before each probe.
Basically, this cannot be the sole task of Apache, as they rely on OpenSSL via mod_ssl. Some parts are apache specific (OCSP stapling), but others, just like cipher suites, purely depend on OpenSSL. But I agree that Distributors (as the "Vendors") need to come up with a suitable solution.
About the Cargo Cult thing: Fair enough. I'm not a native speaker myself, but thought that it may be a well-enough-known idiom.
Anyway, SSL is still what people know it under (plus, according to Wikipedia, TLS support was only added in Java 7, and there are still many Java 6 setups around which have to put up with SSL 3). So I'll stick with SSL/TLS for the time being.
It's basically a shibboleth for "Are you a fan of Richard Feynman". I doubt very many people have actually heard of it directly, but his "Cargo Cult Science" commencement address (http://neurotheory.columbia.edu/~ken/cargo_cult.html) is moderately famous.
>The author attacks blog posts that state the current best-practices
No, I'm attacking the fact that people blingly follow blog posts that have been, at some point, what their author believed were best practices.
> But then goes on to recommend several books that are even more out of date than the blog posts.</cite>
Which is fine, as long as they are read for what they are supposed to be: Either introductions or specializing on a specific topic. I wouldn't have chosen them otherwise.
> Second, instead of allowing sysadmins to find and follow simple, well-researched best-practices, the author instead wants each person to thoroughly research the annals of cryptography in order to then come to their 'own' conclusion
It is up to your own self-conception as a sysadmin as to how deep you want to dive. When interviewing (non-junior grade) sysadmins, I challenge them on security knowledge just as much as other skills. And I know I'm not alone with that. A certain degree of security awareness is not a "nice to have" typoe additional skill. It's vital for everyone that has machines connected to the internet. How far he/she can dive is solely limited by the economics and time constrains. Which is why sensible defaults are needed from vendors and distros (see my other response).
> Most sysadmins won't do this.
Which is a real problem, and again, there should be some effort remedying this, but currently there isn't. That's why I plea to sit down and at least learn about the basics. What "the basics" are obviously depends greatly on your educational background, but if AES, RC4 and PFS do not ring a bell, and you are a professional sysadmin who runs SSL-secured web servers, you are not worth your money.
> (this why you're always told not to roll your own cryptography)
Nobody said anything about rolling your own cryptography. But if you at least have read one of Ivan's books, you can at least make a /qualified decision/ on how credible a config proposed in a "random blog post" is, without having to come up with the complete solution by yourself.
> find the current best practices from a reputable source (like Qualys) and use those.
Which is ok -- if you run a small setup and you at least use SSLLabs to verify your setup. The more responsibility you have, and the more security is required, the more you should dive in and have a qualified opinion on how your SSL/TLS setup should look like.
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.
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.
They did not. For unknown reasons, the switch in the Conference hall got manipulated (unplugged). It carried both the Skype call and the stream to the outside world.
Just to clear this up: cdn.media.ccc.de is the new name for ftp.ccc.de. It was renamed because it does not actually serve FTP anymore, since HTTP can be load-balanced a lot better.
