danimo's comments

Nope.

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.

Second-to-best solutions with older Distributions (Ubuntu 12.04, Debian 7, RHEL 6).

I've essentially answered this in https://news.ycombinator.com/item?id=7620756.

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.

Thanks, added!

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.

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.

>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.

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.

Or http://media.ccc.de/browse/congress/2013/30C3_-_5499_-_en_-_... (incl download option in mp4 hq and lq and webm).

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.

For best experience, please do _not_ use mirrors directly. http://media.ccc.de (http://cdn.media.ccc.de to be precise) will redirect you to the fastest mirror near you (GeoIP and ASN-based).