Hash: SHA256


On 3/23/20 11:35, Mark Thomas wrote:
> On 23/03/2020 14:59, Christopher Schultz wrote:
> <snip/>
>> My only concern here is that request line + header-processing
>> really has to match whatever reverse proxy servers are doing as
>> well, and that's really not something we can know for sure. I
>> don't think there is a single safe implementation that will make
>> everyone happy.
> I think everything is, slowly, getting stricter. Generally as a
> result of request smuggling vulnerabilities and the like.
>> Is there a way to make this kind of thing pluggable with a few
>> obvious implementations so that users can select which one makes
>> the most sense for their environment? Similar to
>> cookie-proessing, we could have a super-spec-compliant one which
>> always requires CRLF line endings (which I guess means dropping
>> support for HTTP 0.9), and is super strict about everything
>> else.
> Yes, it is possible. I'm not sure if truly pluggable or
> configurable makes the most sense. I haven't looked at it too
> closely.
>> Another implementation could work the way Tomcat currently
>> behaves, being mostly spec-compliant and a little tolerant of
>> some sloppiness.
>> This will allow an environment where e.g. httpd is in use to use
>> one implementation while Squid, IIS, nginx, etc. can make
>> different choices depending upon how the proxy will interpret
>> things.
>> I realize that means more code. :( But if the proxy and origin
>> server disagree about how to interpret things, Bad Things can
>> happen. If we take a very strict interpretation of everything, I
>> think we can actually make the origin server safe, but we may
>> break environments which are relying on non-strict behavior.
> So far, the biggest breakage was caused by a regression in
> Tomcat's parsing of valid HTTP/0.9 requests. The approach you
> describe wouldn't address that sort of issue.
> We have had one additional report of new breakage with a client
> that uses LFLF as the line terminator but has never been valid and
> it was pure luck that Tomcat used to allow it - it was never
> intended to be allowed.
> My preference at this point is to concentrate on improving the
> unit tests to reduce the chances of regressions as and when we do
> make changes to the parsing code.
> I'm not completely against making request line (and header)
> parsing pluggable / configurable but relaxing parsing goes against
> the current direction we have been heading in and I'd need a lot of
> convincing to support such an approach.

Sounds good. I entirely missed your actual proposal, which was below
your signature and after your references:

On 3/23/20 09:01, Mark Thomas wrote:
> With all of the above in mind I propose:
> - Doing nothing! I think Tomcat is striking the right balance
> here.
> This means: GET /CRLF   -> processed as HTTP/0.9 GET /LF     ->
> processed as HTTP/0.9 GET / CRLF  -> processed as HTTP/1.1 and
> rejected as invalid GET / LF    -> processed as HTTP/1.1 and
> rejected as invalid
> I want to write some tests to check this is behaving as expected
> but I'm not expecting any changes to the parsing at this point.
I think I like the above very much.

- -chris
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/


To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Reply via email to