Can you use gzip over SSL? And Connection: Keep-Alive headers

Question

I'm evaluating the front end performance of a secure (SSL) web app here at work and I'm wondering if it's possible to compress text files (html/css/javascript) over SSL. I've done some googling around but haven't found anything specifically related to SSL. If it's possible, is it even worth the extra CPU cycles since responses are also being encrypted? Would compressing responses hurt performance?

Also, I'm wanting to make sure we're keeping the SSL connection alive so we're not making SSL handshakes over and over. I'm not seeing Connection: Keep-Alive in the response headers. I do see Keep-Alive: 115 in the request headers but that's only keeping the connection alive for 115 milliseconds (seems like the app server is closing the connection after a single request is processed?) Wouldn't you want the server to be setting that response header for as long as the session inactivity timeout is?

I understand browsers don't cache SSL content to disk so we're serving the same files over and over and over on subsequent visits even though nothing has changed. The main optimization recommendations are reducing the number of http requests, minification, moving scripts to bottom, image optimization, possible domain sharding (though need to weigh the cost of another SSL handshake), things of that nature.

Answer 1

Yes, compression can be used over SSL; it takes place before the data is encrypted so can help over slow links. It should be noted that this is a bad idea: this also opens a vulnerability.

After the initial handshake, SSL is less of an overhead than many people think* - even if the client reconnects, there's a mechanism to continue existing sessions without renegotiating keys, resulting in less CPU usage and fewer round-trips.

Load balancers can screw with the continuation mechanism, though: if requests alternate between servers then more full handshakes are required, which can have a noticeable impact (~few hundred ms per request). Configure your load balancer to forward all requests from the same IP to the same app server.

Which app server are you using? If it can't be configured to use keep-alive, compress files and so on then consider putting it behind a reverse proxy that can (and while you're at it, relax the cache headers sent with static content - HttpWatchSupport's linked article has some useful hints on that front).

(*SSL hardware vendors will say things like "up to 5 times more CPU" but some chaps from Google reported that when Gmail went to SSL by default, it only accounted for ~1% CPU load)

Answer 2

1. You should probably never use TLS compression. Some user agents (at least Chrome) will disable it anyways.

2. You can selectively use HTTP compression

3. You can always minify

4. Let's talk about caching too

I am going to assume you are using an HTTPS Everywhere style web site.

Scenario:

1. Static content like css or js:

   • Use HTTP compression
   • Use minification
   • Long cache period (like a year)
   • etag is only marginally useful (due to long cache)
   • Include some sort of version number in the URL in your HTML pointing to this asset so you can cache-bust

2. HTML content with ZERO sensitive info (like an About Us page):

   • Use HTTP compression
   • Use HTML minification
   • Use a short cache period
   • Use etag

3. HTML content with ANY sensitive info (like a CSRF token or bank account number):

   • NO HTTP compression
   • Use HTML minification
   • Cache-Control: no-store, must-revalidate
   • etag is pointless here (due to revalidation)
   • some logic to redirect the page after session timeout (taking into account multiple tabs). If someone presses the browser's Back button, the sensitive info is not displayed due to the cache header.

You can use HTTP compression with sensitive data IF:

1. You never return user input in the response (got a search box? don't use HTTP compression)
2. Or you do return user input in the response but randomly pad the response

Answer 3

Using compression with SSL opens you up to vulnerabilities like BREACH, CRIME, or other chosen plain-text attacks.

You should disable compression as SSL/TLS have no way to currently mitigate against these length oracle attacks.