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

Hi Amos,

On Tue, Aug 29, 2017 at 05:44:40PM +1200, Amos Jeffries wrote:
> > 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,
> 
> No. Think TLS certificates and crypto keys in their binary form. Both CR and
> NUL are valid "string" characters. I'm suspecting delivery of such keys in
> headers is part of where this proposal is coming from.

Absolutely. What I mean is that I want to be sure that *if* such a field
escapes control (ie is mistakenly passed as-is to H1 via a gateway), it is
invalid before starting to process its contents.

> > 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 think so. A bare-CR in RFC 723x is no longer an end-of-line
> character.

That's exactly the point, it's not allowed unless followed by an LF,
so its presence followed by a NUL at the beginning of an accidentally
leaked value increases the likeliness of its detection by an H1 agent.

> When placed at the beginning or end of a field-value it is just a
> part of the BSP / OSP whitespace construction, and when placed mid-value it
> is part of the value string [albeit with malformed encoding].
> 
> The only invalid part here is the NUL. And ...
> 
> My experience from discussions with server admin in the past is that seeing
> CR NUL sequence where they expect HTTP/1 Mime-format headers people assume
> immediately that the NUL was supposed to be a LF and do something to 'fix'
> the problem by adding it as the message transits the Apache / IIS servers
> CGI gateway layer.

The problem I'm having with the NUL alone is that all those doing limited
checks will consider it as an end of string. But at least I see that we
agree that there's quite a risk here with legacy implementations.

Willy

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