Subject: Security implications of gzip #423

From: Martin Thomson <[email-masked]>
Date: Thu, 13 Mar 2014 21:58:54 +0100

Proposed text:

   HTTP/2 enables greater use of compression for both header fields
   (Section 4.3) and response bodies (Section 9.3).  Compression can
   allow an attacker to recover plaintext when plaintext under attacker
   control is compressed in the same context with secret data.

   There are demonstrable attacks on compression that exploit the
   characteristics of the web platform (e.g., [BREACH]).  The attacker
   induces multiple requests containing varying plaintext, observing the
   length of the resulting ciphertext in each, which reveals a shorter
   length when a guess about the secret is correct.

   Implementations MUST NOT compress plaintext that includes content
   from both confidential and potentially attacker-controlled sources in
   the same compression context.  Thus, even though gzip compression of
   response bodies is permitted for every response, it cannot be used
   every time.  An implementation MAY compress confidential and
   potentially attacker-controlled content independently, if such
   content can be reliably distinguished.

   Further considerations regarding the compression of header fields are
   described in [COMPRESSION].

http://http2.github.io/http2-spec/#rfc.section.10.6

---

From: Adrian Cole <[email-masked]>
Date: Thu, 13 Mar 2014 17:14:23 -0700

LG, except this sentence is awkward.

Thus, even though gzip compression of response bodies is permitted for
every response, it cannot be used every time.

Maybe substitute "it cannot be used every time" with "clients cannot
expect all responses to be gzipped." or similar?

-A

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Fri, 14 Mar 2014 01:41:54 +0100

>   length when a guess about the secret is correct.

I think "web platform" is a word to be avoided; one reason is that the
second result on Google for me is "By downloading and using the Web
Platform Installer (WebPI), you agree to the  license terms and privacy
statement for WebPI." and the third "With the Microsoft Web Platform you
get more than just a powerful set of tools, servers and technologies.
You get a complete eco-system of products" and I am not sure whether at
least those two refer to the same thing. The characteristics should be
spelled out if they are important.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Ted Johnson <[email-masked]>
Date: Fri, 14 Mar 2014 08:14:45 +0000

Martin,

You have done a good job of walking the line between explaining the attack
and that rational for the mediation concisely.  I have a couple of thoughts
on the last, implementations, paragraph.

The following statement is indirect and it 'may' clear what "every time"
means: "Thus, even though gzip compression of response bodies is permitted
for every response, it cannot be used every time.". For example, how
about, "Accordingly,
do not use gzip compression of the response body in this scenario".

I would also add that MUST NOT should really be testable for
compliance/conformance purposes.  Since HTTP does not define confidential
or attackers I think SHOULD NOT makes more sense for that statement.  Or
one might consider moving the MUST NOT to the next sentence.
Possible alternatives, "Thus, gzip compression of response bodies are
permitted for any response but MUST NOT be it cannot be always used." or
"Accordingly, implementations MUST NOT force the use gzip compression for
all response bodies"  (Might choose the word every over all)

Less important thought, the client system can in many situations be
responsible for the security of the information as well.  Think about
utility services that may not understand the sensitivity of the information
they hold or what constitutes an attacker.  The client/requestor might
actually hold the meta-data to know if a resource is confidential.  Is it
worth a mention that the accept-encoding by the consumer might inform the
appropriate encoding for the response for exactly these types of scenarios?
 I would imagine that accept-encoding (at least in revision ten) will be
used less frequently anyhow and would represent a more exceptional scenario.

Regards,
Ted

---

From: Martin Thomson <[email-masked]>
Date: Fri, 14 Mar 2014 11:41:56 -0700

On 14 March 2014 01:14, Ted Johnson <[email-masked]> wrote:
> for every response, it cannot be used every time.". For example, how about,
> "Accordingly, do not use gzip compression of the response body in this
> scenario".

The text I have currently says:

Thus, even though gzip compression of response bodies is permitted, it
cannot be used for all responses.

> compliance/conformance purposes.

This is, of course, highly contextual.  However, it is testable in
specific cases, even where it is not generically.  I can't tell you
what bits in your documents are secret or might be controlled by
others, but I'd hope that you can.  (If you aren't sure, I'd be
recommending that you avoid compression entirely.)

I'm not sure that a weaker recommendation would be better.

> actually hold the meta-data to know if a resource is confidential.

That's an interesting scenario, but I think that the best way of
handling this is to disable compression.  If there is any uncertainty
about whether data potentially contains a mix of secrets and
attacker-controlled data, don't compress.