Security considerations: discuss BREACH in the context of gzip encoding

[reschke]

See https://lists.w3.org/Archives/Public/ietf-http-wg/2015JulSep/0295.html.

[royfielding]

I don't know what this issue is about. Was it intended for CICE?

[wtarreau]

The attack was described here : http://breachattack.com/

In short, if you can force a client to emit requests and affect user input that are reflected in compressed responses, you can guess some parts of the response by observing its length only, hence bypass encryption. If the response contains some secrets (tokens to access another site, etc) then they can be guessed this way.

I've only been aware of one of our users who was worried about this and wanted to disable Gzip compression to stay safe... I guess nobody really cares because there are too many "if" for the attack to be effective. But by mentioning it we could at least encourage implementations to leave the choice to the user when to compress or not. For example in haproxy we still don't provide an easy way to decide whether to compress or not on a per-request basis, and we should work on it at least to mitigate this attack (e.g. disable compression on responses to POST requests maybe or on non-cacheable responses).

[martinthomson]

As Willy says, this general class of attacks relies on the combination of generic compression (like gzip) and a mix of user-controlled content and secrets.

There are a lot of "if"s on this, but the web context is probably the most fraught. CICE doesn't come into this too much, because an attacker generally only can either control the entire request (but won't have the ability to access secrets in doing so) or just the URL and maybe the request body. None of the request contexts really have this unique blend of attacker-controlled and secret information.

However, for responses, it is common for user-generated content to be mixed with secrets. For instance, pages routinely put CSRF tokens into HTML that also contain user-generated messages. Compress those and you can do interesting things. There are plenty of ways in which the attack can be foiled, even accidentally, but also plenty of ways in which information can leak out. I suspect that the authors of the several papers in these areas struggled a little to find vulnerable sites because of this.

All that said, it's worth having some text explaining the basic setup. If you need a volunteer, I might be able to do something.

[royfielding]

Sorry, I should have been more specific. I know what the breach attack is about. What I don't know is the intended target of this issue. The IESG comment was on the CICE draft.

I will guess that @reschke created this issue because we are expected to address the attack somewhere in the core protocol so that we don't have to deal with describing it as a special case in all extension drafts. But where? Oh, never mind, that's why the issue title says security considerations.

[reschke]

I will guess that @reschke created this issue because we are expected to address the attack somewhere in the core protocol so that we don't have to deal with describing it as a special case in all extension drafts.

Indeed.

[mnot]

draft-handte-httpbis-dict-sec would be an excellent reference here, and save us from writing a lot of text. I think it's going to be up for adoption soon-is, so putting this on hold until that resolves.

[mnot]

I don't think that's going to happen in the timeframe we need it to. @reschke did you want to take this one?

[reschke]

Not really :-)