How to turn off gzip compression for SSL traffic

[rmalayter]

B.R. Wrote:
> BREACH attacks the fact that compressed HTTP content encrypted with
> SSL
> makes it easy to guess a known existing header field from the request
> that
> is repeated in the (encrypted) answer looking at the size of the body.
> BEAST conclusion is: don't use HTTP compression underneath SSL
> encryption.

No, the conclusion is: don't echo back values supplied by the requester as
trusted in your *application* code. This is the most basic of anti-injection
protections. BREACH is the result of an application-layer problem, and needs
to be solved there. Why would you *ever* echo arbitrary header or form input
back to the requester alongside sensitive data?

A huge number of established security best practices prevent the BREACH
attack at the application layer; a man-in-the-middle as well as an
exploitable XSS/CSRF vulnerability is needed to even get the attack started.
Fix those issues first. Also, you should likely be rate-limiting responses
by session at your back-end to prevent DoS attacks. For the extra paranoid,
randomly HTML-entity-encode characters of any user data supplied before
echoing it back in a response, and add random padding of random length to
the HEAD of all responses. 

At the nginx layer, some sensible rate limits might also be an appropriate
mitigation: thousands-to-millions of requests are needed to extract secret
data with BREACH.

I haven't seen Google or any other large web site turn of gzip compression
of HTTPS responses yet because of BREACH. If *you* can actually afford to do
so, your traffic level is simply trivial. We would see approximately an 8x
increase in bandwidth costs (and corresponding 8x increase in end-user
response time) if we disabled GZIP for HTTPS connections.

Posted at Nginx Forum: http://forum.nginx.org/read.php?2,241953,242060#msg-242060