Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

this is our ssl optimisation list. it has some tradeoffs like using small keys (1024bit) which may not be appropriate in a lot of situations.

1. Don't use ephemeral diffie helman for key negotiation. This means if an attacker compromises your private key in the future he can decrypt all your past transactions he has recorded. But it does give a nice speed boost. Understand the security implications and if you are happy with the tradeoff do it. More information here: http://matt.io/technobabble/hivemind_devops_alert:_nginx_doe...

2. Use RC4_128 + SHA1. Force clients to use this use server cipher order. (google does this) http://journal.paul.querna.org/articles/2010/07/10/overclock...

3. Use 1024 bit keys. (google does this) 2048bit is much much more expensive.

4. Use ssl session caching and make sure you have some kind of sticky session support or have some way of sharing sessions between your web nodes. haproxy can do it by ip or by ssl session id.

5. When you are dealing with a lot of traffic understand whether you can handle keep alives or not. If you can't handle keep alives turn them off. Keep-alives will improve ssl performance by quite a big deal if clients are doing multiple requests but if you don't have the resources to handle them then they kill your servers.



Worth noting that the attack that compromises your private key is going to cause much bigger problems for most sites than decrypting TLS sessions.

If you're handling state secrets or privacy for dissidents, EDH makes sense. I would guess that very few YC companies (as a relevant sample) are well served by it.


The overhead of newer ephemeral elliptic curve diffie hellman is as low as 15% compared to rsa[1].

[1] http://vincent.bernat.im/en/blog/2011-ssl-perfect-forward-se...




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: