So I have these few compression directives at http level in nginx:

gzip on;
gzip_http_version 1.1;
gzip_vary on;

I read that this should be avoided because of CRIME/BREACH attack, is this correct?

3 Answers 3


I read that this should be avoided because of CRIME/BREACH attack, is this correct?

It depends.

The CRIME attack is already mitigated in current browsers in that they don't use TLS compression and have special handling of contexts in HTTP/2.0. BREACH is only relevant in the context of HTTP level compression if the following two conditions both apply at the same time (to cite http://www.breachattack.com/):

  • Reflect user-input in HTTP response bodies
  • Reflect a secret (such as a CSRF token) in HTTP response bodies

If none or only one of these apply you can use gzip without being affected by BREACH. This means you are safe to use it for any static pages or for any pages which don't include secrets like CSRF tokens (that's the secrets the attacker wants to extract).

Also the attacker needs multiple requests to the same site and must be able to look how the size of the transferred data changes. So if your secrets change all the time or if the site changes (like with adding random padding with a random size) the attacker will not be able to use BREACH. See also Defending against the BREACH Attack.


gzipping SSL-encrypted data eliminates the advantages of SSL to some extent. Yes, gzipping ALL content might opens your website up to the BREACH-vulnerability.

But you can still add some resources for gzipping. For example public images could be gzipped or public documents in general. However you should carefully consider if you want to "sabotate" your own SSL-Protection.

This also might be worth reading: https://stackoverflow.com/questions/2767211/can-you-use-gzip-over-ssl-and-connection-keep-alive-headers

EDIT: I'd like to add, that using SPDY you may achieve a similar compression through compressed Headers and a shortened negotiation/renegotiation of the keys. Also you can "pre"-compress frequently used resources (But that's not exclusive to SPDY).


How SSL/TLS and Gzipping works is that it maps data to reduce the size of a packet in a predictable and repeatable manner that can then be undone. This is not a problem if the pages are static and have no tokens or cookies sent with them. That is because the data requested from the site will constantly be the same and so the packet size will not change. However with a dynamic page, the content always changed except for a little bit in the CSRF and user data. Using that information they can inject data into a request or body. This is a problem because it allows them to change the contents of the packet and see how the compression maps. They eventually have access to certain things in the packet including cookies, any passwords or user information, Cross Site Request Forgery tokens, and anything else that was sent.

Because of this it is not recommended to use TLS/SSL for dynamic data compression of sensitive data because eventually the packet can be Breached.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .