So posts about what you can screw up are nice, but what would be nicer is posts about how to set up an ideal SSL configuration for various web servers. (Perhaps there's no "perfect" configuration possible, but "strongest given known limitations" would be fine too.)
With all the talk of PFS lately I've been trying to configure Apache to do it, but either I'm dumber than I thought or there's no straightforward how-to online at the moment.
Instead of telling us the various crazy pitfalls and edge cases, just give dummies like me the best possible formula so we can configure things securely and then get on with our lives. The first step towards defeating eavesdropping is making the best possible SSL configuration a copy and paste affair instead of an acronym guessing game.
Edit: If total security isn't really possible right now as this post suggests, maybe a "best" configuration plus mailing list for when it's updated for varios major platforms (ie LTS) would be a good stopgap.
I think one of the biggest pitfalls of SSL/TLS (and many other security technologies available now) is that they are so configurable and flexible. The approach assumes everyone has the knowledge and the time to invest to tune everything. In reality, few people do.
Going back to your request, it's impossible to do with server configuration alone. Many other aspects, including the design of the web application, play a significant role. The best we can do at this point is work on the body of knowledge, hoping others can find the time to invest.
The best I was able to do so far is build the SSL Labs test[1], write the SSL/TLS Deployment Best Practices guide[2], and start the SSL Research Wiki[3], where I intend to add other un-structured information over time (including example server configuration). I have also written a free OpenSSL Cookbook[4] (requires registration, and you can opt out of email afterwards).
Apologies if this post comes across as self-promoting, but this is what I spent a large amount of my time on. These are all genuinely useful and important resources.
The only purpose of session resumption is performance, right? I thought someone published a report recently that real-world servers don't get enough successfully resumed sessions for it to even be worthwhile, particularly in a world with crypto hardware, SPDY and HTTP keepalive.
Wouldn't it be easier to just disable TLS resume than to figure out how to do it right?
That report sounds interesting, got a link by any chance?
I would think that session resumption should greatly increase performance for clients returning to your site, because there's no need to do a complete handshake (which is - relatively speaking - resource-intensive and IIRC also requires more network round-trips).
> Ideally the DH group would match or exceed the RSA key size but 1024-bit DHE is arguably better than straight 2048-bit RSA
So let's argue!
It depends on how you presume the attacker is gonna get you. Suppose the attacker is well-funded enough to go after one RSA-1024 or DH-1024 instance. Unlike RSA, however, DHE tends to work modulo the same prime over and over. This has consequences for cryptanalysis: once the attacker has solved a single DH instance, they can solve the next one much faster [2]. In the case of 1024-bit DH, the subsequent instances can be solved in about 2^55 time (versus about 2^80 for the first log); this is not instant, but it's pretty quick for a well-funded and skilled attacker.
Where 1024-bit DHE does shine versus 2048-bit static RSA is against other, less Hollywood, types of key retrieval such as outright hacking.
The recent discussions of SSL/TLS on the server made me wonder about client configuration. I looked around for a SSL Labs like tool for browser and asked on security.SX[1] but I was unable to find anything comparable which was troubling.
Am I missing something to think that an SSL Labs like tool for the client is also important? Does anyone have any recommendations?
Then open https://localhost:4433 in your browser and temporarily ignore the cert-warning.
You'll get a list of ciphers supported by the server, and a list of ciphers common between the server and the client (which, with all ciphers enabled (default) on the server -- should be rather exhaustive).
You can't. It hard codes 1024 bit parameters, which is highly annoying. There's a patch to allow user-specified DH parameters but it hasn't been merged:
I would just go with elliptic curve Diffie Hellman (which unfortunately requires Apache 2.4) and then disable the non-EC Diffie Hellman ciphers if you're concerned about using 1024 bit DH.
FWIW, nginx is a lot more flexible in configuring the cryptography.
So if Google enables forward secrecy for Google searches, would that mean every single Google search would be encrypted with a new key, or only the "open session"? Would encrypting every search be possible with perfect forward secrecy [1]? And if so, can't we get that for TLS 1.3, too?
With all the talk of PFS lately I've been trying to configure Apache to do it, but either I'm dumber than I thought or there's no straightforward how-to online at the moment.
Instead of telling us the various crazy pitfalls and edge cases, just give dummies like me the best possible formula so we can configure things securely and then get on with our lives. The first step towards defeating eavesdropping is making the best possible SSL configuration a copy and paste affair instead of an acronym guessing game.
Edit: If total security isn't really possible right now as this post suggests, maybe a "best" configuration plus mailing list for when it's updated for varios major platforms (ie LTS) would be a good stopgap.