How to turn off gzip compression for SSL traffic

[B.R.]

On Tue, Aug 20, 2013 at 5:12 PM, rmalayter <nginx-forum at nginx.us> wrote:

> 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.
>

​I took a shortcut.
You're right: deactivating gzip compression is usable only for relatively
small websites.

Anyway, I wonder which real-world scenario need to send back user requests
in its answers... maybe some application need this? I can't imagine a
serious use-case however.

For a quick cheat-sheet on possible mitigations, starting with the most
radical ones, some advice has already been provided here:
http://breachattack.com/#mitigations.

I maintain the 'turn the gzip compression off' piece of advice here, as I
suspect people managing HA or populated websites already understand the
problem deeper and don't need to ask on a specific webserver's mailing list
what 'recommendation' they provide... Thus I guess What I wrote fits the
audience here.​
---
*B. R.*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20130820/fc48982d/attachment-0001.html>