<div dir="ltr"><div class="gmail_extra">On Tue, Aug 20, 2013 at 5:12 PM, rmalayter <span dir="ltr"><<a href="mailto:nginx-forum@nginx.us" target="_blank">nginx-forum@nginx.us</a>></span> wrote:<br><div class="gmail_quote">

<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">No, the conclusion is: don't echo back values supplied by the requester as<br>
trusted in your *application* code. This is the most basic of anti-injection<br>
protections. BREACH is the result of an application-layer problem, and needs<br>
to be solved there. Why would you *ever* echo arbitrary header or form input<br>
back to the requester alongside sensitive data?<br>
<br>
A huge number of established security best practices prevent the BREACH<br>
attack at the application layer; a man-in-the-middle as well as an<br>
exploitable XSS/CSRF vulnerability is needed to even get the attack started.<br>
Fix those issues first. Also, you should likely be rate-limiting responses<br>
by session at your back-end to prevent DoS attacks. For the extra paranoid,<br>
randomly HTML-entity-encode characters of any user data supplied before<br>
echoing it back in a response, and add random padding of random length to<br>
the HEAD of all responses.<br>
<br>
At the nginx layer, some sensible rate limits might also be an appropriate<br>
mitigation: thousands-to-millions of requests are needed to extract secret<br>
data with BREACH.<br>
<br>
I haven't seen Google or any other large web site turn of gzip compression<br>
of HTTPS responses yet because of BREACH. If *you* can actually afford to do<br>
so, your traffic level is simply trivial. We would see approximately an 8x<br>
increase in bandwidth costs (and corresponding 8x increase in end-user<br>
response time) if we disabled GZIP for HTTPS connections.<br>
</blockquote></div><br><div class="gmail_default" style="font-size:small;color:rgb(51,51,153)">​I took a shortcut.<br>You're right: deactivating gzip compression is usable only for relatively small websites.<br><br>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.<br>

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

<br>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.​</div>

<font size="1"><span style="color:rgb(102,102,102)">---<br></span><b><span style="color:rgb(102,102,102)">B. R.</span></b><span style="color:rgb(102,102,102)"></span></font>
</div></div>