Re: At wits end: Difficulties with IIS ISAPI connector and Tomcat

[Ellen Meiselman]

Wow, I think I’ve gotten more help in 10 minutes from this users group than in 
2 weeks from anywhere else I’ve tried.

 I’ll try to respond as quickly as I can but I want  to test your various 
suggestions, so it might be tomorrow before I can do them justice.

Thank you all so much!
Ellen Meiselman
elle...@gmail.com



> On Feb 24, 2020, at 3:42 PM, Mark Thomas  wrote:
> 
> On 24/02/2020 20:19, Ellen Meiselman wrote:
>> Hi, 
>> 
>> I’m having a lot of trouble configuring the isapi_redirect connector between 
>> IIS and Tomcat. I am running out of ideas so it’s time to ask for help from 
>> the experts. I think the problems remaining are in the tomcat configuration 
>> area, not the IIS area anymore. 
>> 
>> What’s wrong: 
>> The ISAPI module appears to be working and correctly sending AJP requests to 
>> Tomcat on port 8009, at which point Tomcat refuses those requests with a 403 
>> error. The isapi_redirect.log shows the complete content of the tomcat 
>> response, and no longer shows any errors - in other words, it thinks it is 
>> working.
> 
> I'd agree. If you see a response back from Tomcat then IIS is working.
> 
> You should also see an entry in the access log.
> 
>> Text of the 403 error:
>> 
>> HTTP Status 403 – Forbidden
>> Type Status Report
>> Description The server understood the request but refuses to authorize 
>> it.
>> Apache Tomcat/8.5.51 
> 
> OK. That also indicates that IIS is passing the request to Tomcat
> correctly processing the response.
> 
> 
> 
>> This Windows 2019 setup has the following versions of tomcat, windows, etc:
>> 
>> Tomcat version 8.5.51
>> Isapi_redirect.dll version 1.2.46.0
>> IIS 10/Windows server 2019
> 
> Thank you. It really helps when people provide that information. It
> saves a lot of time.
> 
> 
> 
>> My theories at the moment:
>> 1. Maybe allowedRequestAttributesPattern is a problem? I saw a note about 
>> the allowedRequestAttributesPattern attribute for the AJP connector possibly 
>> causing a 403 error, but I don’t understand how to use it or if it is needed.
>> 2. It’s possible that something in the Tomcat permissions settings are 
>> wrong, but I really don’t know where to look.
> 
> You shouldn't need to set allowedRequestAttributesPattern.
> 
> I think it might be Tomcat configuration. Any again, very helpfully, we
> have ...
> 
>> Relevant configuration settings in server.xml, workers.properties and 
>> uriworkermap.properties:
>> 
>> server.xml  
>> 
>>> redirectPort="8443" />
>>> requiredSecret="true"  secret=“" redirectPort="8443" /> 
>> 
>> > autoDeploy="true">   
>>> directory="logs"
>>   prefix="localhost_access_log" suffix=".txt"
>>   pattern="%h %l %u %t %r %s %b" />
>>  
>> 
>> > autoDeploy="true"> 
>>  > directory="logs"
>>  prefix="127_0_01_access_log" suffix=".txt"
>>  pattern="%h %l %u %t %r %s %b" />
>>   
>> 
>> 
>> workers.properties 
>> 
>> # Set properties for worker1 (ajp13)
>> worker.worker1.type=ajp13
>> worker.worker1.host=127.0.0.1
>> worker.worker1.port=8009
>> worker.worker1.secret=
>> 
>> 
>> uriworkermap.properties  
>> /exposedApplication/*=worker1
>> 
>> 
>> Any suggestions or new directions will be welcome.
> 
> My best guess would be that the value for secret is not the same between
> workers.properties and Tomcat.
> 
> I have a 2019 server test environment. I'll try and replicate what you
> have with a clean 8.5.51 install and the examples application and see
> what happens.
> 
> 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: At wits end: Difficulties with IIS ISAPI connector and Tomcat

[jonmcalexander]

-Original Message-
From: André Warnier (tomcat/perl)  
Sent: Monday, February 24, 2020 3:33 PM
To: users@tomcat.apache.org
Subject: Re: At wits end: Difficulties with IIS ISAPI connector and Tomcat

On 24.02.2020 22:04, Christopher Schultz wrote:
> With 8.5.51, requiredSecret is renamed "secret" but "requiredSecret"
> is still an alias of the same configuration property. If #2 happens 
> after #1 above, then your actual secret will be the literal string 
> "true" (oops).
> 
> We apologize for this confusion. We are trying to clarify things and 
> make them more secure.

> Nobody is saying that the new configuration and attributes are not better, 
> from a security point of > view. The latest on-line documentation, when taken 
> in isolation, is also pretty clear and understandable. So people installing 
> tomcat for the first time should have no problem.

> But I think that quite a few recent posts show that these changes could have 
> been made a bit more > visible for people who have running tomcats, and are 
> just updating from one minor version to the > next minor version.
> Even the on-line documentation for the Connector, shows the current 
> attributes and defaults, but > without any mention that they have just 
> changed compared to the previous minor version. That has apparently caught a 
> lot of people unaware.

> Now how to make this more noticeable, without also alerting the bad guys 
> about the pre-existing vulnerabilities, is probably not so easy..

> How about adding a note on top of the migration guide pages, saying : "If you 
> are just updating from 8.5.50 or lower, to 8.5.51 or higher, you *really* 
> should look at the AJP Connector attributes again".

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

My .02 worth,

I would think that the configuration change would be on the Tomcat side, not 
the ISAPI Connector side as a new version of the Connector wasn't released, so 
everything would stay the same on the IIS side. Only the info in the server.xml 
would change, i.e. RequiredSecret to Secret, etc.

Thanks,


Dream * Excel * Explore * Inspire
Jon McAlexander
Asst Vice President

Middleware Product Engineering
Enterprise CIO | Platform Services | Middleware | Infrastructure Solutions

Upcoming PTO: 11/8, 11/11, 11/15, 11/22, 11/28, 11/29, 12/2, 12/6, 12/13, 12/20 
– 12/31

8080 Cobblestone Rd | Urbandale, IA 50322
MAC: F4469-010
Tel 515-988-2508 | Cell 515-988-2508

jonmcalexan...@wellsfargo.com


This message may contain confidential and/or privileged information. If you are 
not the addressee or authorized to receive this for the addressee, you must not 
use, copy, disclose, or take any action based on this message or any 
information herein. If you have received this message in error, please advise 
the sender immediately by reply e-mail and delete this message. Thank you for 
your cooperation.

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

Re: At wits end: Difficulties with IIS ISAPI connector and Tomcat

[tomcat/perl]

On 24.02.2020 22:04, Christopher Schultz wrote:

With 8.5.51, requiredSecret is renamed "secret" but "requiredSecret"
is still an alias of the same configuration property. If #2 happens
after #1 above, then your actual secret will be the literal string
"true" (oops).

We apologize for this confusion. We are trying to clarify things and
make them more secure.


Nobody is saying that the new configuration and attributes are not better, from a security 
point of view. The latest on-line documentation, when taken in isolation, is also pretty 
clear and understandable. So people installing tomcat for the first time should have no 
problem.


But I think that quite a few recent posts show that these changes could have been made a 
bit more visible for people who have running tomcats, and are just updating from one minor 
version to the next minor version.
Even the on-line documentation for the Connector, shows the current attributes and 
defaults, but without any mention that they have just changed compared to the previous 
minor version. That has apparently caught a lot of people unaware.


Now how to make this more noticeable, without also alerting the bad guys about the 
pre-existing vulnerabilities, is probably not so easy..


How about adding a note on top of the migration guide pages, saying : "If you are just 
updating from 8.5.50 or lower, to 8.5.51 or higher, you *really* should look at the AJP 
Connector attributes again".


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

Re: At wits end: Difficulties with IIS ISAPI connector and Tomcat

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Chris,

On 2/24/20 15:53, Chris Cheshire wrote:
> On Mon, Feb 24, 2020 at 3:19 PM Ellen Meiselman 
> wrote:
>>
>> Hi,
>>
>> I’m having a lot of trouble configuring the isapi_redirect
>> connector between IIS and Tomcat. I am running out of ideas so
>> it’s time to ask for help from the experts. I think the problems
>> remaining are in the tomcat configuration area, not the IIS area
>> anymore.
>>
>> What’s wrong: The ISAPI module appears to be working and
>> correctly sending AJP requests to Tomcat on port 8009, at which
>> point Tomcat refuses those requests with a 403 error. The
>> isapi_redirect.log shows the complete content of the tomcat
>> response, and no longer shows any errors - in other words, it
>> thinks it is working.
>>
>> Text of the 403 error:
>>
>> HTTP Status 403 – Forbidden Type Status Report Description The
>> server understood the request but refuses to authorize it. Apache
>> Tomcat/8.5.51
>>
>>
>> What does work: Requests directly to Tomcat on port 8080 to pages
>> within the connector-exposed web application work fine. For
>> example, both of these work:
>> localhost:8080/exposedApplication/simple.html. (viewed on the
>> server’s browser)
>> my.servers.domain.com:8080/exposedApplication/simple.html (viewed
>> anywhere else)
>>
>>
>> What does not work: Requests that go through IIS and the
>> connector to the connector-exposed application result in a 403
>> error. For example, this does not work:
>> https:my.servers.domain.com/exposedApplication/simple.html
>>
>>
>> This Windows 2019 setup has the following versions of tomcat,
>> windows, etc:
>>
>> Tomcat version 8.5.51 Isapi_redirect.dll version 1.2.46.0 IIS
>> 10/Windows server 2019
>>
>> I also have two older, similar Windows Server environments that
>> work perfectly. They both use these versions:
>>
>> Tomcat version 8.5.3 (64 bit) as a service Isapi_redirect.dll
>> version 1.2.40.0 64 bit IIS 8/Windows server 2012R2
>>
>>
>> The component versions between the working and non-working
>> environments are slightly different, and I think that might be
>> the source of the problem - there are probably new configuration
>> requirements that I need to be aware of. I started with the
>> settings used in the working environments and found that some
>> things needed to be changed to get the connector to work at alll.
>> For example I had to specify an iPv4 address for the connector
>> where I didn’t need to before.
>>
>> My theories at the moment: 1. Maybe
>> allowedRequestAttributesPattern is a problem? I saw a note about
>> the allowedRequestAttributesPattern attribute for the AJP
>> connector possibly causing a 403 error, but I don’t understand
>> how to use it or if it is needed. 2. It’s possible that something
>> in the Tomcat permissions settings are wrong, but I really don’t
>> know where to look.
>>
>>
>> Relevant configuration settings in server.xml, workers.properties
>> and uriworkermap.properties:
>>
>> server.xml
>>
>>  > protocol="AJP/1.3”  address=“127.0.0.1" port="8009"
>> requiredSecret="true"  secret=“" redirectPort="8443" />
>>
>> > autoDeploy="true"> > className="org.apache.catalina.valves.AccessLogValve"
>> directory="logs" prefix="localhost_access_log" suffix=".txt"
>> pattern="%h %l %u %t %r %s %b" /> 
>>
>> > autoDeploy="true"> > className="org.apache.catalina.valves.AccessLogValve"
>> directory="logs" prefix="127_0_01_access_log" suffix=".txt"
>> pattern="%h %l %u %t %r %s %b" /> 
>>
>>
>> workers.properties
>>
>> # Set properties for worker1 (ajp13) worker.worker1.type=ajp13
>> worker.worker1.host=127.0.0.1 worker.worker1.port=8009
>> worker.worker1.secret=
>>
>>
>> uriworkermap.properties /exposedApplication/*=worker1
>>
>>
>> Any suggestions or new directions will be welcome.
>>
>> Thank you,
>>
>> Ellen Meiselman
>>
>
> Change requiredSecret="true" to secretRequired="true" in your AJP
> connector definition.

+1

These configuration attributes have names which are easily confused.

In the past, "requiredSecret" was the name of the configuration
property where the secret should have been set (e.g.
requiredSecret="tiger"). In Tomcat 8.5.51, this configuration
attribute changed to "secret" and the boolean "secretRequired"
attribute was added. So you need:

secretRequired="true" (which is the default, so it can be removed)
secret="xxx"

If you use requiredSecret="true" then it's very possible that the XML
parser will fire these two events (in this order):

1: attribute [ name=secret value=x ]
2: attribute [ name=requiredSecret value=true ]

With 8.5.51, requiredSecret is renamed "secret" but "requiredSecret"
is still an alias of the same configuration property. If #2 happens
after #1 above, then your actual secret will be the literal string
"true" (oops).

We apologize for this confusion. We are trying to clarify things and
make them more secure.

- -chris
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - 

Re: At wits end: Difficulties with IIS ISAPI connector and Tomcat

[Mark Thomas]

On 24/02/2020 20:53, Chris Cheshire wrote:
> On Mon, Feb 24, 2020 at 3:19 PM Ellen Meiselman  wrote:
>>
>> Hi,
>>
>> I’m having a lot of trouble configuring the isapi_redirect connector between 
>> IIS and Tomcat. I am running out of ideas so it’s time to ask for help from 
>> the experts. I think the problems remaining are in the tomcat configuration 
>> area, not the IIS area anymore.
>>
>> What’s wrong:
>> The ISAPI module appears to be working and correctly sending AJP requests to 
>> Tomcat on port 8009, at which point Tomcat refuses those requests with a 403 
>> error. The isapi_redirect.log shows the complete content of the tomcat 
>> response, and no longer shows any errors - in other words, it thinks it is 
>> working.
>>
>> Text of the 403 error:
>>
>>  HTTP Status 403 – Forbidden
>>  Type Status Report
>>  Description The server understood the request but refuses to authorize 
>> it.
>>  Apache Tomcat/8.5.51
>>
>>
>> What does work:
>> Requests directly to Tomcat on port 8080 to pages within the 
>> connector-exposed web application work fine.
>> For example, both of these work:
>> localhost:8080/exposedApplication/simple.html. (viewed on the server’s 
>> browser)
>> my.servers.domain.com:8080/exposedApplication/simple.html (viewed anywhere 
>> else)
>>
>>
>> What does not work:
>> Requests that go through IIS and the connector to the connector-exposed 
>> application result in a 403 error.
>> For example, this does not work:
>> https:my.servers.domain.com/exposedApplication/simple.html
>>
>>
>> This Windows 2019 setup has the following versions of tomcat, windows, etc:
>>
>> Tomcat version 8.5.51
>> Isapi_redirect.dll version 1.2.46.0
>> IIS 10/Windows server 2019
>>
>> I also have two older, similar Windows Server environments that work 
>> perfectly. They both use these versions:
>>
>> Tomcat version 8.5.3 (64 bit) as a service
>> Isapi_redirect.dll version 1.2.40.0 64 bit
>> IIS 8/Windows server 2012R2
>>
>>
>> The component versions between the working and non-working environments are 
>> slightly different, and I think that might be the source of the problem - 
>> there are probably new configuration requirements that I need to be aware 
>> of. I started with the settings used in the working environments and found 
>> that some things needed to be changed to get the connector to work at alll. 
>> For example I had to specify an iPv4 address for the connector where I 
>> didn’t need to before.
>>
>> My theories at the moment:
>> 1. Maybe allowedRequestAttributesPattern is a problem? I saw a note about 
>> the allowedRequestAttributesPattern attribute for the AJP connector possibly 
>> causing a 403 error, but I don’t understand how to use it or if it is needed.
>> 2. It’s possible that something in the Tomcat permissions settings are 
>> wrong, but I really don’t know where to look.
>>
>>
>> Relevant configuration settings in server.xml, workers.properties and 
>> uriworkermap.properties:
>>
>> server.xml
>>
>> > redirectPort="8443" />
>> > requiredSecret="true"  secret=“" redirectPort="8443" />
>>
>>  > autoDeploy="true">
>> > directory="logs"
>>prefix="localhost_access_log" suffix=".txt"
>>pattern="%h %l %u %t %r %s %b" />
>>   
>>
>>  > autoDeploy="true">
>> > directory="logs"
>> prefix="127_0_01_access_log" suffix=".txt"
>> pattern="%h %l %u %t %r %s %b" />
>>  
>>
>>
>> workers.properties
>>
>> # Set properties for worker1 (ajp13)
>> worker.worker1.type=ajp13
>> worker.worker1.host=127.0.0.1
>> worker.worker1.port=8009
>> worker.worker1.secret=
>>
>>
>> uriworkermap.properties
>> /exposedApplication/*=worker1
>>
>>
>> Any suggestions or new directions will be welcome.
>>
>> Thank you,
>>
>> Ellen Meiselman
>>
> 
> Change requiredSecret="true" to secretRequired="true" in your AJP
> connector definition.

Well spotted Chris. I'd missed that.

requiredSecret==secret

The order attributes are processed in is not always the order in which
they are defined. The value of secret is probably being over-written
with "true".

Mark

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

Re: At wits end: Difficulties with IIS ISAPI connector and Tomcat

[Chris Cheshire]

On Mon, Feb 24, 2020 at 3:19 PM Ellen Meiselman  wrote:
>
> Hi,
>
> I’m having a lot of trouble configuring the isapi_redirect connector between 
> IIS and Tomcat. I am running out of ideas so it’s time to ask for help from 
> the experts. I think the problems remaining are in the tomcat configuration 
> area, not the IIS area anymore.
>
> What’s wrong:
> The ISAPI module appears to be working and correctly sending AJP requests to 
> Tomcat on port 8009, at which point Tomcat refuses those requests with a 403 
> error. The isapi_redirect.log shows the complete content of the tomcat 
> response, and no longer shows any errors - in other words, it thinks it is 
> working.
>
> Text of the 403 error:
>
>  HTTP Status 403 – Forbidden
>  Type Status Report
>  Description The server understood the request but refuses to authorize 
> it.
>  Apache Tomcat/8.5.51
>
>
> What does work:
> Requests directly to Tomcat on port 8080 to pages within the 
> connector-exposed web application work fine.
> For example, both of these work:
> localhost:8080/exposedApplication/simple.html. (viewed on the server’s 
> browser)
> my.servers.domain.com:8080/exposedApplication/simple.html (viewed anywhere 
> else)
>
>
> What does not work:
> Requests that go through IIS and the connector to the connector-exposed 
> application result in a 403 error.
> For example, this does not work:
> https:my.servers.domain.com/exposedApplication/simple.html
>
>
> This Windows 2019 setup has the following versions of tomcat, windows, etc:
>
> Tomcat version 8.5.51
> Isapi_redirect.dll version 1.2.46.0
> IIS 10/Windows server 2019
>
> I also have two older, similar Windows Server environments that work 
> perfectly. They both use these versions:
>
> Tomcat version 8.5.3 (64 bit) as a service
> Isapi_redirect.dll version 1.2.40.0 64 bit
> IIS 8/Windows server 2012R2
>
>
> The component versions between the working and non-working environments are 
> slightly different, and I think that might be the source of the problem - 
> there are probably new configuration requirements that I need to be aware of. 
> I started with the settings used in the working environments and found that 
> some things needed to be changed to get the connector to work at alll. For 
> example I had to specify an iPv4 address for the connector where I didn’t 
> need to before.
>
> My theories at the moment:
> 1. Maybe allowedRequestAttributesPattern is a problem? I saw a note about the 
> allowedRequestAttributesPattern attribute for the AJP connector possibly 
> causing a 403 error, but I don’t understand how to use it or if it is needed.
> 2. It’s possible that something in the Tomcat permissions settings are wrong, 
> but I really don’t know where to look.
>
>
> Relevant configuration settings in server.xml, workers.properties and 
> uriworkermap.properties:
>
> server.xml
>
>  redirectPort="8443" />
>  requiredSecret="true"  secret=“" redirectPort="8443" />
>
>   autoDeploy="true">
>  directory="logs"
>prefix="localhost_access_log" suffix=".txt"
>pattern="%h %l %u %t %r %s %b" />
>   
>
>   autoDeploy="true">
>  directory="logs"
> prefix="127_0_01_access_log" suffix=".txt"
> pattern="%h %l %u %t %r %s %b" />
>  
>
>
> workers.properties
>
> # Set properties for worker1 (ajp13)
> worker.worker1.type=ajp13
> worker.worker1.host=127.0.0.1
> worker.worker1.port=8009
> worker.worker1.secret=
>
>
> uriworkermap.properties
> /exposedApplication/*=worker1
>
>
> Any suggestions or new directions will be welcome.
>
> Thank you,
>
> Ellen Meiselman
>

Change requiredSecret="true" to secretRequired="true" in your AJP
connector definition.

HTH

Chris

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

Re: At wits end: Difficulties with IIS ISAPI connector and Tomcat

[Mark Thomas]

On 24/02/2020 20:44, calder wrote:
> On Mon, Feb 24, 2020, 14:19 Ellen Meiselman  wrote:
> 
>> Hi,
>>
>> I’m having a lot of trouble configuring the isapi_redirect connector
>> between IIS and Tomcat. I am running out of ideas so it’s time to ask for
>> help from the experts. I think the problems remaining are in the tomcat
>> configuration area, not the IIS area anymore.
>>
>> What’s wrong:
>> The ISAPI module appears to be working and correctly sending AJP requests
>> to Tomcat on port 8009, at which point Tomcat refuses those requests with a
>> 403 error. The isapi_redirect.log shows the complete content of the tomcat
>> response, and no longer shows any errors - in other words, it thinks it is
>> working.
>>
>> Text of the 403 error:
>>
>>  HTTP Status 403 – Forbidden
>>  Type Status Report
>>  Description The server understood the request but refuses to
>> authorize it.
>>  Apache Tomcat/8.5.51
>>
> 
> 
> Is IIS returning the 403?  If yes, we should see a "dot error" number, such
> as 403.1 or 403.2, and so on.

All the evidence indicates that Tomcat, not IIS, is generating the 403
so the user will see a "proper" 403 rather than one of the IIS variants.

> What does work:
>> Requests directly to Tomcat on port 8080 to pages within the
>> connector-exposed web application work fine.
>> For example, both of these work:
>> localhost:8080/exposedApplication/simple.html. (viewed on the server’s
>> browser)
>> my.servers.domain.com:8080/exposedApplication/simple.html (viewed
>> anywhere else)
>>
>>
>> What does not work:
>> Requests that go through IIS and the connector to the connector-exposed
>> application result in a 403 error.
>> For example, this does not work:
>> https:my.servers.domain.com/exposedApplication/simple.html
>>
>>
>> This Windows 2019 setup has the following versions of tomcat, windows, etc:
>>
>> Tomcat version 8.5.51
>> Isapi_redirect.dll version 1.2.46.0
>> IIS 10/Windows server 2019
>>
>> I also have two older, similar Windows Server environments that work
>> perfectly. They both use these versions:
>>
>> Tomcat version 8.5.3 (64 bit) as a service
>> Isapi_redirect.dll version 1.2.40.0 64 bit
>> IIS 8/Windows server 2012R2
>>
>>
>> The component versions between the working and non-working environments
>> are slightly different, and I think that might be the source of the problem
>> - there are probably new configuration requirements that I need to be aware
>> of. I started with the settings used in the working environments and found
>> that some things needed to be changed to get the connector to work at alll.
>> For example I had to specify an iPv4 address for the connector where I
>> didn’t need to before.
>>
>> My theories at the moment:
>> 1. Maybe allowedRequestAttributesPattern is a problem? I saw a note about
>> the allowedRequestAttributesPattern attribute for the AJP connector
>> possibly causing a 403 error, but I don’t understand how to use it or if it
>> is needed.
>> 2. It’s possible that something in the Tomcat permissions settings are
>> wrong, but I really don’t know where to look.
>>
>>
>> Relevant configuration settings in server.xml, workers.properties and
>> uriworkermap.properties:
>>
>> server.xml
>>
>> > redirectPort="8443" />
>> > requiredSecret="true"  secret=“" redirectPort="8443" />
>>
>>  > autoDeploy="true">
>> > directory="logs"
>>prefix="localhost_access_log" suffix=".txt"
>>pattern="%h %l %u %t %r %s %b" />
>>   
>>
>>  > autoDeploy="true">
>> > directory="logs"
>> prefix="127_0_01_access_log" suffix=".txt"
>> pattern="%h %l %u %t %r %s %b" />
>>  
>>
>>
>> workers.properties
>>
>> # Set properties for worker1 (ajp13)
>> worker.worker1.type=ajp13
>> worker.worker1.host=127.0.0.1
>> worker.worker1.port=8009
>> worker.worker1.secret=
>>
>> uriworkermap.properties
>> /exposedApplication/*=worker1
>>
>> Any suggestions or new directions will be welcome.
>>
> 
> 
> A full stack trace (including any "caused by" statements)  from Tomcat
> *and*  IIS would be helpful.

There won't be any.

Mark

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

Re: At wits end: Difficulties with IIS ISAPI connector and Tomcat

[calder]

On Mon, Feb 24, 2020, 14:19 Ellen Meiselman  wrote:

> Hi,
>
> I’m having a lot of trouble configuring the isapi_redirect connector
> between IIS and Tomcat. I am running out of ideas so it’s time to ask for
> help from the experts. I think the problems remaining are in the tomcat
> configuration area, not the IIS area anymore.
>
> What’s wrong:
> The ISAPI module appears to be working and correctly sending AJP requests
> to Tomcat on port 8009, at which point Tomcat refuses those requests with a
> 403 error. The isapi_redirect.log shows the complete content of the tomcat
> response, and no longer shows any errors - in other words, it thinks it is
> working.
>
> Text of the 403 error:
>
>  HTTP Status 403 – Forbidden
>  Type Status Report
>  Description The server understood the request but refuses to
> authorize it.
>  Apache Tomcat/8.5.51
>


Is IIS returning the 403?  If yes, we should see a "dot error" number, such
as 403.1 or 403.2, and so on.


What does work:
> Requests directly to Tomcat on port 8080 to pages within the
> connector-exposed web application work fine.
> For example, both of these work:
> localhost:8080/exposedApplication/simple.html. (viewed on the server’s
> browser)
> my.servers.domain.com:8080/exposedApplication/simple.html (viewed
> anywhere else)
>
>
> What does not work:
> Requests that go through IIS and the connector to the connector-exposed
> application result in a 403 error.
> For example, this does not work:
> https:my.servers.domain.com/exposedApplication/simple.html
>
>
> This Windows 2019 setup has the following versions of tomcat, windows, etc:
>
> Tomcat version 8.5.51
> Isapi_redirect.dll version 1.2.46.0
> IIS 10/Windows server 2019
>
> I also have two older, similar Windows Server environments that work
> perfectly. They both use these versions:
>
> Tomcat version 8.5.3 (64 bit) as a service
> Isapi_redirect.dll version 1.2.40.0 64 bit
> IIS 8/Windows server 2012R2
>
>
> The component versions between the working and non-working environments
> are slightly different, and I think that might be the source of the problem
> - there are probably new configuration requirements that I need to be aware
> of. I started with the settings used in the working environments and found
> that some things needed to be changed to get the connector to work at alll.
> For example I had to specify an iPv4 address for the connector where I
> didn’t need to before.
>
> My theories at the moment:
> 1. Maybe allowedRequestAttributesPattern is a problem? I saw a note about
> the allowedRequestAttributesPattern attribute for the AJP connector
> possibly causing a 403 error, but I don’t understand how to use it or if it
> is needed.
> 2. It’s possible that something in the Tomcat permissions settings are
> wrong, but I really don’t know where to look.
>
>
> Relevant configuration settings in server.xml, workers.properties and
> uriworkermap.properties:
>
> server.xml
>
>  redirectPort="8443" />
>  requiredSecret="true"  secret=“" redirectPort="8443" />
>
>   autoDeploy="true">
>  directory="logs"
>prefix="localhost_access_log" suffix=".txt"
>pattern="%h %l %u %t %r %s %b" />
>   
>
>   autoDeploy="true">
>  directory="logs"
> prefix="127_0_01_access_log" suffix=".txt"
> pattern="%h %l %u %t %r %s %b" />
>  
>
>
> workers.properties
>
> # Set properties for worker1 (ajp13)
> worker.worker1.type=ajp13
> worker.worker1.host=127.0.0.1
> worker.worker1.port=8009
> worker.worker1.secret=
>
> uriworkermap.properties
> /exposedApplication/*=worker1
>
> Any suggestions or new directions will be welcome.
>


A full stack trace (including any "caused by" statements)  from Tomcat
*and*  IIS would be helpful.

>

Re: At wits end: Difficulties with IIS ISAPI connector and Tomcat

[Mark Thomas]

On 24/02/2020 20:19, Ellen Meiselman wrote:
> Hi, 
> 
> I’m having a lot of trouble configuring the isapi_redirect connector between 
> IIS and Tomcat. I am running out of ideas so it’s time to ask for help from 
> the experts. I think the problems remaining are in the tomcat configuration 
> area, not the IIS area anymore. 
> 
> What’s wrong: 
> The ISAPI module appears to be working and correctly sending AJP requests to 
> Tomcat on port 8009, at which point Tomcat refuses those requests with a 403 
> error. The isapi_redirect.log shows the complete content of the tomcat 
> response, and no longer shows any errors - in other words, it thinks it is 
> working.

I'd agree. If you see a response back from Tomcat then IIS is working.

You should also see an entry in the access log.

> Text of the 403 error:
> 
>  HTTP Status 403 – Forbidden
>  Type Status Report
>  Description The server understood the request but refuses to authorize 
> it.
>  Apache Tomcat/8.5.51 

OK. That also indicates that IIS is passing the request to Tomcat
correctly processing the response.



> This Windows 2019 setup has the following versions of tomcat, windows, etc:
>  
> Tomcat version 8.5.51
> Isapi_redirect.dll version 1.2.46.0
> IIS 10/Windows server 2019

Thank you. It really helps when people provide that information. It
saves a lot of time.



> My theories at the moment:
> 1. Maybe allowedRequestAttributesPattern is a problem? I saw a note about the 
> allowedRequestAttributesPattern attribute for the AJP connector possibly 
> causing a 403 error, but I don’t understand how to use it or if it is needed.
> 2. It’s possible that something in the Tomcat permissions settings are wrong, 
> but I really don’t know where to look.

You shouldn't need to set allowedRequestAttributesPattern.

I think it might be Tomcat configuration. Any again, very helpfully, we
have ...

> Relevant configuration settings in server.xml, workers.properties and 
> uriworkermap.properties:
> 
> server.xml  
> 
>  redirectPort="8443" />
>  requiredSecret="true"  secret=“" redirectPort="8443" /> 
>  
>   autoDeploy="true">   
>  directory="logs"
>prefix="localhost_access_log" suffix=".txt"
>pattern="%h %l %u %t %r %s %b" />
>   
> 
>   autoDeploy="true"> 
>directory="logs"
>   prefix="127_0_01_access_log" suffix=".txt"
>   pattern="%h %l %u %t %r %s %b" />
>
> 
> 
> workers.properties 
> 
> # Set properties for worker1 (ajp13)
> worker.worker1.type=ajp13
> worker.worker1.host=127.0.0.1
> worker.worker1.port=8009
> worker.worker1.secret=
> 
> 
> uriworkermap.properties  
> /exposedApplication/*=worker1
> 
> 
> Any suggestions or new directions will be welcome.

My best guess would be that the value for secret is not the same between
workers.properties and Tomcat.

I have a 2019 server test environment. I'll try and replicate what you
have with a clean 8.5.51 install and the examples application and see
what happens.

Mark

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

At wits end: Difficulties with IIS ISAPI connector and Tomcat

[Ellen Meiselman]

Hi, 

I’m having a lot of trouble configuring the isapi_redirect connector between 
IIS and Tomcat. I am running out of ideas so it’s time to ask for help from the 
experts. I think the problems remaining are in the tomcat configuration area, 
not the IIS area anymore. 

What’s wrong: 
The ISAPI module appears to be working and correctly sending AJP requests to 
Tomcat on port 8009, at which point Tomcat refuses those requests with a 403 
error. The isapi_redirect.log shows the complete content of the tomcat 
response, and no longer shows any errors - in other words, it thinks it is 
working.

Text of the 403 error:

 HTTP Status 403 – Forbidden
 Type Status Report
 Description The server understood the request but refuses to authorize it.
 Apache Tomcat/8.5.51 


What does work: 
Requests directly to Tomcat on port 8080 to pages within the connector-exposed 
web application work fine. 
For example, both of these work:
localhost:8080/exposedApplication/simple.html. (viewed on the server’s browser)
my.servers.domain.com:8080/exposedApplication/simple.html (viewed anywhere else)


What does not work:
Requests that go through IIS and the connector to the connector-exposed 
application result in a 403 error.
For example, this does not work:
https:my.servers.domain.com/exposedApplication/simple.html


This Windows 2019 setup has the following versions of tomcat, windows, etc:
 
Tomcat version 8.5.51
Isapi_redirect.dll version 1.2.46.0
IIS 10/Windows server 2019

I also have two older, similar Windows Server environments that work perfectly. 
They both use these versions:

Tomcat version 8.5.3 (64 bit) as a service
Isapi_redirect.dll version 1.2.40.0 64 bit
IIS 8/Windows server 2012R2


The component versions between the working and non-working environments are 
slightly different, and I think that might be the source of the problem - there 
are probably new configuration requirements that I need to be aware of. I 
started with the settings used in the working environments and found that some 
things needed to be changed to get the connector to work at alll. For example I 
had to specify an iPv4 address for the connector where I didn’t need to before.

My theories at the moment:
1. Maybe allowedRequestAttributesPattern is a problem? I saw a note about the 
allowedRequestAttributesPattern attribute for the AJP connector possibly 
causing a 403 error, but I don’t understand how to use it or if it is needed.
2. It’s possible that something in the Tomcat permissions settings are wrong, 
but I really don’t know where to look.  


Relevant configuration settings in server.xml, workers.properties and 
uriworkermap.properties:

server.xml  


 
 


  

  

   


workers.properties 

# Set properties for worker1 (ajp13)
worker.worker1.type=ajp13
worker.worker1.host=127.0.0.1
worker.worker1.port=8009
worker.worker1.secret=


uriworkermap.properties  
/exposedApplication/*=worker1


Any suggestions or new directions will be welcome. 

Thank you, 

Ellen Meiselman

 



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

Re: Novice Tomcat Admin Question - Filtering log output

[Darryl Philip Baker]

>   > The second reason is we use Splunk as a log aggregator. In Splunk

>> it is easy to filter these out when looking at the log but having

>> all these almost useless messages significantly adds to the

>> activity of the Splunk forwarder on these systems.

>I'm surprised Splunk doesn't have a "drop records matching pattern" or

>something like that, so you can just never ingest them. Maybe that

>would be a feature too easy to exploit.



Chris, that is a great idea. I don't control the aggregator and that may be 
where a filter might be configured. I will check.



Darryl Baker, GSEC  (he/him/his)

Sr. System Administrator

Distributed Application Platform Services

Northwestern University

1800 Sherman Ave.

Suite 6-600 – Box #39

Evanston, IL  60201-3715

darryl.ba...@northwestern.edu

(847) 467-6674

Re: Novice Tomcat Admin Question - Filtering log output

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256


Darryl,

On 2/21/20 12:49, Darryl Philip Baker wrote:
> On 2/21/20, 11:36 AM, "Christopher Schultz"
>  wrote:
>
> -BEGIN PGP SIGNED MESSAGE- Hash: SHA256
>
> Darryl,
>
> On 2/21/20 12:15, Darryl Philip Baker wrote:
>> I have taken over the administration of several Tomcat
>> instances. A number of these are load balanced using an F5
>> appliance.  The org.apache.catalina.values.AccessLogValve log
>> file is filled with the F5 polls to see if the application is
>> alive. Under almost all circumstances these are useless, I would
>> like to stop logging just these requests.
> Dumb question: why bother removing them?
>
> Not so dumb a question, I have 2 reasons. First when looking at
> the raw file on the server these poles from the load balancers make
> it hard to find the useful entries.

grep?

> The second reason is we use Splunk as a log aggregator. In Splunk
> it is easy to filter these out when looking at the log but having
> all these almost useless messages significantly adds to the
> activity of the Splunk forwarder on these systems.
I'm surprised Splunk doesn't have a "drop records matching pattern" or
something like that, so you can just never ingest them. Maybe that
would be a feature too easy to exploit.

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl5T6dEACgkQHPApP6U8
pFg1SA/9Gl05+KgkrmgwKcbcGKf+KgFCaWALn9ui29CdtwBwES9dMVbxDaKppOMg
ElQKuGIJt0xjqoL/kBRSaNXPWhB2rst9dv1cJI3XrIKQRIM0TNeGSHByTp76HAZD
6xFIoOjuWb8g5keon8TEBlRa+BRvhM6vvBb7AhJqIdQcXajpPkmNH/kYVDPK6+0I
o3ts5gwRtLgf4wErFUZjYR39nk8t9vYgxKJwbWYLeQP9OQrw0ikumzxiadj0YRqk
ETuX7SF8MVznL/Aeb4QY0ifS6u2a4E7JU+KEnwnoPEJfus2Wz/y45RxZAFXE6rD1
7LDmKc0abvzclEjUXBZsxYPFPqDaSys76X41/ZrpyeCVcWEfaMb+SLnPZYbi9HMW
lgkXRrVsbzYZ7o7yMLMlX1QmnbY/i7eg/xSSoq/8D5ZoRnX0luyT3XwgR4hH7hDP
NUdYzMUjZ5yVgC3T7hOAQQ0r908YUaVGTLUVjiVBTv300ntksAQ4fubaoRNEOhlm
wLHCBBtd4I2Ff0TbwTWJd2nVVHGhmz7uiEk8V7WVX4wvy319700BSizrclBb4ybm
T0GBuRilqa/j8cO13LFFp8sJyz4PnFylkLJC/OC9CFfyG5dTd5TRFE+VT5r4mpfo
TFIO+cCPUcUsWnuZzMzyZvQ2veVFYXTAadNNoQE/EZL00KF3bkY=
=2I07
-END PGP SIGNATURE-

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

Re: cookie configurations for Tomcat 7

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Lazar,

On 2/24/20 02:05, Lazar Kirchev wrote:
> Chris,
>
> CookieProcessor.generateCookie(Map<> requestHeaders, Cookie) will
> work perfectly for me and I guess for anyone who needs to check the
> client version.

Want to prepare a PR?

- -chris

> On Fri, Feb 21, 2020 at 7:17 PM Christopher Schultz <
> ch...@christopherschultz.net> wrote:
>
> Lazar,
>
> On 2/21/20 10:29, Lazar Kirchev wrote:
 Yes, the SameSite attribute is still in a draft and this
 causes the mess, at least partly.> And yes, I was thinking
 about something like that -
 CookieProcessor.generateCookie(String userAgent, Cookie) or
 CookieProcessor.generateCookie(Map<> requestHeaders, Cookie).
 I
> absolutely
 agree that this would be very hacky. And it might be
 dangerous as CookieProcessor is an interface and there
 already might be custom implementations.
>
> We can fix that with default implementations, for Java versions
> that support such thing (Java >= 1.8).
>
 But can you think of another way of making the cookie
 generation logic aware of the user agent header value?
>
> Not really.
>
> I have a preference for:
>
> CookieProcessor.generateCookie(Map<> requestHeaders, Cookie)
>
> This is because User-Agent might not be the only header which is
> useful, here. For example, Google Chrome (amusingly enough) will
> be removing the User-Agent header[1] in favor of "client
> hints"[2].
>
> So you might have to look at more than one header at a time,
> including possibly User-Agent.
>
> -chris
>
> [1]
> https://www.zdnet.com/article/google-to-phase-out-user-agent-strings-i
n-
>
>
chrome/
> 
>
>  [2] https://wicg.github.io/ua-client-hints/
>
 On Fri, Feb 14, 2020 at 8:59 PM Christopher Schultz <
 ch...@christopherschultz.net> wrote:

 Lazar,

 On 2/14/20 05:36, Lazar Kirchev wrote:
>>> Chris,
>>>
>>> Just FYI or in case someone else hits this problem.
>>>
>>> Actually I had to use the response wrapper approach
>>> for Tomcat 8.5.50 as well. As described by Chrome in
>>> https://www.chromium.org/updates/same-site/incompatible-clients,
>>>
>>>
>
>>>
there are older browser versions which do not support the SameSite
>>> attribute at all and reject the cookies which contain
>>> it. Although Tomcat 8.5.42 and later provide the
>>> CookieProcessor configuration for the SameSite
>>> attribute, it is a problem if one wants to support
>>> older browser versions as well.
 Wow, what a huge pain in the neck. I don't see anything in
 RFC 6265 that says anything about rejecting cookies with
 unknown attributes, but I also don't see anything prohibiting
 that behavior, either. Than again, RFC 6265 doesn't mention
 the SameSite attribute at all, so ... there is that.

 This is what you get when vendors try to implement standards
 before they are standards.

>>> Adding the SameSite attribute in order to support
>>> newest Chrome breaks the old ones as the configuration
>>> via the CookieProcessor does not allow for user agent
>>> sniffing. Even if you extend the existing
>>> CookieProcessor implementations or create your own, you
>>> cannot get the request headers in it so that you can
>>> check for the browser version. If one needs such
>>> flexibility, only the response wrapper helps. Do you
>>> think that it makes sense to provide a mechanism in
>>> the CookieProcessor to get access to the request
>>> headers in order to check the user agent?
 Are you referring to CookieProcessor.generateCookie(Cookie)?
 So the proposal would be to change that to
 CookieProcessor.generateCookie(String userAgent, Cookie)? Or
 maybe even CookieProcessor.generateCookie(Map<>
 rquestHeaders, Cookie)?

 It seems super hacky to do it that way, but I'm not sure I
 see another option for introducing SameSite in a compatible
 way.

 -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
>>
>>
>
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl5T6WwACgkQHPApP6U8
pFhGHxAAwiVqrNm6k4LjfFedovPEVPADUqGe1cT9UIB1seFUhPJ2u1REgVhOoAsq
EuIxnn69nRpqqtp31petFk7D1XMw9HQHgr6dXBJILL+fPxqZxvavDeM+jqXL/D4O
+UTzz85EXMl0A/HVkIYR9tb0kW3lgLEvdyYeWQB+0sz3pzdyIxW6ZtKOfRFOwjff

[ANN] Apache Tomcat 10.0.0-M1 available

[Mark Thomas]

The Apache Tomcat team announces the immediate availability of Apache
Tomcat 10.0.0-M1.

Apache Tomcat 10 is an open source software implementation of the
Jakarta Servlet, Jakarta Server Pages, Jakarta Expression Language,
Jakarta WebSocket, Jakarta Authentication and Jakarta Annotations
specifications.

Users of Tomcat 10 onwards should be aware that, as a result of the move
from Java EE to Jakarta EE as part of the transfer of Java EE to the
Eclipse Foundation, the primary package for all implemented APIs has
changed from javax.* to jakarta.*. This will almost certainly require
code changes to enable applications to migrate from Tomcat 9 and earlier
to Tomcat 10 and later. A migration tool is under development to aid
this process.

Apache Tomcat 10.0.0-M1 is the first milestone release of the 10.0.x
branch and has been made to provide users with early access to the new
features in Apache Tomcat 10.0.x so that they may provide feedback. The
notable changes compared to 9.0.x include:

- Update to Jakarta Servlet 5.0, Jakarta Server Pages 3.0,
  Jakarta Expression Language 4.0, Jakarta WebSocket 2.0,
  Jakarta Authentication 2.0 and Jakarta Annotations 2.0 specifications.

- Use  and  in
  conf/web.xml to set the default request and response character
  encodings to UTF-8.

- Remove duplication of HTTP/1.1 configuration on the HTTP/2
  UpgradeProtocol element. Configuration from the main Connector element
  will now be used.

Please refer to the change log for the complete list of changes:
http://tomcat.apache.org/tomcat-10.0-doc/changelog.html

Downloads:
http://tomcat.apache.org/download-10.cgi

Migration guides from Apache Tomcat 7.0.x, 8.5.x and 9.0.x:
http://tomcat.apache.org/migration.html

Enjoy!

- The Apache Tomcat team

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

[SECURITY] CVE-2020-1938 AJP Request Injection and potential Remote Code Execution

[Mark Thomas]

CVE-2020-1938 AJP Request Injection and potential Remote Code Execution

Severity: High

Vendor: The Apache Software Foundation

Versions Affected:
Apache Tomcat 9.0.0.M1 to 9.0.30
Apache Tomcat 8.5.0 to 8.5.50
Apache Tomcat 7.0.0 to 7.0.99

Description:
When using the Apache JServ Protocol (AJP), care must be taken when
trusting incoming connections to Apache Tomcat. Tomcat treats AJP
connections as having higher trust than, for example, a similar HTTP
connection. If such connections are available to an attacker, they can
be exploited in ways that may be surprising.

Prior to Tomcat 9.0.31, 8.5.51 and 7.0.100, Tomcat shipped with an AJP
Connector enabled by default that listened on all configured IP
addresses. It was expected (and recommended in the security guide) that
this Connector would be disabled if not required.

Prior to this vulnerability report, the known risks of an attacker being
able to access the AJP port directly were:
- bypassing security checks based on client IP address
- bypassing user authentication if Tomcat was configured to trust
  authentication data provided by the reverse proxy
This vulnerability report identified a mechanism that allowed the following:
- returning arbitrary files from anywhere in the web application
  including under the WEB-INF and META-INF directories or any other
  location reachable via ServletContext.getResourceAsStream()
- processing any file in the web application as a JSP
Further, if the web application allowed file upload and stored those
files within the web application (or the attacker was able to control
the content of the web application by some other means) then this, along
with the ability to process a file as a JSP, made remote code execution
possible.

Mitigation:
It is important to note that mitigation is only required if an AJP port
is accessible to untrusted users.
- If AJP support is not required, the Connector may be disabled e.g. by
  removing the AJP Connector element from the server.xml file
- If AJP support is required, untrusted users may be prevented from
  accessing the AJP port by one or more of the following means:
  - configuring appropriate network firewall rules
  - configuring an explicit address attribute to the connector so that
the Connector listens on a non-public interface
  - configuring a shared secret for the AJP connection
Users wishing to take a defence-in-depth approach and block the vector
that permits returning arbitrary files and execution as JSP may upgrade to:
- Apache Tomcat 9.0.31 or later
- Apache Tomcat 8.5.51 or later
- Apache Tomcat 7.0.100 or later
Users should note that a number of changes were made to the default AJP
Connector configuration in these versions to harden the default
configuration. The changes are:
- The AJP Connector is commented out in the provided server.xml file.
- The "requiredSecret" attribute has been renamed "secret" (the old name
  continues to work but is deprecated).
- A new attribute "secretRequired" has been added which defaults to
  "true". When this attribute is "true", the AJP Connector will not
  start unless a shared secret has been configured.
- The default listen address for the AJP Connector is now the loopback
  address.
It is likely that users upgrading to 9.0.31, 8.5.51 or 7.0.100 and later
will need to make small changes to their configurations as a result.


References:
[1] http://tomcat.apache.org/security-9.html
[2] http://tomcat.apache.org/security-8.html
[3] http://tomcat.apache.org/security-7.html

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

[SECURITY] CVE-2019-17569 HTTP Request Smuggling

[Mark Thomas]

CVE-2019-17569 HTTP Request Smuggling

Severity: Low

Vendor: The Apache Software Foundation

Versions Affected:
Apache Tomcat 9.0.28 to 9.0.30
Apache Tomcat 8.5.48 to 8.5.50
Apache Tomcat 7.0.98 to 7.0.99

Description:
The refactoring in 9.0.28, 8.5.48 and 7.0.98 introduced a regression.
The result of the regression was that invalid Transfer-Encoding headers
were incorrectly processed leading to a possibility of HTTP Request
Smuggling if Tomcat was located behind a reverse proxy that incorrectly
handled the invalid Transfer-Encoding header in a particular manner.
Such a reverse proxy is considered unlikely.

Mitigation:
- Upgrade to Apache Tomcat 9.0.31 or later
- Upgrade to Apache Tomcat 8.5.51 or later
- Upgrade to Apache Tomcat 7.0.100 or later

Credit:
This issue was found by @ZeddYu and reported responsibly to the Apache
Tomcat Security Team.

References:
[1] http://tomcat.apache.org/security-9.html
[2] http://tomcat.apache.org/security-8.html
[3] http://tomcat.apache.org/security-7.html

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

[SECURITY] CVE-2020-1935 HTTP Request Smuggling

[Mark Thomas]

CVE-2020-1935 HTTP Request Smuggling

Severity: Low

Vendor: The Apache Software Foundation

Versions Affected:
Apache Tomcat 9.0.0.M1 to 9.0.30
Apache Tomcat 8.5.0 to 8.5.50
Apache Tomcat 7.0.0 to 7.0.99

Description:
The HTTP header parsing code used an approach to end-of-line parsing
that allowed some invalid HTTP headers to be parsed as valid. This led
to a possibility of HTTP Request Smuggling if Tomcat was located behind
a reverse proxy that incorrectly handled the invalid Transfer-Encoding
header in a particular manner. Such a reverse proxy is considered unlikely.

Mitigation:
- Upgrade to Apache Tomcat 9.0.31 or later
- Upgrade to Apache Tomcat 8.5.51 or later
- Upgrade to Apache Tomcat 7.0.100 or later

Credit:
This issue was found by @ZeddYu and reported responsibly to the Apache
Tomcat Security Team.

References:
[1] http://tomcat.apache.org/security-9.html
[2] http://tomcat.apache.org/security-8.html
[3] http://tomcat.apache.org/security-7.html

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