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 _______________________________________________ nginx mailing list nginx@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx
