How to botch TLS forward secrecy | Hacker News Reader

How to botch TLS forward secrecy

imperialviolet.org

111 pointsphenylene18 comments

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.

[1] https://www.ssllabs.com/ssltest/

[2] https://www.ssllabs.com/projects/best-practices/

[3] https://github.com/ssllabs/research/wiki

[4] https://www.feistyduck.com/books/bulletproof-ssl-tls-and-pki...

Thank you very much for your great work, I've found both the SSL Labs test and the best practice guide quite useful!

https://github.com/ioerror/duraconf might answer some questions...

This is problematic in itself, because the "best" configuration changes from time to time.

That said -- perfect, good, enemies etc.

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?

edit: It was another agl article, https://www.imperialviolet.org/2010/06/25/overclocking-ssl.h...:

  Since the session information contains key material, 
  it's never cached on disk so the attempted client 
  resume rate, seen by Google, is only 50%.

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.

[1] https://tools.ietf.org/html/rfc2409#page-22

[2] http://www.iacr.org/archive/pkc2006/39580175/39580175.pdf

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?

[1] http://security.stackexchange.com/q/38084/4564

If you want to just test yourself, you get quite a lot of info from openssl's s_servers's status-page, enabled with -www:

    openssl req -x509 -nodes -days 30 -newkey rsa:2048 -keyout localhost.key -out localhost.crt
    openssl s_server -www -debug -accept 4433 -key localhost.key -cert localhost.crt

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

Perhaps someone ought to add session ticket support to OpenSSL for using some of the latest fast in memory-only databases.

If I were a company which made such a database, I'd think that kind of project would give me very good exposure.

I think there are two takeaways from this

1. A timely reminder nothing is perfectly secure

2. Don't use session tickets. Store nothing on the client except a random key. You will cock it up.

OpenSSL itself does not deal with tickets, afaik. The application code does.

How to configure Apache to use stronger than 1024 bit DHE? Like group 14.

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:

https://issues.apache.org/bugzilla/show_bug.cgi?id=49559

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.

Elliptical curve is faster too.

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?

[1] http://en.wikipedia.org/wiki/Perfect_forward_secrecy

Well Google is also a company that stores full history of everything and hands over stuff to the NSA, so in the bigger picture the point is moot?

Reply on news.ycombinator.com