On 10 Aug 2013, at 00:37, Eric Covener <cove...@gmail.com> wrote: > On Fri, Aug 9, 2013 at 5:24 PM, Steinar H. Gunderson > <sgunder...@bigfoot.com> wrote: >> On Tue, Aug 06, 2013 at 01:32:00PM -0400, Eric Covener wrote: >>> Another option in this neighborhood is small/varying deflate blocks. >>> But that probably limits the usefulness of deflate to the same extent >>> that it helps. The idea is to make it less likely that the user input >>> and secret get compressed together. >> >> It would be interesting to see how feasible “barriers” in mod_deflate would >> be. E.g., if my application outputs >> >> <input type="hidden" name="csrftoken" DEFLATE_BARRIER_START value="1234" >> DEFLATE_BARRIER_END> >> >> maybe mod_deflate could be taught not to compress the parts in-between. > > For this attack, it would be enough to compress that section by itself > -- a barrier between the reflected user input and the "secret".
I'd keep in mind that compression is simply an amplifier for this type of attack. It makes the approach more effective. But it is not essential; when you have in essence a largely known plaintext surrounding a short secret and an oracle. And the latter is not going to go away - current dominant site development models will make this worse; as do current operational models w.r.t. to picking such up early. So the only fundamental thing we can do (i.e. if we want to go beyond guessing (future) browser and developer introduced vulnerabilities at higher layers) is a wee bit of padding/random*-cruft insertion in key places. Perhaps even doing so by default. And whilst on this topic - may be good to also consider a slow migration away from RSA to at least DH and perhaps ECC where possible as our 'default's. Dw. *: or very pseudo - as not to make it simply a nop in statistics.
