RE: Question in regards to the Connector allowHostHeaderMismatch when it is set to "false"
Hi Mark,
In the example above...the port remains the same (8143). How is it different?
From: Mark Thomas
Sent: Friday, May 5, 2023 4:56 PM
To: Tomcat Users List
Subject: [EXTERNAL] Re: Question in regards to the Connector
allowHostHeaderMismatch when it is set to "false"
5 May 2023 18:21:02 Alvaro Garay :
> Hi,
>
>
> Tomcat version: 9.0.73
>
> Operating system: Unix z/OS System
>
>
>
> I have a question in regard to the Connector attribute
> allowHostHeaderMismatch=false which checks the request line is
> consistent with the Host Header.
>
> So in this scenario, I have the request line using the absolute path
> with a conflicting host header. The response is 400 Bad Request from
> Tomcat, which makes sense.
>
> telnet myhostname.company.com 8143
> GET http://myhostname.company.com/api/v1/endpoint HTTP/1.1
> Host: facebook.com
>
>
> If I define a valid host header now, then the request is a success. So
> all is good.
>
> telnet myhostname.company.com 8143
> GET http://myhostname.company.com/api/v1/endpoint HTTP/1.1
> Host: myhostname.company.com
>
> telnet 1.1.1.1 8143
> GET http://1.1.1.1/api/v1/endpoint HTTP/1.1
> Host: 1.1.1.1
>
> However, as soon as I define a port number in the host header with
> syntax : then I get 400 Bad Request from Tomcat.
>
> telnet myhostname.company.com 8143
> GET http://myhostname.company.com/api/v1/endpoint HTTP/1.1
> Host: myhostname.company.com:8143
>
> HTTP/1.1 400
> Content-Type: text/html;charset=utf-8
> Content-Language: en
> Content-Length: 762
> Date: Fri, 05 May 2023 15:27:09 GMT
> Connection: close
>
> HTTP Status 400 \u2013 Bad
> Requestbody
> {font-family:Tahoma,Arial,sans-serif;} h1, h2, h3, b
> {color:white;background-color:#525D76;} h1 {font-size:22px;} h2
> {font-size:16px;} h3 {font-size:14px;} p {font-size:12px;} a
> {color:black;} .line
> {height:1px;background-color:#525D76;border:none;}HTTP
> Status 400 \u2013 Bad RequestType
> Status ReportDescription The server cannot or will not
> process the request due to something that is perceived to be a client
> error (e.g., malformed request syntax, invalid request message framing,
> or deceptive request routing).Apache
> Tomcat/9.0.73
>
> This request should be allowed right?
No. Different port means a different host so Tomcat correctly rejects the
request.
Mark
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Jakarta - Sources you'd recommend
Hello folks! I am trying to learn how to program web pages using Java, but I am having serious difficulties understanding the how to. So, is there a source [books, web sites, etc.] anyone here can recommend me. Thanks in advance. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Jakarta - Sources you'd recommend
YouTube is an excellent resource.Sent from my T-Mobile 5G Device Original message From: Amn Ojee Uw Date: 5/8/23 10:21 AM (GMT-05:00) To: users@tomcat.apache.org Subject: Jakarta - Sources you'd recommend Hello folks!I am trying to learn how to program web pages using Java, but I am having serious difficulties understanding the how to. So, is there a source [books, web sites, etc.] anyone here can recommend me.Thanks in advance.-To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.orgFor additional commands, e-mail: users-h...@tomcat.apache.org
Re: Question in regards to the Connector allowHostHeaderMismatch when it is set to "false"
On 08/05/2023 13:52, Alvaro Garay wrote:
Hi Mark,
In the example above...the port remains the same (8143). How is it different?
GET http://myhostname.company.com/api/v1/endpoint HTTP/1.1
The host is "myhostname.company.com"
Host: myhostname.company.com:8143
The host is "myhostname.company.com:8143"
"myhostname.company.com" != "myhostname.company.com:8143"
The port the client connects to is irrelevant. All that matters is the
host in the request line and the host header.
1. The host header MUST be present
2. If a host is present in the request line it MUST be identical (host
and port) to the host header.
Mark
From: Mark Thomas
Sent: Friday, May 5, 2023 4:56 PM
To: Tomcat Users List
Subject: [EXTERNAL] Re: Question in regards to the Connector allowHostHeaderMismatch when
it is set to "false"
5 May 2023 18:21:02 Alvaro Garay :
Hi,
Tomcat version: 9.0.73
Operating system: Unix z/OS System
I have a question in regard to the Connector attribute
allowHostHeaderMismatch=false which checks the request line is
consistent with the Host Header.
So in this scenario, I have the request line using the absolute path
with a conflicting host header. The response is 400 Bad Request from
Tomcat, which makes sense.
telnet myhostname.company.com 8143
GET http://myhostname.company.com/api/v1/endpoint HTTP/1.1
Host: facebook.com
If I define a valid host header now, then the request is a success. So
all is good.
telnet myhostname.company.com 8143
GET http://myhostname.company.com/api/v1/endpoint HTTP/1.1
Host: myhostname.company.com
telnet 1.1.1.1 8143
GET http://1.1.1.1/api/v1/endpoint HTTP/1.1
Host: 1.1.1.1
However, as soon as I define a port number in the host header with
syntax : then I get 400 Bad Request from Tomcat.
telnet myhostname.company.com 8143
GET http://myhostname.company.com/api/v1/endpoint HTTP/1.1
Host: myhostname.company.com:8143
HTTP/1.1 400
Content-Type: text/html;charset=utf-8
Content-Language: en
Content-Length: 762
Date: Fri, 05 May 2023 15:27:09 GMT
Connection: close
HTTP Status 400 \u2013 Bad
Requestbody
{font-family:Tahoma,Arial,sans-serif;} h1, h2, h3, b
{color:white;background-color:#525D76;} h1 {font-size:22px;} h2
{font-size:16px;} h3 {font-size:14px;} p {font-size:12px;} a
{color:black;} .line
{height:1px;background-color:#525D76;border:none;}HTTP
Status 400 \u2013 Bad RequestType
Status ReportDescription The server cannot or will not
process the request due to something that is perceived to be a client
error (e.g., malformed request syntax, invalid request message framing,
or deceptive request routing).Apache
Tomcat/9.0.73
This request should be allowed right?
No. Different port means a different host so Tomcat correctly rejects the
request.
Mark
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Supporting Proxy Protocol in Tomcat
Amit, On 5/4/23 16:07, Amit Pande wrote: We have a similar requirement as mentioned in the below enhancement request. https://bz.apache.org/bugzilla/show_bug.cgi?id=57830 Is there any plan to add this support in Tomcat in future releases? Nothing at the moment that I know of. I thought that markt had looked at this a while back and said it didn't look too difficult. It does require Tomcat to handle the stream directly and not just rely on Java's SSLServerSocket. I thought that had been done at some point, but it may not have. Handling the stream directly may have some other advantages as well, though it definitely makes the code more complicated. Also, since this was requested long time back and there is no update, are there any other alternatives to pass the client information from load balancer to Tomcat in situations where there is no SSL termination at load balancer? You mean like a network load balancer where the lb is just proxying bytes and not looking at the data at all? The PROXY protocol really is the best way to do that, honestly. -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Apache httpd as reverse proxy in front of Tomcat 10.1 - Different Connectors vs. HTTP request smuggling
Reg, On 5/5/23 23:48, r.barc...@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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Jakarta - Sources you'd recommend
Amn,
On 5/8/23 10:20, Amn Ojee Uw wrote:
I am trying to learn how to program web pages using Java, but I am
having serious difficulties understanding the how to. So, is there a
source [books, web sites, etc.] anyone here can recommend me.
How much do you want to read, and how much do you want to know?
If you just want to dabble in JSP, google for "JSP tutorial" and have at it.
If you want to learn like everything, I can recommend "Professional Java
for Web Applications" by Nick Williams.
Whatever you choose, be sure to look at the copyright date: there are
loads of books out there published in 2001 which have really terrible
advice. By 2014, pretty much everything had settled down but now there
is a new big change: the switch from Java EE to Jakarta EE and AFAIK
there aren't any books that cover the new APIs. Those APIs are somewhat
literally just "global search-and-replace javax. -> jakarta." but there
are some subtle changes.
If you start with Java EE ("old style") then use Tomcat 9. If you start
with Jakarta EE, then use Tomcat 10. (You can technically use Tomcat 10
for both, but there's no need to complicate your life too much with the
differences at this point).
-chris
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Question in regards to the Connector allowHostHeaderMismatch when it is set to "false"
Alvaro,
On 5/8/23 10:39, Mark Thomas wrote:
On 08/05/2023 13:52, Alvaro Garay wrote:
Hi Mark,
In the example above...the port remains the same (8143). How is it
different?
GET http://myhostname.company.com/api/v1/endpoint HTTP/1.1
The host is "myhostname.company.com"
Host: myhostname.company.com:8143
The host is "myhostname.company.com:8143"
"myhostname.company.com" != "myhostname.company.com:8143"
The port the client connects to is irrelevant. All that matters is the
host in the request line and the host header.
1. The host header MUST be present
2. If a host is present in the request line it MUST be identical (host
and port) to the host header.
nb the spec says that the URL takes precedence if there is a mismatch,
but when setting allowHostHeaderMismatch="false" (the current default),
then Tomcat is being stricter than the spec.
The reason Tomcat is being stricter than the spec by default is because
usually Host <> URL host mismatch is an indication that the client is
doing something it should not be doing.
-chris
From: Mark Thomas
Sent: Friday, May 5, 2023 4:56 PM
To: Tomcat Users List
Subject: [EXTERNAL] Re: Question in regards to the Connector
allowHostHeaderMismatch when it is set to "false"
5 May 2023 18:21:02 Alvaro Garay :
Hi,
Tomcat version: 9.0.73
Operating system: Unix z/OS System
I have a question in regard to the Connector attribute
allowHostHeaderMismatch=false which checks the request line is
consistent with the Host Header.
So in this scenario, I have the request line using the absolute path
with a conflicting host header. The response is 400 Bad Request from
Tomcat, which makes sense.
telnet myhostname.company.com 8143
GET http://myhostname.company.com/api/v1/endpoint HTTP/1.1
Host: facebook.com
If I define a valid host header now, then the request is a success. So
all is good.
telnet myhostname.company.com 8143
GET http://myhostname.company.com/api/v1/endpoint HTTP/1.1
Host: myhostname.company.com
telnet 1.1.1.1 8143
GET http://1.1.1.1/api/v1/endpoint HTTP/1.1
Host: 1.1.1.1
However, as soon as I define a port number in the host header with
syntax : then I get 400 Bad Request from Tomcat.
telnet myhostname.company.com 8143
GET http://myhostname.company.com/api/v1/endpoint HTTP/1.1
Host: myhostname.company.com:8143
HTTP/1.1 400
Content-Type: text/html;charset=utf-8
Content-Language: en
Content-Length: 762
Date: Fri, 05 May 2023 15:27:09 GMT
Connection: close
HTTP Status 400 \u2013 Bad
Requestbody
{font-family:Tahoma,Arial,sans-serif;} h1, h2, h3, b
{color:white;background-color:#525D76;} h1 {font-size:22px;} h2
{font-size:16px;} h3 {font-size:14px;} p {font-size:12px;} a
{color:black;} .line
{height:1px;background-color:#525D76;border:none;}HTTP
Status 400 \u2013 Bad RequestType
Status ReportDescription The server cannot or will not
process the request due to something that is perceived to be a client
error (e.g., malformed request syntax, invalid request message framing,
or deceptive request routing).Apache
Tomcat/9.0.73
This request should be allowed right?
No. Different port means a different host so Tomcat correctly rejects the
request.
Mark
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Question in regards to the Connector allowHostHeaderMismatch when it is set to "false"
Hi,
This makes sense now. Thank you for clarifying.
Best,
Alvaro
From: Christopher Schultz
Sent: Monday, May 8, 2023 5:04 PM
To: users@tomcat.apache.org
Subject: [EXTERNAL] Re: Question in regards to the Connector
allowHostHeaderMismatch when it is set to "false"
Alvaro,
On 5/8/23 10:39, Mark Thomas wrote:
> On 08/05/2023 13:52, Alvaro Garay wrote:
>> Hi Mark,
>>
>> In the example above...the port remains the same (8143). How is it
>> different?
>
> GET http://myhostname.company.com/api/v1/endpoint HTTP/1.1
>
> The host is "myhostname.company.com"
>
> Host: myhostname.company.com:8143
>
> The host is "myhostname.company.com:8143"
>
> "myhostname.company.com" != "myhostname.company.com:8143"
>
> The port the client connects to is irrelevant. All that matters is the
> host in the request line and the host header.
>
> 1. The host header MUST be present
> 2. If a host is present in the request line it MUST be identical (host
> and port) to the host header.
nb the spec says that the URL takes precedence if there is a mismatch,
but when setting allowHostHeaderMismatch="false" (the current default),
then Tomcat is being stricter than the spec.
The reason Tomcat is being stricter than the spec by default is because
usually Host <> URL host mismatch is an indication that the client is
doing something it should not be doing.
-chris
>> From: Mark Thomas
>> Sent: Friday, May 5, 2023 4:56 PM
>> To: Tomcat Users List
>> Subject: [EXTERNAL] Re: Question in regards to the Connector
>> allowHostHeaderMismatch when it is set to "false"
>>
>>
>> 5 May 2023 18:21:02 Alvaro Garay :
>>
>>> Hi,
>>>
>>>
>>> Tomcat version: 9.0.73
>>>
>>> Operating system: Unix z/OS System
>>>
>>>
>>>
>>> I have a question in regard to the Connector attribute
>>> allowHostHeaderMismatch=false which checks the request line is
>>> consistent with the Host Header.
>>>
>>> So in this scenario, I have the request line using the absolute path
>>> with a conflicting host header. The response is 400 Bad Request from
>>> Tomcat, which makes sense.
>>>
>>> telnet myhostname.company.com 8143
>>> GET http://myhostname.company.com/api/v1/endpoint HTTP/1.1
>>> Host: facebook.com
>>>
>>>
>>> If I define a valid host header now, then the request is a success. So
>>> all is good.
>>>
>>> telnet myhostname.company.com 8143
>>> GET http://myhostname.company.com/api/v1/endpoint HTTP/1.1
>>> Host: myhostname.company.com
>>>
>>> telnet 1.1.1.1 8143
>>> GET http://1.1.1.1/api/v1/endpoint HTTP/1.1
>>> Host: 1.1.1.1
>>>
>>> However, as soon as I define a port number in the host header with
>>> syntax : then I get 400 Bad Request from Tomcat.
>>>
>>> telnet myhostname.company.com 8143
>>> GET http://myhostname.company.com/api/v1/endpoint HTTP/1.1
>>> Host: myhostname.company.com:8143
>>>
>>> HTTP/1.1 400
>>> Content-Type: text/html;charset=utf-8
>>> Content-Language: en
>>> Content-Length: 762
>>> Date: Fri, 05 May 2023 15:27:09 GMT
>>> Connection: close
>>>
>>> HTTP Status 400 \u2013 Bad
>>> Requestbody
>>> {font-family:Tahoma,Arial,sans-serif;} h1, h2, h3, b
>>> {color:white;background-color:#525D76;} h1 {font-size:22px;} h2
>>> {font-size:16px;} h3 {font-size:14px;} p {font-size:12px;} a
>>> {color:black;} .line
>>> {height:1px;background-color:#525D76;border:none;}HTTP
>>> Status 400 \u2013 Bad RequestType
>>> Status ReportDescription The server cannot or will not
>>> process the request due to something that is perceived to be a client
>>> error (e.g., malformed request syntax, invalid request message framing,
>>> or deceptive request routing).Apache
>>> Tomcat/9.0.73
>>>
>>> This request should be allowed right?
>>
>> No. Different port means a different host so Tomcat correctly rejects the
>> request.
>>
>> Mark
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>
>>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
CommunityOverCode Asia 2023 is calling for Presentations!
Hi All, Community over Code Asia 2023 (formerly ApacheCon Asia) will be held in person this year in Beijing [1]. The CFP will end on Tuesday, Jun 6th, 2023 8:00 AM (Beijing time - UTC +8). For details could be found on the website [1]. Note that for those that can't be present, a pre-recorded video is also acceptable. Please do not hesitate to submit, including the Web Server/Tomcat track as well as the others! [1] https://www.bagevent.com/event/cocasia-2023-EN -- Best Regards！ Huxing - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Question in regards to the Connector allowHostHeaderMismatch when it is set to "false"
On 08/05/2023 22:04, Christopher Schultz wrote: On 5/8/23 10:39, Mark Thomas wrote: The port the client connects to is irrelevant. All that matters is the host in the request line and the host header. 1. The host header MUST be present 2. If a host is present in the request line it MUST be identical (host and port) to the host header. nb the spec says that the URL takes precedence if there is a mismatch, but when setting allowHostHeaderMismatch="false" (the current default), then Tomcat is being stricter than the spec. That is not correct. The two requirements stated above have been RFC "MUST" requirements since 2014. RFC 2616 (June 1999) stated that any host in the request line takes precedence. RFC 7230 (June 2014) stated that any host in the request line MUST match the host header although there is also language that suggests they might be different. RFC 9112 (June 2022) states that any host in the request line MUST match the host header. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
