W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2014

Re: fixing TLS vulnerabilities with h2 was: ezflate: proposal to reinstitute deflate header compression

From: Matthew Kerwin <matthew@kerwin.net.au>
Date: Fri, 6 Jun 2014 08:26:36 +1000
Message-ID: <CACweHND2jeP87Uc3YFN==WS=c4v4OHLfsVGn_0bpusi3QjuSug@mail.gmail.com>
To: Greg Wilkins <gregw@intalio.com>
Cc: Willy Tarreau <w@1wt.eu>, "K.Morgan@iaea.org" <K.Morgan@iaea.org>, "C.Brunhuber@iaea.org" <C.Brunhuber@iaea.org>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>, RUELLAN Herve <Herve.Ruellan@crf.canon.fr>
On Jun 5, 2014 9:10 PM, "Greg Wilkins" <gregw@intalio.com> wrote:
>
> Having the padding in the spec is not that much of an intrusion, but I
just don't see what good it does.   If an application wants to pad it's
data for security reason, then it does not need a transport mechanism for
that.
>

If it only wants to pad the data during transport, then the padding is a
transport mechanism. Otherwise you need a higher-level padding mechanism
which both ends understand. Whitespace as a security feature sounds...
interesting...

> The only reason the transport needs to be aware of padding is if the
transport is expected to do something with it - ie like generate it.
>

Well, yeah. Generate at one end, and strip at the other. Why would my
application code ever want to touch a buffer full of 17000 null bytes?
Especially at the receiving end?

> But as the warnings in the draft clearly make out, generating padding is
apparently non trivial and should only be done by experts with detailed
knowledge of the actual payload.
>

Generating is trivial; knowing when to generate isn't.

>
> So if the transport is not going to generate the padding, not handle the
padding, etc. then why does the transport even need to know about the
padding?
>

Because the transport does generate it, but more importantly the transport
strips it at the other end. The receiving application never need know how
much padding was involved -- but if it does want to know, a simple int will
suffice, no point feeding it a huge chunk of allocated memory with no
semantic value whatsoever.

> To me it is setting false expectation that the implementation of h2 will
be safe from leaking information about their meta data and payloads.
>

Apparently so, but I suspect that comes from our different readings of the
spec. HTTP has lots of features that can help with security, if used
correctly, that are completely optional. It also contains cookies. I think
padding is just one of the former.
Received on Thursday, 5 June 2014 22:27:05 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:31 UTC