Re: HTTP/2: allow binary data in header field values

Hi Willy,

> I really don't like this, because it becomes possible for a sender to
> produce special values on the other side by benefitting from the
> decoding, thus evading certain filtering measures. For example, an
> agent may send :
>
>    Content-Encoding: \x00\x83\x38\xa9
>
> and the binary-aware recipient having to "encode" it as gzip would
> apply base64 to "\x83\x38\xa9" and would produce :
>
>    Content-Encoding: gzip
>
> You can apply the same principle to other fields like content-length or
> other and easily cause some trouble. If you need this, at the very least
> it's important to enclose the encoded value between some "rare enough"
> characters to prevent such risks. Something like this for example :
>
>    Binary-Header: $b64<Y2h1bmtlZA==>$
>
> The example above would produce  :
>
>    Content-Encoding: $b64<gzip>$
>
> That's just an example of course.

Good point, I didn't consider that.

> This is really the part which needs to be verified I think.
>
> I'm now thinking that prefixing the value with <CR><NUL> instead of <NUL>
> could be more efficient : while <NUL> may translate to an end of string
> on many implementations and simply result in a field silently being
> processed as empty, a <CR> in the middle of a string is always an
> error, unless the next character is <LF> in which case what follows is
> the next header field. In case a gateway would inappropriately forward
> the <CR> to HTTP/1, it would produce an invalid message, even if
> truncated on the <NUL> since the line would end in <CR><CR><LF>.
>
> (...)
>
> I don't disagree and think that some fields could later become binary
> (dates, etc). I'm just extra careful for knowing that most HTTP/1 parsers
> are extremely lazy and that at least one H2 parser (the one I wrote) does
> not notice the presence of <CR>, <LF> or <NUL> in values. But this one is
> not yet deployed so it can be fixed. I don't know for other ones.

Sorry, I should have omitted the whole "NOTE". I added it only to
illustrate that in some deployments endpoints could abuse RFC7540's
restrictions to avoid base64 encoding on the first flight when they
assume that the peer is binary-aware and will negotiate the extension.
It wasn't meant to be the part of the draft, so please disregard it,
since it clearly side-tracked the discussion.

To reiterate, binary header field values prefixed with NUL byte (0x00)
would be sent only to binary-aware peers that announced support for
binary headers via HTTP/2 SETTINGS option, therefore, those headers
would never be seen by HTTP/1.x or HTTP/2 parsers that aren't aware of
this extension, so I'm not sure if there is any difference whether
it's <NUL>, <CR> or any combination of those.

Best regards,
Piotr Sikora

Received on Tuesday, 29 August 2017 06:56:33 UTC