Tips to accelerate SSL

Removing export ciphersuites is fine, but it's not the case that TLS randomly picks a ciphersuite from the list and therefore removing some slow ones will speed things up.

Servers either use the client's most preferable ciphersuite or their own. Most servers use their own preference (SSLHonorCipherOrder in mod_ssl).

So removing 3DES doesn't do anything because none of the connections will be using it anyway as everyone prefers RC4 or AES. The only cases where it would be used is if the client supports almost nothing else. In that case, you're just breaking the client.

Far more important is that the text is recommending DHE-RSA-AES256-SHA as the most preferable ciphersuite. The benefit of AES-256 over AES-128 are almost nil in this case, because AES is not your weakest link. And the cost of DHE is substantial.

Disabling DHE removes forward security, but results in substantially faster handshake times. Ideally the text would discuss this tradeoff and how ECDHE gets you the best of both worlds to some extent.

Given that most sites are going to nullify forward secrecy with non-ephemeral SessionTicket keys in any case, RSA-AES128-SHA or RSA-RC4-SHA are reasonable choices for the casual site. Certainly better than just using HTTP.

The points about Keep-Alive is fine and caching are fine, but not specific to HTTPS.

Minimising domains and serving complete chains is correct, but just telling people not to miss intermediates is unhelpful: put your site into ssllabs.com and it'll tell you if you need to fix your certificate chain.

My recommendations would be:

1) Prioritize ECDHE-RSA-RC4-SHA. This gives you forward secrecy, is reasonably fast, and avoids the security problems with how block ciphers are integrated into TLS (see http://www.imperialviolet.org/2011/11/22/forwardsecret.html).

2) Enable HSTS headers. Not only does this protect you from SSL stripping attacks, it will often speed things up by eliminating a roundtrip (user types yoursite.com into their browser, makes an HTTP request, gets a 301 for https://yoursite.com, does a TLS handshake).

3) This article mentions Keep-Alive, but TLS Session Tickets are going to be more effective in reducing handshake overhead. Enable them, and setup a job to rotate your session ticket keys once a day.

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.

The article didn't mention TLS-session caching. Sometimes keep-alive alone is not enough. Enabling session caching helped us to reduce nginx server CPU load by about 90%.

Add this in nginx.conf "http" configuration:

  ssl_session_cache shared:SSL:10m;
  ssl_session_timeout  10m;

This makes nginx store TLS-sessions in a cache for 10 minutes and tell the clients about it. Although some clients can still use a shorter duration.

"If the browser doesn’t know the intermediate CA, it must look for it and download it."

Is that accurate? Where is this behavior specified? RFC 2246 states "If the server is authenticated, its certificate message must provide a valid certificate chain leading to an acceptable certificate authority." No mention of a client doing behind-the-scenes magic to fill in the missing intermediate certs.

It's been my understanding that cert validation will simply fail if there are missing intermediate certs, and my experience is that this is the case. However, if there's something I'm missing that would allow a browser to synthesize the cert chain, I'd be interested in reading about it.

The first tip for setting the cipher suite in Apache httpd is incomplete without:

    SSLHonorCipherOrder On

Without it, the client's preference is used, which may be a slower cipher in your list. You'll want to revise your SSLCipherSuite directive and there's nothing wrong with specifying individual ciphers instead of aliases when using such a short list.

You'll also want to monitor the effects of the change. Before you do anything, make sure you're logging SSL information with something like this:

      CustomLog /var/log/httpd/ssl_request_log "%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b"

Collect some data for a few days, then update your cipher suite. In most cases, you'll probably want to see RC4-SHA (for now), since it's fast, widely supported and immune to BEAST attacks.

Kind of surprised there is not a single word about AES-NI in there.

Both Intel and AMD now support it in modern server cpus.

You want to be using aes128-cbc to take advantage of it.

http://google.com/search?q=cache:http://zombe.es/post/407872...

> Activate caching for static assets

A quick and dirty test in Firebug on one of my SSL sites seems to indicate that Firefox is serving SSL content from the cache already. Is this a Firefox thing or am I overlooking an Apache configuration I might have set?

If you care about compatibility with applications that use Schannel for TLS on Windows XP or Windows Server 2003, be aware of which ciphers it supports/doesn't support:

http://msdn.microsoft.com/en-us/library/windows/desktop/aa38...

Note that there are no ciphers that use AES for encryption in that list.

tl;dr: Make sure TLS_RSA_WITH_RC4_128_SHA ("RC4-SHA" in OpenSSL) is in your server's cipher list if you care about Windows XP and removed the 3DES ciphers because they're "too slow."

I wouldn't recommend "KeepAlive On" in Apache using the standard mpm_worker model unless you really know what you're doing. It does conserve some TCP handshaking round-trips, but it could cause resource starvation (in the form of denied connections, or connections timed out that are waiting in the TCP listen queue) when MaxClients is reached. Children are precious and limited, and many could be occupied waiting for subsequent requests that may never arrive - from the time the connection is received to the time it is disconnected, the child process can't do anything else.

In general, keep-alives are best used with event-driven webservers like nginx, which doesn't have this issue. It's a common practice to put an nginx reverse proxy or a good load balancer like an F5 BIG-IP (with keep-alives on) in front of Apache (with keep-alives off) for this reason.

If you use this model, be sure to set the proxy_buffers in nginx high enough to consume the largest possible response from the Apache backend, because Apache children will also block waiting for clients to receive complete responses.

Why not stay on a safe site and enable private caching (Cache-Control: private)? Any advantages of public?

I'd love to see this article with the nginx equivalent configuration directives.

I had to change the ciphers in nginx a while ago, and was absolutely amazed at how much faster it became.

Good tips.

Why isn't apache and/or openssl shipping with "optimized" defaults already?

Nicely done. I was worried when I saw the headline that he wasn't going to take security into account...

awesome