- From: Piotr Sikora <piotrsikora@google.com>
- Date: Mon, 28 Aug 2017 23:56:08 -0700
- To: Willy Tarreau <w@1wt.eu>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>, Craig Tiller <ctiller@google.com>
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