Can We Disable Chunked Encoding?

[Eric Robinson]

We've been seeing problems with failed requests where the response comes back 
with duplicate chunked encoding headers:

[Response]

HTTP/1.1 200
Strict-Transport-Security: max-age=86400; includeSubDomains;
Cache-Control: no-cache,no-store
isAuthenticated: true
X-FRAME-OPTIONS: SAMEORIGIN
Transfer-Encoding: chunked  <
X-XSS-Protection: 1; mode=block
vary: accept-encoding
Content-Encoding: gzip
Content-Type: text/xml;charset=ISO-8859-1
Transfer-Encoding: chunked  << Duplicate
Date: Wed, 05 Jul 2023 17:22:11 GMT

This is a violation of RFC 7230, so our nginx proxy is dropping the request and 
returning a 502 bad gateway error. I've spoken to F5 about this, and there's no 
way to make nginx ignore this violation. Unfortunately, the app is a canned 
product, and we don't have access to the code.

Is there a way to disable that behavior in Tomcat?

-Eric


Disclaimer : This email and any files transmitted with it are confidential and 
intended solely for intended recipients. If you are not the named addressee you 
should not disseminate, distribute, copy or alter this email. Any views or 
opinions presented in this email are solely those of the author and might not 
represent those of Physician Select Management. Warning: Although Physician 
Select Management has taken reasonable precautions to ensure no viruses are 
present in this email, the company cannot accept responsibility for any loss or 
damage arising from the use of this email or attachments.

RE: Apache Tomcat request smuggling in 9.0.68?

[James Boggs]

Hello,

I was sent this information, I hope this meets your expectations.

-
Request 1
GET / HTTP/1.1
Host: rplans.army.mil
Accept-Encoding: gzip, deflate
Accept: 
text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7
Accept-Language: en-US;q=0.9,en;q=0.8
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 
(KHTML, like Gecko) Chrome/113.0.5672.93 Safari/537.36
Connection: keep-alive
Cache-Control: max-age=0
Upgrade-Insecure-Requests: 1
Sec-CH-UA: ".Not/A)Brand";v="99", "Google Chrome";v="113", "Chromium";v="113"
Sec-CH-UA-Platform: Windows
Sec-CH-UA-Mobile: ?0
Content-Length: 61
Cookie: ai_user=zah6PVBAYp+ILUaHTr/CZn|2023-06-27T16:40:26.575Z; 
ai_session=4yP6RgcdmaqsiFQJVdym6I|1687884026682|1687884026682; 
_ga=GA1.2.1707569457.1687904638; _gid=GA1.2.1713949416.1687904638; _gat=1

GET /j6pnv4c5dp?j6pnv4c5dp=j6pnv4c5dp HTTP/1.1
X: kyhzap9frc
Response 1
HTTP/1.1 301 Moved Permanently
Server: AkamaiGHost
Content-Length: 0
Location: https://rplans.army.mil/
Date: Wed, 28 Jun 2023 01:37:07 GMT
Connection: Keep-Alive
Request 2
GET / HTTP/1.1
Host: rplans.army.mil
Accept-Encoding: gzip, deflate
Accept: 
text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7
Accept-Language: en-US;q=0.9,en;q=0.8
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 
(KHTML, like Gecko) Chrome/113.0.5672.93 Safari/537.36
Connection: keep-alive
Cache-Control: max-age=0
Upgrade-Insecure-Requests: 1
Sec-CH-UA: ".Not/A)Brand";v="99", "Google Chrome";v="113", "Chromium";v="113"
Sec-CH-UA-Platform: Windows
Sec-CH-UA-Mobile: ?0
Content-Length: 61
Cookie: ai_user=zah6PVBAYp+ILUaHTr/CZn|2023-06-27T16:40:26.575Z; 
ai_session=4yP6RgcdmaqsiFQJVdym6I|1687884026682|1687884026682; 
_ga=GA1.2.1707569457.1687904638; _gid=GA1.2.1713949416.1687904638; _gat=1

GET /j6pnv4c5dp?j6pnv4c5dp=j6pnv4c5dp HTTP/1.1
X: kyhzap9frc
Response 2
HTTP/1.1 301 Moved Permanently
Server: AkamaiGHost
Content-Length: 0
Location: https://rplans.army.mil/j6pnv4c5dp?j6pnv4c5dp=j6pnv4c5dp
Date: Wed, 28 Jun 2023 01:37:09 GMT
Connection: Keep-Alive
-

V/r,


James Boggs | Senior DBA/SA | Mobile: 571-337-0535
“Trust, Integrity, Loyalty to Our Customers, Employees and Partner”
VA Verified (SDVOSB) | SBA Certified 8(a) | SB | SDB | MBE/DBE (MD) | SWaM (VA)
ISO 9001:2015|ISO/IEC 2-1:2018|ISO/IEC 27001:2013|
CMMI-DEV Level 3 Appraised |
GSA Schedule Holder: IT-70#:GS35F237AA
GSA 8(a) STARS III#: 47QTCB21D0030
CIO-SP3 Contract#: HHSN316201800033W(SDVOSB)
CIO-SP3 Contract#: HHSN316201800054W(HUBZone) 
Seaport-NXG Contract#: N00178-19-D-8420
eFAST Contract#: DTFAWA-13-A-00074


-Original Message-
From: Mark Thomas  
Sent: Wednesday, July 5, 2023 12:59 PM
To: users@tomcat.apache.org
Subject: Re: Apache Tomcat request smuggling in 9.0.68?

Without knowing which vulnerability is being tested for and how the 
vulnerability is being tested for I don't think anyone here will be able to 
help.

A (cleartext) tcpdump of the associated request(s) and response(s) would also 
be helpful.

Mark


On 05/07/2023 17:51, James Boggs wrote:
> Hi,
> 
> We have Apache Tomcat 0.0.73 installed on a Windows Server 2019 o/s 
> which is has a Request Smuggling vulnerability being reported in a 
> BURP scan.
> 
> Here Tomcat documentation reports Request Smuggling has been fixed in 
> 9.0.68, so we don’t understand why it would still be reported using 9.0.73.
> 
> Any insights on this?
> 
> We have been told the proxy in use only supports HTTP1, so HTTP2 is 
> not an option.
> 
> V/r,
> 
> James Boggs | Senior DBA/SA | Mobile: 571-337-0535 /“Trust, Integrity, 
> Loyalty to Our Customers, Employees and Partner”/ */VA Verified 
> (SDVOSB)/* | */SBA Certified 8(a)/* | */SB/* | */SDB/* | */MBE/DBE 
> (MD)/* | */SWaM (VA)/*
> I*SO* 9001:2015|*ISO/IEC* 2-1:2018|*ISO/IEC* 27001:2013|
> *CMMI-DEV* Level 3 Appraised |
> 
> GSA Schedule Holder: IT-70#:GS35F237AA
> 
> GSA 8(a) STARS III#: 47QTCB21D0030
> 
> CIO-SP3 Contract#: HHSN316201800033W(SDVOSB)
> 
> CIO-SP3 Contract#: HHSN316201800054W(HUBZone)
> 
> Seaport-NXG Contract#: N00178-19-D-8420
> 
> eFAST Contract#: DTFAWA-13-A-00074
> 
> Fax: 410-814-7539 _|jbo...@rightdirectiontech.com 
> _
> 
> RightDirection Technology Solutions, LLC | 300 E. Lombard St Suite 840 
> | Baltimore, MD 21202|
> 
> www.rightdirectiontech.com 
> 
> Please Go Green! Please do not print this e-mail unless necessary.
> 
> 
> Notice of Confidentiality: This e-mail and any attachments thereto, 
> are intended only for use by the addressee(s) named herein and may 
> contain legally privileged and/or confidential information. If you are 
> 

Re: [mod_jk] Is it possible to set the value of a specific attribute via HTTP?

[Christopher Schultz]

Martin,

On 7/3/23 04:47, Martin Knoblauch wrote:

On 6/29/23 17:06, Rainer Jung wrote:



Since I try to push people into mod_proxy, I am hesitant to implement
more and more features which keep people from switching ;)




Hi Rainer,

  so, what do you suggest for the mod_jk retirement?
mod_proxy+mod_proxy_ajp, or just proxy to the HTTPS port?


You should consider whether you actually need a "real" reverse-proxy or 
if you can get away with "simple" load-balancing from a network balancer 
)i.e. one that doesn't know anything about HTTP).


If you still need one, I would recommend migrating from AJP -> HTTP(S). 
I have a whole talk about it: 
https://tomcat.apache.org/presentations.html#latest-migrate-ajp-http



Is there an
equivalent to jkmanager with mod_proxy?


Yes.

-chris

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

Re: [mod_jk] Is it possible to set the value of a specific attribute via HTTP?

[Christopher Schultz]

Jon,

On 6/30/23 17:21, jonmcalexan...@wellsfargo.com.INVALID wrote:

Hi Chris and Rainer,

Just want to add my .02 worth. Having the ability to "Drain" hosts in a Proxy 
configuration would be an awesome boon so you could gracefully take down a "node" for 
maintenance, or even just a restart. Then be able to put it back in action afterwards. :-) Of 
course, only in setups where you are using load-balancing and multiple back-end app servers. :-)


I have a presentation which covers how to do this, including references 
to automated tools to drain the servers, how to configure Tomcat to 
participate in that draining, etc.


It's this one from ApacheCon 2015: 
http://home.apache.org/~schultz/ApacheCon%20NA%202015/Load-balancing%20Tomcat%20with%20mod_jk.pdf


-chris


-Original Message-
From: Christopher Schultz 
Sent: Friday, June 30, 2023 2:19 PM
To: users@tomcat.apache.org
Subject: Re: [mod_jk] Is it possible to set the value of a specific attribute 
via
HTTP?

Rainer,

On 6/29/23 17:06, Rainer Jung wrote:

Hi Chris,

Am 29.06.23 um 15:00 schrieb Christopher Schultz:

All,

I've been using mod_jk forever and have some tools[1][2] to check on
the status of a worker and change its state using the status worker.

One of the samples I check is the "errors" count and if it's above 0
then I report an error to my monitoring system.

The problem is that sometimes we just get a random error here or
there, and my only recourse is to go into the status worker and
"reset" the worker which clears out everything. That may not be a big
deal because honestly I don't care what mod_jk thinks the estimated
number of sessions on a particular node is, but what I'd prefer to do
is bleed-off those errors over time.

For example, we check the service every few minutes. If we have more
than 0 errors, we start checking more frequently. If, every time we
checked, we reduced the error-count by some small number, the count
would eventually reach 0 if the event was temporary but it would
continue to grow as long as there was some kind of persistent error
(like Tomcat-node-is-down).

Is there a way to decrement the "errors" count without resetting all
counters back to zero?

Thanks,
-chris

[1] Hmm... I haven't put my check_mod_jk.py upon GitHub. I should do
that.
[2]


https://urldefense.com/v3/__https://github.com/ChristopherSchultz/apa

che-tomcat-

stuff/tree/master/bin/mod_jk__;!!F9svGWnIaVPGSwU!t6oVjPiPK



IiI1py49MyQzz_Jewu0_iQqa6xWLqEokHwNpzvlcQ2qAXIfGvhJsWTS34rA8tgC
_le50_

lUkwrMqUjevlf5d9KD$


no, there is no way to change insdividual runtime counters. As always
it would be possible to code it as an addition to the jk manager. One
would have to think about which counters for which workers (lb,
member, ajp) and whether one should be able to reset to 0, to adjust
by some delta or whatever.

I have not immediate intention to implement it, at this point just
wanted to mention it is not there but doable.


Thank you. I figured you would know best :)


Since I try to push people into mod_proxy, I am hesitant to implement
more and more features which keep people from switching ;)


I wouldn't suggest adding this to mod_jk for exactly the same reason.
But if the feature DID exist, I would have used it :)


The last feature I added was putting a request id on the log lines
(yet unreleased).


Does mod_proxy_balancer have this kind of thing? Does it sound like
something worth implementing? mod_jk's support for monitoring and live-
adjustments has always been better than mod_proxy_* IMHO but it is
catching up. Something like this would be very helpful addition.

-chris

-
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: Apache Tomcat request smuggling in 9.0.68?

[Mark Thomas]

Without knowing which vulnerability is being tested for and how the 
vulnerability is being tested for I don't think anyone here will be able 
to help.


A (cleartext) tcpdump of the associated request(s) and response(s) would 
also be helpful.


Mark


On 05/07/2023 17:51, James Boggs wrote:

Hi,

We have Apache Tomcat 0.0.73 installed on a Windows Server 2019 o/s 
which is has a Request Smuggling vulnerability being reported in a BURP 
scan.


Here Tomcat documentation reports Request Smuggling has been fixed in 
9.0.68, so we don’t understand why it would still be reported using 9.0.73.


Any insights on this?

We have been told the proxy in use only supports HTTP1, so HTTP2 is not 
an option.


V/r,

James Boggs | Senior DBA/SA | Mobile: 571-337-0535
/“Trust, Integrity, Loyalty to Our Customers, Employees and Partner”/
*/VA Verified (SDVOSB)/* | */SBA Certified 8(a)/* | */SB/* | */SDB/* | 
*/MBE/DBE (MD)/* | */SWaM (VA)/*

I*SO* 9001:2015|*ISO/IEC* 2-1:2018|*ISO/IEC* 27001:2013|
*CMMI-DEV* Level 3 Appraised |

GSA Schedule Holder: IT-70#:GS35F237AA

GSA 8(a) STARS III#: 47QTCB21D0030

CIO-SP3 Contract#: HHSN316201800033W(SDVOSB)

CIO-SP3 Contract#: HHSN316201800054W(HUBZone)

Seaport-NXG Contract#: N00178-19-D-8420

eFAST Contract#: DTFAWA-13-A-00074

Fax: 410-814-7539 _|jbo...@rightdirectiontech.com 
_


RightDirection Technology Solutions, LLC | 300 E. Lombard St Suite 840 | 
Baltimore, MD 21202|


www.rightdirectiontech.com 

Please Go Green! Please do not print this e-mail unless necessary.


Notice of Confidentiality: This e-mail and any attachments thereto, are 
intended only for use by the addressee(s) named herein and may contain 
legally privileged and/or confidential information. If you are not the 
intended recipient of this e-mail (or the person responsible for 
delivering this document to the intended recipient), you are hereby 
notified that any dissemination, distribution, printing or copying of 
this e-mail, and any attachment thereto, is strictly prohibited. If you 
have received this e-mail in error, please respond to the individual 
sending the message, and permanently delete the original and any copy of 
any e-mail and printout thereof.




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

Apache Tomcat request smuggling in 9.0.68?

[James Boggs]

Hi,

We have Apache Tomcat 0.0.73 installed on a Windows Server 2019 o/s which is 
has a Request Smuggling vulnerability being reported in a BURP scan.
Here Tomcat documentation reports Request Smuggling has been fixed in 9.0.68, 
so we don't understand why it would still be reported using 9.0.73.
Any insights on this?
We have been told the proxy in use only supports HTTP1, so HTTP2 is not an 
option.

V/r,

James Boggs | Senior DBA/SA | Mobile: 571-337-0535
"Trust, Integrity, Loyalty to Our Customers, Employees and Partner"
VA Verified (SDVOSB) | SBA Certified 8(a) | SB | SDB | MBE/DBE (MD) | SWaM (VA)
ISO 9001:2015|ISO/IEC 2-1:2018|ISO/IEC 27001:2013|
CMMI-DEV Level 3 Appraised |
GSA Schedule Holder: IT-70#:GS35F237AA
GSA 8(a) STARS III#: 47QTCB21D0030
CIO-SP3 Contract#: HHSN316201800033W(SDVOSB)
CIO-SP3 Contract#: HHSN316201800054W(HUBZone)
Seaport-NXG Contract#: N00178-19-D-8420
eFAST Contract#: DTFAWA-13-A-00074
[cid:image001.png@01D9AF3F.5DD6D0E0]
[cid:image002.png@01D9AF3F.5DD6D0E0]
Fax: 410-814-7539 
|jbo...@rightdirectiontech.com
RightDirection Technology Solutions, LLC | 300 E. Lombard St Suite 840 | 
Baltimore, MD 21202 |
www.rightdirectiontech.com

Please Go Green! Please do not print this e-mail unless necessary.

Notice of Confidentiality: This e-mail and any attachments thereto, are 
intended only for use by the addressee(s) named herein and may contain legally 
privileged and/or confidential information. If you are not the intended 
recipient of this e-mail (or the person responsible for delivering this 
document to the intended recipient), you are hereby notified that any 
dissemination, distribution, printing or copying of this e-mail, and any 
attachment thereto, is strictly prohibited. If you have received this e-mail in 
error, please respond to the individual sending the message, and permanently 
delete the original and any copy of any e-mail and printout thereof.