Re: Call for Adoption: draft-reschke-rfc54987bis

On Wed, Apr 01, 2015 at 10:13:23AM +0200, Julian Reschke wrote:
> On 2015-03-31 07:42, Willy Tarreau wrote:
> >After a quick review, I think we should make it stricter. Currently,
> >it suggests that recipients should be prepared to receive invalid code
> >sequences but that can be dangerous when passing through multiple
> >intermediaries because all of them could have different fallback
> >methods. I'd rather make it clear that any recipient in the chain
> >which finds an encoding issue must return a 400 bad req.
> 
> a) It's not the case right now. How do you want to get this change 
> deployed in practice?

Just like we said that multiple content-length values are not acceptable
if different despite most implementations not doing the check yet. I mean,
by not specifying the control, we can leave the hole open.

> b) How do you want to signal an error on a *response*?

Good point. In haproxy we return a 502 bad gateway when the server
returns something unparsable. Only the client receives it and (in
rare occasions) reports it.

> >Also, I'd prefer to make it explicitly forbidden to %-encode US-ASCII
> >characters because this could be used to bypass some WAFs for example :
> >if it is detected that a server implements this standard and is able
> >to %-decode some attributes in header fields, and a WAF in the middle
> >does not, the client can abuse the %-encoding to try to hide some
> >activities.
> 
> Yes, that's the case right now. I'd argue that the spec has been out for 
> ages, so the intermediary ought to be fixed.

I had never heard about %-encoding in header fields to be honnest,
and I don't know which servers or intermediaries decode them given
that unless I'm mistaken, "%" is a valid character in a header field
and doesn't imply %-encoding.

> >In addition to this, probably that we should make it clear that some
> >characters must not be emitted nor encoded (NUL, CR, LF). The risk is
> >that some intermediaries decode them and replace them before passing
> >the request to the next hop and change the message header structure,
> >resulting in issues similar to HTTP request smugling attacks.
> 
> I think that depends on the header field it is used in.

That can become delicate.

> For instance, 
> RFC 6266 discusses these constraints for the filename parameter.

Indeed, I wasn't aware of this. And it uses the same syntax as in
your proposal.

> >Otherwise I think it could be useful indeed.
> 
> It already is, and has been for a long time.

It's just that I never heard about this.

I really think that in the future we should make better use of the
8bit-clean path of HTTP/2 to avoid having to repeat such exceptions,
but I'm sure we'll have to go a long way before reaching this stage :-/

Thanks,
Willy

Received on Wednesday, 1 April 2015 19:20:01 UTC