- From: Mark Nottingham <mnot@mnot.net>
- Date: Mon, 19 Jul 2021 15:48:45 +1000
- To: HTTP Working Group <ietf-http-wg@w3.org>
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