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.