Re: Security implications of gzip #423

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



On Thu, Mar 13, 2014 at 1:58 PM, Martin Thomson
<martin.thomson@gmail.com> wrote:
> 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
>

Received on Friday, 14 March 2014 00:14:50 UTC