Re: #879: Should servers interpret Transfer-Encoding in 1.0 requests?

So it sounds like 'MUST be handled as an error' might work (perhaps with some additional details about why it's unsafe): a specific compatibility mode that doesn't claim conformance is out of scope. We might want to add something like:

> Note that some implementations can be configured to process messages with both Content-Length and Transfer-Encoding to improve compatibility with non-conformant peers. Such modes should be only used when the security and interoperability considerations (as per above) are understood.

?


> On 19 Jul 2021, at 1:01 pm, Greg Wilkins <gregw@webtide.com> wrote:
> 
> 
> Jetty server is similar to squid.  By default we will send a 400 response to any request with both a Transfer-Encoding and a Content-Length.  However, we do have a legacy compliance mode that will allow both, in which case if the Transfer-Encoding includes chunking, then it is used rather than the content-length.
> 
> If you have some specific exploits that are of concern with such a mode, then please send them to us on security@webtide.com and we'd like to try them in this mode to see if any of our other checks will catch anything strange about them.
> 
> cheers
> 
> 
> 
> 
> 
> On Sun, 18 Jul 2021 at 17:54, Amos Jeffries <squid3@treenet.co.nz> wrote:
> On 13/07/21 7:43 pm, Mark Nottingham wrote:
> > <https://github.com/httpwg/http-core/issues/879>
> > 
> > Some security researchers have found what appears to be a situation where handling of Transfer-Encoding and Content-Length in a particular deployment can introduce a request smuggling vulnerability, even if the specification's requirements are followed closely.
> > 
> > See the issue for details. The heart of the question at this point is whether we can strengthen (to a SHOULD or MUST) or otherwise qualify this 'ought':
> > 
> >> If a message is received with both a Transfer-Encoding and a Content-Length header field, the Transfer-Encoding overrides the Content-Length.  Such a message might indicate an attempt to perform request smuggling (Section 9.5) or response splitting (Section 9.4) and ought to be handled as an error.
> > 
> > Their research indicates that a number of servers don't reject such requests.
> > 
> > Could implementers take a look and weigh in (here or on the issue)?
> 
> 
> There is allowance in the main spec for senders to deliver HTTP/1.0 on 
> messages even if the sender supports a higher version if it believes the 
> server is HTTP/1.0-only.
> 
> 
> Squid has configurable strict and relaxed modes of message parse/validate.
> 
> The relaxed mode (default) accepts such messages as if HTTP/1.1 sender 
> was trying to work around such buggy servers. Obeys the spec rules about 
> T-E overriding C-L. Then goes right on and sends HTTP/1.1 version to the 
> server anyway.
>   *IF* the client was right about the servers bugs needing "HTTP/1.0" we 
> are probably wrong to send the "HTTP/1.1". But I am not aware of any 
> problems being reported about it, ever.
> 
> The strict mode should be responding with an 'invalid-request' error 
> about framing issues spotted.
> 
> 
> Amos
> 
> 
> 
> -- 
> Greg Wilkins <gregw@webtide.com> CTO http://webtide.com

--
Mark Nottingham   https://www.mnot.net/

Received on Monday, 19 July 2021 05:49:09 UTC