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.

Answer 1

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.

Answer 2

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 3

To your first question: SSL is working on a different layer than compression. In a sense these two are features of a web server that can work together and not overlap. Yes, by enabling compression you'll use more CPU on your server but have less of outgoing traffic. So it's more of a tradeoff.

To your second question: Keep-Alive behavior is really dependent on HTTP version. You could move your static content to a non-ssl server (may include images, movies, audio, etc)

Answer 4

Yes, gzip compression and Keep-Alive can be used with HTTPS/SSL. Also, browsers can cache SSL content.

This blog post has more information about tuning a web site for HTTPS/SSL:

http://blog.httpwatch.com/2009/01/15/https-performance-tuning/

Answer 5

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