[prev in list] [next in list] [prev in thread] [next in thread] 

List:       tomcat-user
Subject:    Re: Apache httpd as reverse proxy in front of Tomcat 10.1 - Different Connectors vs. HTTP request sm
From:       Christopher Schultz <chris () christopherschultz ! net>
Date:       2023-05-08 20:54:12
Message-ID: 7006acce-edf9-6ea7-d5eb-cf60c6cac0c6 () christopherschultz ! net
[Download RAW message or body]

Reg,

On 5/5/23 23:48, r.barclay@habmalnefrage.de wrote:
> I have some questions about HTTP request smuggling in the context of Tomcat with \
> Apache httpd as its reverse proxy. 
> First of all, a few words about my current setup: At the moment I have a few \
> applications that are deployed this way: I use Tomcat 10.1 as my backend server. It \
> only activates its AJP connector (no HTTP(S)). In front, there is an Apache httpd \
> 2.4 with mod_jk as a reverse proxy for my Tomcat. Apache httpd does SSL termination \
> and HSTS redirecting and rejects some trash traffic before it could reach Tomcat. \
> mod_jk is used with the more or less default configuration, which includes reuse of \
> backend AJP connections. 
> Question 1:
> Assuming I use the up-to-date package versions in Debian 11, is this setup prone to \
> HTTP request smuggling? If that might be the case, what steps should be taken \
> against? Do users have to enable "JkOptions +DisableReuse" to prevent HTTP request \
> smuggling? Or is the AJP protocol somewhat "immune" against the confusion about the \
> request headers Content-Length, Transfer-Encoding etc.? I haven't found much about \
> the topic "mod_jk + request smuggling".

mod_jk is a little less prone to mismatches between httpd and Tomcat 
interpretation of HTTP messages, which is the root of pretty much all 
request-smuggling issues. The reason is that mod_jk was built 
specifically for proxying to Tomcat and its URL-handling rules match the 
Servlet API. Compare that to mod_proxy which was designed to proxy any 
number of protocols and even when used with HTTP can be configured to 
handle URLs in several different ways.

As long as httpd doesn't get confused about what is a header, mod_jk 
will not make anything worse.

You /can/ +DisableReuse but that will kill your performance. If 
performance is not a consideration (e.g. low volume, etc.) then it's a 
great way to prevent one client from bashing requests (or, more likely, 
responses) intended for another client.

> Question 2:
> In a new application I will have to use websockets.
> It seems websockets do not work over AJP / mod_jk.

This is correct: Websockets essentially cannot be proxied over mod_jk.

> So I will have to enable Tomcat's HTTP connector and use mod_proxy_wstunnel in the \
> Apache httpd reverse proxy. Therefore, the setup probably won't use AJP / mod_jk at \
> all, but mod_proxy_http, connecting to Tomcat's HTTP connector. What steps does one \
> have to take against HTTP request smuggling in this case? Do we have to use \
> "disablereuse=on keepalive=off" on the Apache httpd side?

keepalive=off will kill your performance even worse than disablereuse=on 
because even a single client cannot make multiple requests across a 
single connection.

I would read all of the various security-related configuration options 
for mod_proxy and mod_proxy_wstunnel (if there are any). Mostly, the 
pain points will be in URL handling and not really the headers, since 
httpd already does a really good job of rejecting requests whose headers 
are mangled.

You might consider using something like mod_security which looks at a 
lot of semantic stuff in requests and rejects all kinds of funny-looking 
stuff that may be spec-compliant but still ... shady-looking.

> What are your experiences / best practices?
> 
> Question 3:
> Do the Apache httpd and Apache Tomcat projects coordinate their header processing \
> algorithms, header normalization efforts etc. to combat HTTP request smuggling?

To the extent possible without lock-stepping our two communities. There 
is some overlap between the committers on the projects, but mostly we 
are distinct groups. But instead of trying to coordinate our efforts, 
the Tomcat team takes the stance that the RFCs are the Source of Truth 
and should be followed, and any product (including httpd) that deviates 
from them is out-of-spec and ought to be changed.

I suspect that the httpd team takes that same stance, but I haven't 
asked for an official statement. Also, httpd has a 30-year history at 
this point and some "old behavior" needs to be preserved for 
compatibility reasons. But usually anything that violates the spec must 
be changed from the default configuration.

> So is the combination of "Apache httpd + (mod_jk | mod_proxy_*) + Apache Tomcat" \
> considered "HTTP request smuggling"-safe in general?

I should hope so, as a significant portion of the users of this mailing 
list are using that exact configuration. ;)

-chris

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


[prev in list] [next in list] [prev in thread] [next in thread]