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

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