This is a good article about SSL optimization for webservers. The key bits I gleaned:
* order the SSL algorithms from fastest to slowest (after you’ve weeded out the weakest ones, of course) so the server will pick the fastest that the client can handle
* concatenate any intermediate CA certs to your own .pem to save the client some extra round trips to that CA the first time the client visits your site
Originally shared by Abraham Williams
Nice writeup, but it looks like a first take. I hope he fills in the gaps, as the author definitely seems to know this stuff.
In addition to reordering/removing ciphers, you should ensure that it’s the server’s list that will be given preference (ModSSL SSLHonorCipherOrder/Nginx ssl_prefer_server_ciphers). Else, the client’s cipher will be chosen.
What he does not say is that large keys will kill performance. Sure, 1024 bit key-protected session could be saved, and decrypted when the key is broken at some point, but this is a risk a lot of organizations should consider vs. speed advantage.
RC4-SHA will not offer forward secrecy, but it will significantly decrease SSL session setup time. It’s a simple setup, as the SSL session cache just works.
ECDHE-RSA-RC4-SHA offers forward secrecy but, since the session tickets hold also the decryption keys, they have to be protected in turn by ephemeral keys, which have to be distributed to all of the SSL nodes. Else, just go with RC4-SHA.
Finally, enable Strict Transport Security. That cures a lot of headaches caused by SSLStrip-like MITM.
Oh, nice: Chinese government denies access to the SSL version of GitHub but, since the site implemented HSTS, the users are aware and can decide to proceed in clear, or find another way, if required.
Comments are closed.