RE: Migrating from Tomcat 9.0.x to 10.1.x
Thank you, Chris, for the feedback.
The changes are needed in the Spring WebSocket library to ensure Tomcat 10.1
compatibility.
https://github.com/spring-projects/spring-framework/pull/29434
As I understand, this means I should be updating the Spring libraries used in
the applications to be deployed with Tomcat 10.1.
I was exploring the possibility of performing Tomcat 10 upgrade independent of
the upgrades of TPIPs used the application (mainly Spring 5 to 6). And using
migration tool seemed a very promising approach.
Now looking at issue like this, seems like it's ideal to have both Tomcat
upgrade and the application TPIPs upgrade go together.
Thanks,
Amit
-Original Message-
From: Christopher Schultz
Sent: Thursday, April 4, 2024 9:37 PM
To: users@tomcat.apache.org
Subject: Re: Migrating from Tomcat 9.0.x to 10.1.x
CAUTION: This email originated from outside the organization. Do not click
links or open attachments unless you recognize the sender and know the content
is safe. If you believe this is a phishing email, use the Report to
Cybersecurity icon in Outlook.
Amit,
On 4/4/24 22:21, Amit Pande wrote:
> I am in the process of migrating from Tomcat 9 (9.0.87) to Tomcat 10.1
> (10.1.20).
>
> https://tomcat.apache.org/migration-10.1.html Using the migration tool, I
> have migrated the applications (which use Spring libraries 5.x).
>
> While testing the migrated apps( which use web socket), ran into:
>
>
> org.springframework.web.util.NestedServletException: Handler dispatch
> failed; nested exception is java.lang.NoSuchMethodError: 'void
> org.apache.tomcat.websocket.server.WsServerContainer.doUpgrade(jakarta
> .servlet.http.HttpServletRequest,
> jakarta.servlet.http.HttpServletResponse,
> jakarta.websocket.server.ServerEndpointConfig, java.util.Map)
>
>
> https://gith/
> ub.com%2Fapache%2Ftomcat%2Fblob%2F9.0.x%2Fjava%2Forg%2Fapache%2Ftomcat
> %2Fwebsocket%2Fserver%2FWsServerContainer.java=05%7C02%7CAmit.Pan
> de%40veritas.com%7C2650bfb140d94911624408dc55195c23%7Cfc8e13c0422c4c55
> b3eaca318e6cac32%7C0%7C0%7C638478814607427868%7CUnknown%7CTWFpbGZsb3d8
> eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0
> %7C%7C%7C=w69RggozFPZcifxDJOHnII9jtZJJ29qZQSkDNNFYTzE%3D
> d=0
>
> * @deprecated This method will be removed in Apache Tomcat 10.1 onwards.
> It has been replaced by
> * {@link #upgradeHttpToWebSocket(Object, Object,
> ServerEndpointConfig, Map)}
> */
> @Deprecated
> public void doUpgrade(HttpServletRequest request, HttpServletResponse
> response, ServerEndpointConfig sec,
> Map pathParams) throws ServletException,
> IOException {
> UpgradeUtil.doUpgrade(this, request, response, sec, pathParams);
> }
>
> Is this an issue with the migration tool to appropriately replace the removed
> methods?
>
> Or the applications using web sockets with Tomcat 9.x are required to be
> updated before moving to Tomcat 10.1, instead of using the migration tool as
> an intermediate step to upgrade to Tomcat 10.1 without having to update the
> applications at the same time?
> FWIW, Spring 5 to Spring 6 is a major upgrade and Tomcat 10 is a requirement.
The Migration Tool doesn't rewrite your code, it only rewrites the class names
referenced by your class files. (Okay, it also re-writes strings in your files
which match those class names as well.) But it will not change method calls. It
is not a Deprecation Cleanup Tool.
You should change your Java EE-compatible application to use
upgradeHttpToWebSocket(Object, Object, ServerEndpointConfig, Map) first, then
run the Migration Tool on your application.
-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
Migrating from Tomcat 9.0.x to 10.1.x
Hello,
I am in the process of migrating from Tomcat 9 (9.0.87) to Tomcat 10.1
(10.1.20).
https://tomcat.apache.org/migration-10.1.html Using the migration tool, I have
migrated the applications (which use Spring libraries 5.x).
While testing the migrated apps( which use web socket), ran into:
org.springframework.web.util.NestedServletException: Handler dispatch failed;
nested exception is java.lang.NoSuchMethodError: 'void
org.apache.tomcat.websocket.server.WsServerContainer.doUpgrade(jakarta.servlet.http.HttpServletRequest,
jakarta.servlet.http.HttpServletResponse,
jakarta.websocket.server.ServerEndpointConfig, java.util.Map)
https://github.com/apache/tomcat/blob/9.0.x/java/org/apache/tomcat/websocket/server/WsServerContainer.java
* @deprecated This method will be removed in Apache Tomcat 10.1 onwards. It
has been replaced by
* {@link #upgradeHttpToWebSocket(Object, Object,
ServerEndpointConfig, Map)}
*/
@Deprecated
public void doUpgrade(HttpServletRequest request, HttpServletResponse
response, ServerEndpointConfig sec,
Map pathParams) throws ServletException,
IOException {
UpgradeUtil.doUpgrade(this, request, response, sec, pathParams);
}
Is this an issue with the migration tool to appropriately replace the removed
methods?
Or the applications using web sockets with Tomcat 9.x are required to be
updated before moving to Tomcat 10.1, instead of using the migration tool as an
intermediate step to upgrade to Tomcat 10.1 without having to update the
applications at the same time?
FWIW, Spring 5 to Spring 6 is a major upgrade and Tomcat 10 is a requirement.
Appreciate the guidance.
Thanks,
Amit
RE: Regression in mutual authentication in 9.0.86+?
Thank you Mark for your inputs.
Upon further debugging, it looks like the issue we ran into is also with the
reloading of SSL context.
Test execution sequence:
1. Add a trusted CA in Tomcat's trust store.
2. The SSL context is reloaded if any of the trust/key store has changes.
3. Perform a mutual client authentication using a client certificate signed by
the CA used in step 1.
Still a bit puzzled in such a case there was no SSL handshake failure at Tomcat
level but request made it to application and failed (due to empty
javax.servlet.request.X509Certificate).
One follow-up question:
Are we planning to have an immediate 9.0.88 release, or it will be regular
cadence? Asking because the versions until 9.0.85 have vulnerabilities reported
and this regression might potentially block the upgrade to 9.0.86/87.
Lastly, I wholeheartedly echo the gratitude many have expressed around the
awesome Tomcat leads.
Thanks,
Amit
-Original Message-
From: Mark Thomas
Sent: Monday, March 18, 2024 4:41 AM
To: users@tomcat.apache.org
Subject: Re: Regression in mutual authentication in 9.0.86+?
CAUTION: This email originated from outside the organization. Do not click
links or open attachments unless you recognize the sender and know the content
is safe. If you believe this is a phishing email, use the Report to
Cybersecurity icon in Outlook.
I've just tested 9.0.x and mutual TLS authentication appears to be working as
expected.
I suggest starting with testing a simple JSP that echoes that attribute and if
you still see the issue, provide us with your configuration. Note that the
issue may be related to the certs you are using so the configuration
information should include steps to recreate the TLS certs with keystore,
OpenSSL or similar.
On 15/03/2024 00:48, Amit Pande wrote:
> Hello all,
>
> I have upgraded the Tomcat version from 9.0.85 to 9.0.86 (and tried with
> 9.0.87 too).
>
> Some of our tests which involve on mutual authentication
> ("certificateVerification = optional") have started to fail.
>
> In tests where the client does pass the certificate, I didn't see any SSL
> handshake errors (with SSL handshake debugging enabled) but
> "javax.servlet.request.X509Certificate" attribute wasn't set. This is the
> attribute the application needs for further validations.
Have you confirmed that the certificate was sent from the client?
> Could anyone please give pointers on how to debug this further?
>
> Any code pointers where Tomcat sets this
> "javax.servlet.request.X509Certificate" attribute?
git clone
grep
> Also, one more question - with optional certificate verification, the
> connection doesn't fail if certificate is not passed. But connection will
> fail if SSL handshake fails when a certificate is passed by client, is that
> correct understanding?
Yes, that is what I would expect.
Mark
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Regression in mutual authentication in 9.0.86+?
Hello all,
I have upgraded the Tomcat version from 9.0.85 to 9.0.86 (and tried with 9.0.87
too).
Some of our tests which involve on mutual authentication
("certificateVerification = optional") have started to fail.
In tests where the client does pass the certificate, I didn't see any SSL
handshake errors (with SSL handshake debugging enabled) but
"javax.servlet.request.X509Certificate" attribute wasn't set. This is the
attribute the application needs for further validations.
Could anyone please give pointers on how to debug this further?
Any code pointers where Tomcat sets this
"javax.servlet.request.X509Certificate" attribute?
Also, one more question - with optional certificate verification, the
connection doesn't fail if certificate is not passed. But connection will fail
if SSL handshake fails when a certificate is passed by client, is that correct
understanding?
Thanks,
Amit
RE: JAVA -tomcat- Request header is too large
Thank you, Chris. Right now, we're on 9.x line. But this is a very important and useful field for debugging which we should be aware of. Thanks, Amit -Original Message- From: Christopher Schultz Sent: Monday, December 11, 2023 2:02 PM To: users@tomcat.apache.org Subject: Re: JAVA -tomcat- Request header is too large CAUTION: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. If you believe this is a phishing email, use the Report to Cybersecurity icon in Outlook. Amit, On 12/11/23 11:32, Amit Pande wrote: > Mark, Chris, > > What request ID we're referring to here? Perhaps, I missed some documentation? > > How do we enable it? Request-id is available in Tomcat 11.0 and 10.1 at the moment. Are you using either of those? I'm not seeing any documentation in the AccessLogValve for reporting that value anywhere... -chris > -Original Message- > From: Mark Thomas > Sent: Monday, December 11, 2023 3:06 AM > To: users@tomcat.apache.org > Subject: Re: JAVA -tomcat- Request header is too large > > > CAUTION: This email originated from outside the organization. Do not click > links or open attachments unless you recognize the sender and know the > content is safe. If you believe this is a phishing email, use the Report to > Cybersecurity icon in Outlook. > > > > On 08/12/2023 22:01, Christopher Schultz wrote: > > > >> Are request-ids always allocated, or only if they are "enabled"? > > Always allocated. > >> I think adding the request-id to this exception detail message might >> be helpful, even if the request-id hasn't been enabled in the access-log. >> >> WDYT? > > Good point. More widely, we should probably be adding the request ID to every > request related error message. > > 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: JAVA -tomcat- Request header is too large
Mark, Chris, What request ID we're referring to here? Perhaps, I missed some documentation? How do we enable it? Thanks, Amit -Original Message- From: Mark Thomas Sent: Monday, December 11, 2023 3:06 AM To: users@tomcat.apache.org Subject: Re: JAVA -tomcat- Request header is too large CAUTION: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. If you believe this is a phishing email, use the Report to Cybersecurity icon in Outlook. On 08/12/2023 22:01, Christopher Schultz wrote: > Are request-ids always allocated, or only if they are "enabled"? Always allocated. > I think adding the request-id to this exception detail message might > be helpful, even if the request-id hasn't been enabled in the access-log. > > WDYT? Good point. More widely, we should probably be adding the request ID to every request related error message. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
FIPS Configuration for Java 11/17 and Tomcat 9
Please refer to the link below in case you are interested in configuring FIPS for Tomcat 9 running on Java 17. https://github.com/amitlpande/tomcat-9-fips/wiki/Java-11-17-Tomcat-9-FIPS-Configuration-Using-Bouncy-Castle I have tested steps for Java 11 and even Java 8 too. But there are different ways for Java 8 at least (https://github.com/amitlpande/tomcat-9-fips). Appreciate reviews and any other feedback. Thanks, Amit
RE: [External] RE: Java 9+ and custom JCE/JSSE providers
Hello Cris, The system property can take an URL. java.security.properties=. However, my quick testing suggests the protocol (file:/ ) isn't needed. Also, perhaps worth reading the effects of "=" and "==" while using this property. https://bugs.openjdk.org/browse/JDK-7133344 https://github.com/frohoff/jdk8u-dev-jdk/blob/master/src/share/lib/security/java.security-linux Thanks, Amit -Original Message- From: Berneburg, Cris J. - US Sent: Thursday, November 2, 2023 3:41 PM To: Tomcat Users List Subject: [External] RE: Java 9+ and custom JCE/JSSE providers CAUTION: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. If you believe this is a phishing email, use the Report to Cybersecurity icon in Outlook. Amit > -Djava.security.properties=file:/path/to/java_security_properties_file That "file:" prefix looks like Spring syntax. Is the prefix needed on the JVM command line? -- Cris Berneburg CACI Senior Software Engineer -Original Message- From: Amit Pande Sent: Tuesday, October 31, 2023 10:23 AM To: Tomcat Users List Subject: Java 9+ and custom JCE/JSSE providers EXTERNAL EMAIL - This email originated from outside of CACI. Do not click any links or attachments unless you recognize and trust the sender. Hello, I am in the process of updating https://github.com/amitlpande/tomcat-9-fips page for version later than Java 8. Ran into an issue: 1. Was looking the configure the additional bouncy castle providers in the Java install itself by: * Modifying the java.security file to add providers. * Place the jars in the Java'e lib/ext directory. 2. However, from Java 9+, the lib/ext directory is no longer present (https://docs.oracle.com/javase/9/migrate/toc.htm#JSMIG-GUID-2C896CA8-927C-4381-A737-B1D81D964B7B) 3. The alternate I attempted was to place the additional provider jars in Tomcat's lib directory. 4. Create a java security properties file with: security.provider.1=org.bouncycastle.jcajce.provider.BouncyCastleFipsProvider security.provider.2=org.bouncycastle.jsse.provider.BouncyCastleJsseProvider fips:BCFIPS security.provider.3=sun.security.provider.Sun ssl.KeyManagerFactory.algorithm=PKIX ssl.TrustManagerFactory.algorithm=PKIX 1. Launch Tomcat with JVM option -Djava.security.properties=file:/path/to/java_security_properties_file 2. However, I noticed that these BC providers weren't getting loaded. I see a comment from Chris here - https://www.mail-archive.com/users@tomcat.apache.org/msg137824.html "I don't see any place in Tomcat to specify the JSSE provider. Perhaps we should expose that to the administrator in some way." Not sure if it's relevant here. But wanted to know if there is any way to configure Tomcat for Java 9+ with custom JSSE/JCE providers (with just config change) ? Maybe I missed something? Also, FWIW, I was able get the FIPS configuration for Java 11, 17 with Tomcat 9, by registering a custom listener and adding providers there. Will soon update the https://github.com/amitlpande/tomcat-9-fips for detailed steps. Thanks, Amit This electronic message contains information from CACI International Inc or subsidiary companies, which may be company sensitive, proprietary, privileged or otherwise protected from disclosure. The information is intended to be used solely by the recipient(s) named above. If you are not an intended recipient, be aware that any review, disclosure, copying, distribution or use of this transmission or its contents is prohibited. If you have received this transmission in error, please notify the sender immediately. - 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: [External] Re: Java 9+ and custom JCE/JSSE providers
Setting CLASSPATH worked perfectly! Thank you so much Mark! Thanks, Amit -Original Message- From: Mark Thomas Sent: Tuesday, October 31, 2023 2:47 PM To: users@tomcat.apache.org Subject: [External] Re: Java 9+ and custom JCE/JSSE providers CAUTION: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. If you believe this is a phishing email, use the Report to Cybersecurity icon in Outlook. On 31/10/2023 14:22, Amit Pande wrote: > Hello, > > I am in the process of updating https://github.com/amitlpande/tomcat-9-fips > page for version later than Java 8. > > Ran into an issue: > > >1. Was looking the configure the additional bouncy castle providers in > the Java install itself by: > * Modifying the java.security file to add providers. > * Place the jars in the Java'e lib/ext directory. >2. However, from Java 9+, the lib/ext directory is no longer present > (https://docs.oracle.com/javase/9/migrate/toc.htm#JSMIG-GUID-2C896CA8-927C-4381-A737-B1D81D964B7B) >3. The alternate I attempted was to place the additional provider jars in > Tomcat's lib directory. >4. Create a java security properties file with: > > security.provider.1=org.bouncycastle.jcajce.provider.BouncyCastleFipsProvider > > security.provider.2=org.bouncycastle.jsse.provider.BouncyCastleJsseProvider > fips:BCFIPS > security.provider.3=sun.security.provider.Sun > ssl.KeyManagerFactory.algorithm=PKIX > ssl.TrustManagerFactory.algorithm=PKIX > >1. Launch Tomcat with JVM option > -Djava.security.properties=file:/path/to/java_security_properties_file >2. However, I noticed that these BC providers weren't getting loaded. You'll also need to add the JARS containing the providers to the class path so the JRE can load them. You should be able to do that (and set java.security.properties) in setenv.sh|bat Mark > > > > > > > I see a comment from Chris here - > https://www/. > mail-archive.com%2Fusers%40tomcat.apache.org%2Fmsg137824.html=05% > 7C01%7CAmit.Pande%40veritas.com%7C4bcc30de9820433b280308dbda4a443a%7Cf > c8e13c0422c4c55b3eaca318e6cac32%7C0%7C0%7C638343784744378375%7CUnknown > %7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJ > XVCI6Mn0%3D%7C3000%7C%7C%7C=SgG9b6ilBMEGwV5nedIdX9XcXXDGHqbyQmva > 14m8xwI%3D=0 "I don't see any place in Tomcat to specify the > JSSE provider. Perhaps we should expose that to the administrator in some > way." > > Not sure if it's relevant here. > > But wanted to know if there is any way to configure Tomcat for Java 9+ with > custom JSSE/JCE providers (with just config change) ? Maybe I missed > something? > > Also, FWIW, I was able get the FIPS configuration for Java 11, 17 with Tomcat > 9, by registering a custom listener and adding providers there. Will soon > update the https://github.com/amitlpande/tomcat-9-fips for detailed steps. > > Thanks, > Amit > > > > - 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: [External] Re: Java 9+ and custom JCE/JSSE providers
Adding the provider jars to CLASSPATH solved the issue. Thank you so much Mark for your quick feedback. Thanks, Amit -Original Message- From: Mark Thomas Sent: Tuesday, October 31, 2023 2:47 PM To: users@tomcat.apache.org Subject: [External] Re: Java 9+ and custom JCE/JSSE providers CAUTION: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. If you believe this is a phishing email, use the Report to Cybersecurity icon in Outlook. On 31/10/2023 14:22, Amit Pande wrote: > Hello, > > I am in the process of updating https://github.com/amitlpande/tomcat-9-fips > page for version later than Java 8. > > Ran into an issue: > > >1. Was looking the configure the additional bouncy castle providers in > the Java install itself by: > * Modifying the java.security file to add providers. > * Place the jars in the Java'e lib/ext directory. >2. However, from Java 9+, the lib/ext directory is no longer present > (https://docs.oracle.com/javase/9/migrate/toc.htm#JSMIG-GUID-2C896CA8-927C-4381-A737-B1D81D964B7B) >3. The alternate I attempted was to place the additional provider jars in > Tomcat's lib directory. >4. Create a java security properties file with: > > security.provider.1=org.bouncycastle.jcajce.provider.BouncyCastleFipsProvider > > security.provider.2=org.bouncycastle.jsse.provider.BouncyCastleJsseProvider > fips:BCFIPS > security.provider.3=sun.security.provider.Sun > ssl.KeyManagerFactory.algorithm=PKIX > ssl.TrustManagerFactory.algorithm=PKIX > >1. Launch Tomcat with JVM option > -Djava.security.properties=file:/path/to/java_security_properties_file >2. However, I noticed that these BC providers weren't getting loaded. You'll also need to add the JARS containing the providers to the class path so the JRE can load them. You should be able to do that (and set java.security.properties) in setenv.sh|bat Mark > > > > > > > I see a comment from Chris here - > https://www/. > mail-archive.com%2Fusers%40tomcat.apache.org%2Fmsg137824.html=05% > 7C01%7CAmit.Pande%40veritas.com%7C4bcc30de9820433b280308dbda4a443a%7Cf > c8e13c0422c4c55b3eaca318e6cac32%7C0%7C0%7C638343784744378375%7CUnknown > %7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJ > XVCI6Mn0%3D%7C3000%7C%7C%7C=SgG9b6ilBMEGwV5nedIdX9XcXXDGHqbyQmva > 14m8xwI%3D=0 "I don't see any place in Tomcat to specify the > JSSE provider. Perhaps we should expose that to the administrator in some > way." > > Not sure if it's relevant here. > > But wanted to know if there is any way to configure Tomcat for Java 9+ with > custom JSSE/JCE providers (with just config change) ? Maybe I missed > something? > > Also, FWIW, I was able get the FIPS configuration for Java 11, 17 with Tomcat > 9, by registering a custom listener and adding providers there. Will soon > update the https://github.com/amitlpande/tomcat-9-fips for detailed steps. > > Thanks, > Amit > > > > - 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
Java 9+ and custom JCE/JSSE providers
Hello, I am in the process of updating https://github.com/amitlpande/tomcat-9-fips page for version later than Java 8. Ran into an issue: 1. Was looking the configure the additional bouncy castle providers in the Java install itself by: * Modifying the java.security file to add providers. * Place the jars in the Java'e lib/ext directory. 2. However, from Java 9+, the lib/ext directory is no longer present (https://docs.oracle.com/javase/9/migrate/toc.htm#JSMIG-GUID-2C896CA8-927C-4381-A737-B1D81D964B7B) 3. The alternate I attempted was to place the additional provider jars in Tomcat's lib directory. 4. Create a java security properties file with: security.provider.1=org.bouncycastle.jcajce.provider.BouncyCastleFipsProvider security.provider.2=org.bouncycastle.jsse.provider.BouncyCastleJsseProvider fips:BCFIPS security.provider.3=sun.security.provider.Sun ssl.KeyManagerFactory.algorithm=PKIX ssl.TrustManagerFactory.algorithm=PKIX 1. Launch Tomcat with JVM option -Djava.security.properties=file:/path/to/java_security_properties_file 2. However, I noticed that these BC providers weren't getting loaded. I see a comment from Chris here - https://www.mail-archive.com/users@tomcat.apache.org/msg137824.html "I don't see any place in Tomcat to specify the JSSE provider. Perhaps we should expose that to the administrator in some way." Not sure if it's relevant here. But wanted to know if there is any way to configure Tomcat for Java 9+ with custom JSSE/JCE providers (with just config change) ? Maybe I missed something? Also, FWIW, I was able get the FIPS configuration for Java 11, 17 with Tomcat 9, by registering a custom listener and adding providers there. Will soon update the https://github.com/amitlpande/tomcat-9-fips for detailed steps. Thanks, Amit
RE: [External] Re: Tomcat upgrade from 9.0.80 to 9.0.81
Thank you so much for inputs. "If one could help with testing release candidates, it would help." >> I was thinking about this. Is there a channel/process that we can subscribe >> to get the RC candidate updates? If we get to know about a RC build, we can >> perform (black box) testing and communicate the results (Details in case of >> failures). Thanks, Amit -Original Message- From: Konstantin Kolinko Sent: Tuesday, October 10, 2023 7:11 PM To: Tomcat Users List Subject: Re: [External] Re: Tomcat upgrade from 9.0.80 to 9.0.81 CAUTION: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. If you believe this is a phishing email, use the Report to Cybersecurity icon in Outlook. ср, 11 окт. 2023 г. в 02:31, Amit Pande : > > Thank you Konstantin for the quick update! > > Since this release contained multiple security fixes, it's important to > upgrade. However, there seem regressions too. > > What is the way forward here? Follow up version coming sooner? Or a version > with just security fixes and all other changes can go in subsequent release? There are workarounds for these regressions: - Regarding this specific issue: I would just disable the compression. - Regarding the jdbc-pool issue: it is possible to use tomcat-jdbc.jar from a previous release. (Either unzipping a release, or pulling the specific jar from Maven Central). Release managers were at a conference, maybe are travelling, and voting for a new release usually takes 3 days. The vote was unusually shortened due to one of the issues going public and I guess that it might be widely discussed and (ab)used. I still do not know how this will be handled, but it may take a few days. Watch for "VOTE" threads on the dev mailing list. If one could help with testing release candidates, it would help. Best regards, Konstantin Kolinko - 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: [External] Re: Tomcat upgrade from 9.0.80 to 9.0.81
Thank you Konstantin for the quick update! Since this release contained multiple security fixes, it's important to upgrade. However, there seem regressions too. What is the way forward here? Follow up version coming sooner? Or a version with just security fixes and all other changes can go in subsequent release? Thanks, Amit From: Konstantin Kolinko Sent: Tuesday, October 10, 2023 5:12:45 PM To: Tomcat Users List Subject: [External] Re: Tomcat upgrade from 9.0.80 to 9.0.81 CAUTION: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. If you believe this is a phishing email, use the Report to Cybersecurity icon in Outlook. Hi! Thank you for reporting and investigating the issue. I added your observation to https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbz.apache.org%2Fbugzilla%2Fshow_bug.cgi%3Fid%3D67670=05%7C01%7CAmit.Pande%40veritas.com%7C65608c49469b42b3f6ea08dbc9de3891%7Cfc8e13c0422c4c55b3eaca318e6cac32%7C0%7C0%7C638325728499716103%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=oADTYN4nOfLFatx%2BOXDEXsVuXgHZvvBfoFcKK93jrLk%3D=0<https://bz.apache.org/bugzilla/show_bug.cgi?id=67670> Best regards, Konstantin Kolinko ср, 11 окт. 2023 г. в 00:01, Amit Pande : > > I am still investigating more but after upgrading from Tomcat 9.0.80 to > 9.0.81, many of our rest assured based tests are failing with below error ... > > Caused by: org.apache.http.ConnectionClosedException: Premature end of > Content-Length delimited message body (expected: 4,999; received: 3,040) >at > org.apache.http.impl.io.ContentLengthInputStream.read(ContentLengthInputStream.java:178) >at io.restassured.internal.util.IOUtils.toByteArray(IOUtils.java:30) >at > io.restassured.internal.http.GZIPEncoding$GZIPDecompressingEntity.getContent(GZIPEncoding.java:69) >at > org.apache.http.conn.BasicManagedEntity.getContent(BasicManagedEntity.java:85) >at > io.restassured.internal.http.HTTPBuilder.parseResponse(HTTPBuilder.java:546) >at > io.restassured.internal.RequestSpecificationImpl$RestAssuredHttpBuilder.super$2$parseResponse(RequestSpecificationImpl.groovy) >at sun.reflect.GeneratedMethodAccessor129.invoke(Unknown Source) >at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >at java.lang.reflect.Method.invoke(Method.java:498) >at > org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:107) >at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:323) >at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1268) >at > org.codehaus.groovy.runtime.ScriptBytecodeAdapter.invokeMethodOnSuperN(ScriptBytecodeAdapter.java:144) > > Has anyone seen this? I will keep everyone posted after debugging more. > > Thanks, > Amit - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Tomcat upgrade from 9.0.80 to 9.0.81
I am still investigating more but after upgrading from Tomcat 9.0.80 to 9.0.81, many of our rest assured based tests are failing with below error ... Caused by: org.apache.http.ConnectionClosedException: Premature end of Content-Length delimited message body (expected: 4,999; received: 3,040) at org.apache.http.impl.io.ContentLengthInputStream.read(ContentLengthInputStream.java:178) at io.restassured.internal.util.IOUtils.toByteArray(IOUtils.java:30) at io.restassured.internal.http.GZIPEncoding$GZIPDecompressingEntity.getContent(GZIPEncoding.java:69) at org.apache.http.conn.BasicManagedEntity.getContent(BasicManagedEntity.java:85) at io.restassured.internal.http.HTTPBuilder.parseResponse(HTTPBuilder.java:546) at io.restassured.internal.RequestSpecificationImpl$RestAssuredHttpBuilder.super$2$parseResponse(RequestSpecificationImpl.groovy) at sun.reflect.GeneratedMethodAccessor129.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:107) at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:323) at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1268) at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.invokeMethodOnSuperN(ScriptBytecodeAdapter.java:144) Has anyone seen this? I will keep everyone posted after debugging more. Thanks, Amit
RE: [External] Re: Supporting Proxy Protocol in Tomcat
Thank you, Jonathan, for updating this thread. I was thinking of cleaning up the existing patch and submit it for review. I agree it's better to get feedback before any work is started. Thanks, Amit -Original Message- From: Jonathan S. Fisher Sent: Monday, September 4, 2023 9:42 AM To: Tomcat Users List Subject: Re: [External] Re: Supporting Proxy Protocol in Tomcat CAUTION: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. If you believe this is a phishing email, use the Report to Cybersecurity icon in Outlook. Mark thank you again for your leadership and setting expectations. I'm going to commit to working on this with anyone else that wants to help with the goal of a patch by year end. I want to nail the patch with minimal rework that meets Tomcat project quality standards. To that end, I'll attempt to summarize what you expect here and if you could comment and correct my understanding that would be appreciated. It sounds like you're satisfied with the ubiquity of the Proxy protocol and that it has an RFC We'll target just implementing the latest version of the Proxy protocol We'll implement a "TrustedProxies" feature similar to what the Remote IP Valve does We'll implement a, or modify the RemoteIp, valve to be able to set the remote IP from Proxy protocol headers We'll follow the RFC spec and reject any request that does a proper Proxy protocol header I'm particularly interested in the Proxy protocol over Unix Domain Sockets, so expect to see a lot of the work focused on this, but accepting Proxy Protocol over TCP looks to be quite important from the comments on this email chain If I may ask two things: Can you summarize your desired implementation? What point in the stack should we target to implement this? One thing I'm not familiar with on Tomcat is the testing expectations. If you can point to a set of unit tests and a set of integration tests and say "Do it like this" Anything else on the original patch you liked/didn't like? ( https://bz.apache.org/bugzilla/show_bug.cgi?id=57830) Thank you, On Tue, Aug 29, 2023 at 3:13 PM Mark Thomas wrote: > On 28/08/2023 18:44, Amit Pande wrote: > > Oh, sure. So, what would be the best way to get some conclusion on > > this > thread? > > Provide a patch for review based on the feedback provided here and in > the BZ issue. > > > https://bz/ > > .apache.org%2Fbugzilla%2Fshow_bug.cgi%3Fid%3D57830=05%7C01%7CAm > > it.Pande%40veritas.com%7Cead161f45fdf4f7ae40808dbad552039%7Cfc8e13c0 > > 422c4c55b3eaca318e6cac32%7C0%7C0%7C638294353363138987%7CUnknown%7CTW > > FpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVC > > I6Mn0%3D%7C3000%7C%7C%7C=UPENCoX0wXwqKw4L96w9PfNxSvh%2FzItbDGg > > uwsdMlqY%3D=0 The state of the > ticket isn't updated for long. Perhaps add comments/ask the folks on > user list to vote? > > That is more likely to irritate folks rather than encourage them to > help you progress your patch. > > Mark > > > > > > Thanks, > > Amit > > > > -Original Message- > > From: Mark Thomas > > Sent: Monday, August 28, 2023 11:20 AM > > To: Tomcat Users List > > Subject: Re: [External] Re: Supporting Proxy Protocol in Tomcat > > > > > > CAUTION: This email originated from outside the organization. Do not > click links or open attachments unless you recognize the sender and > know the content is safe. If you believe this is a phishing email, use > the Report to Cybersecurity icon in Outlook. > > > > > > > > 28 Aug 2023 17:11:20 Amit Pande : > > > >> Mark, > >> > >> Just checking - Did this issue get discussed in any of the core > >> members' meeting? > > > > There are no such meetings. Discussion happens on the mailing lists. > > > > Mark > > > > > >> > >> Thanks, > >> Amit > >> > >> -Original Message- > >> From: Amit Pande > >> Sent: Monday, July 31, 2023 9:29 AM > >> To: Tomcat Users List > >> Subject: RE: [External] Re: Supporting Proxy Protocol in Tomcat > >> > >> Yes, understood. > >> > >> Thank you for clarifying. Even I was referring to initial consensus > >> without any timeline or approach conclusion. > >> > >> Thanks, > >> Amit > >> > >> -Original Message- > >> From: Mark Thomas > >> Sent: Friday, July 28, 2023 2:48 PM > >> To: users@tomcat.apache.org > >> Subject: Re: [External] Re: Supporting Proxy Protocol in Tomcat > >> > >> On 28/07/2023 19:2
RE: [External] Re: Supporting Proxy Protocol in Tomcat
Oh, sure. So, what would be the best way to get some conclusion on this thread? https://bz.apache.org/bugzilla/show_bug.cgi?id=57830 The state of the ticket isn't updated for long. Perhaps add comments/ask the folks on user list to vote? Thanks, Amit -Original Message- From: Mark Thomas Sent: Monday, August 28, 2023 11:20 AM To: Tomcat Users List Subject: Re: [External] Re: Supporting Proxy Protocol in Tomcat CAUTION: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. If you believe this is a phishing email, use the Report to Cybersecurity icon in Outlook. 28 Aug 2023 17:11:20 Amit Pande : > Mark, > > Just checking - Did this issue get discussed in any of the core > members' meeting? There are no such meetings. Discussion happens on the mailing lists. Mark > > Thanks, > Amit > > -Original Message- > From: Amit Pande > Sent: Monday, July 31, 2023 9:29 AM > To: Tomcat Users List > Subject: RE: [External] Re: Supporting Proxy Protocol in Tomcat > > Yes, understood. > > Thank you for clarifying. Even I was referring to initial consensus > without any timeline or approach conclusion. > > Thanks, > Amit > > -Original Message- > From: Mark Thomas > Sent: Friday, July 28, 2023 2:48 PM > To: users@tomcat.apache.org > Subject: Re: [External] Re: Supporting Proxy Protocol in Tomcat > > On 28/07/2023 19:21, Amit Pande wrote: >> Thank you all for the valuable discussion on this topic. >> >> Is it okay to say that we're agreeing to adding proxy protocol >> support in Tomcat? > > I think that is a little too strong. At this point there is a proposed > approach and no one is objecting but until there is an actual patch to > discuss... > > Keep in mind that any committer can veto a change. > > My sense is that it should be possible to implement this feature while > addressing any concerns that may be raised but it is not guaranteed. > > Mark > > >> >> Thanks, >> Amit >> >> -Original Message- >> From: Christopher Schultz >> Sent: Thursday, July 27, 2023 4:13 PM >> To: users@tomcat.apache.org >> Subject: Re: [External] Re: Supporting Proxy Protocol in Tomcat >> >> All, >> >> On 7/27/23 12:39, Mark Thomas wrote: >>> On 27/07/2023 16:27, Jonathan S. Fisher wrote: >>>> On the topic of security, may we consider a trustedProxies setting? >>> >>> Seems reasonable. >> >> We should probably look at what httpd did for all of this. >> >> -chris >> >>>> This >>>> would be an analog to the internalProxies setting on RemoteIpValve. >>>> It would need to be able to function with APR/NIO listening in a >>>> Unix Domain Socket. >>>> >>>> I'm not sure if this is super useful, but the goal would be an >>>> added layer of security to prevent Proxy Protocol header injection. >>>> >>>> On Thu, Jul 27, 2023 at 3:47 AM Mark Thomas >>>> wrote: >>>> >>>>> On 26/07/2023 21:53, Christopher Schultz wrote: >>>>>> Mark, >>>>>> >>>>>> On 7/26/23 13:58, Mark Thomas wrote: >>>>>>> I'm not a huge fan of this feature in general. I prefer >>>>>>> supporting features backed by specifications rather than vendor >>>>>>> specific hacks. >>>>>> >>>>>> I think the PROXY protocol is fairly standard, even if it's not >>>>>> backed by an RFC. It's published by haproxy, but supported by >>>>>> nginx, >>>>>> (obviously) haproxy, AWS, httpd[1], and a whole bunch of others ( >>>>> https://ww/ >>>>> w.haproxy.com%2Fblog%2Fuse-the-proxy-protocol-to-preserve-a-client >>>>> s >>>>> - >>>>> ip-address=05%7C01%7CAmit.Pande%40veritas.com%7C51dbcc5eeac14 >>>>> f >>>>> a >>>>> b5aa708db8ee67aae%7Cfc8e13c0422c4c55b3eaca318e6cac32%7C0%7C0%7C638 >>>>> 2 >>>>> 6 >>>>> 0892775883704%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoi >>>>> V >>>>> 2 >>>>> luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=RWHWpIL >>>>> a >>>>> 0 >>>>> rLRM0xPgFAeXdk0y1l2ob%2BNcQHZP55fQDg%3D=0 >>>>> ). >>>>> >>>>> ACK. That reduces my concerns somewhat. >>>>> >>>>>&
RE: [External] Re: Supporting Proxy Protocol in Tomcat
Mark, Just checking - Did this issue get discussed in any of the core members' meeting? Thanks, Amit -Original Message- From: Amit Pande Sent: Monday, July 31, 2023 9:29 AM To: Tomcat Users List Subject: RE: [External] Re: Supporting Proxy Protocol in Tomcat Yes, understood. Thank you for clarifying. Even I was referring to initial consensus without any timeline or approach conclusion. Thanks, Amit -Original Message- From: Mark Thomas Sent: Friday, July 28, 2023 2:48 PM To: users@tomcat.apache.org Subject: Re: [External] Re: Supporting Proxy Protocol in Tomcat On 28/07/2023 19:21, Amit Pande wrote: > Thank you all for the valuable discussion on this topic. > > Is it okay to say that we're agreeing to adding proxy protocol support in > Tomcat? I think that is a little too strong. At this point there is a proposed approach and no one is objecting but until there is an actual patch to discuss... Keep in mind that any committer can veto a change. My sense is that it should be possible to implement this feature while addressing any concerns that may be raised but it is not guaranteed. Mark > > Thanks, > Amit > > -Original Message- > From: Christopher Schultz > Sent: Thursday, July 27, 2023 4:13 PM > To: users@tomcat.apache.org > Subject: Re: [External] Re: Supporting Proxy Protocol in Tomcat > > All, > > On 7/27/23 12:39, Mark Thomas wrote: >> On 27/07/2023 16:27, Jonathan S. Fisher wrote: >>> On the topic of security, may we consider a trustedProxies setting? >> >> Seems reasonable. > > We should probably look at what httpd did for all of this. > > -chris > >>> This >>> would be an analog to the internalProxies setting on RemoteIpValve. >>> It would need to be able to function with APR/NIO listening in a >>> Unix Domain Socket. >>> >>> I'm not sure if this is super useful, but the goal would be an added >>> layer of security to prevent Proxy Protocol header injection. >>> >>> On Thu, Jul 27, 2023 at 3:47 AM Mark Thomas wrote: >>> >>>> On 26/07/2023 21:53, Christopher Schultz wrote: >>>>> Mark, >>>>> >>>>> On 7/26/23 13:58, Mark Thomas wrote: >>>>>> I'm not a huge fan of this feature in general. I prefer >>>>>> supporting features backed by specifications rather than vendor specific >>>>>> hacks. >>>>> >>>>> I think the PROXY protocol is fairly standard, even if it's not >>>>> backed by an RFC. It's published by haproxy, but supported by >>>>> nginx, >>>>> (obviously) haproxy, AWS, httpd[1], and a whole bunch of others ( >>>> https://ww/ >>>> w.haproxy.com%2Fblog%2Fuse-the-proxy-protocol-to-preserve-a-clients >>>> - >>>> ip-address=05%7C01%7CAmit.Pande%40veritas.com%7C51dbcc5eeac14f >>>> a >>>> b5aa708db8ee67aae%7Cfc8e13c0422c4c55b3eaca318e6cac32%7C0%7C0%7C6382 >>>> 6 >>>> 0892775883704%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV >>>> 2 >>>> luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=RWHWpILa >>>> 0 >>>> rLRM0xPgFAeXdk0y1l2ob%2BNcQHZP55fQDg%3D=0 >>>> ). >>>> >>>> ACK. That reduces my concerns somewhat. >>>> >>>>> Well, the reality is that people want to use this in the real >>>>> world and this is essentially the only way to do it, barring >>>>> coming up with a whole new protocol for the purpose (I'm looking at /you/ >>>>> AJP!). >>>> >>>> Indeed. >>>> >>>>> So why not use /the/ protocol that (a) exists and (b) is supported >>>>> by every single product that currently supports this type of thing? >>>>> >>>>>> My support for any patch is going to depend on the specifics of >>>>>> the patch. >>>>>> >>>>>> In addition to the comments in the BZ >>>>>> - exposing the data as a request attribute is inconsistent with >>>>>> other >>>>>> mechanisms that solve the same problem (e.g. see >>>>>> RemoteIpFilter) >>>>> >>>>> +1 >>>>> >>>>> The whole point of PROXY is to kind of mix-together the >>>>> capabilities of both the RemoteIPFilter/Valve (which uses HTTP >>>>> headers for >>>>> source-information) and the top-level idea of a Connector >>>>> (something that binds to a socket and pushe
RE: [External] Re: listening all local addresses by default is not security best practice
Thank you, Chris, for inputs.
I have created a BZ ticket: https://bz.apache.org/bugzilla/show_bug.cgi?id=67065
Thanks,
Amit
-Original Message-
From: Christopher Schultz
Sent: Monday, August 14, 2023 10:47 AM
To: Tomcat Users List
Subject: Re: [External] Re: listening all local addresses by default is not
security best practice
CAUTION: This email originated from outside the organization. Do not click
links or open attachments unless you recognize the sender and know the content
is safe. If you believe this is a phishing email, use the Report to
Cybersecurity icon in Outlook.
On 8/6/23 13:25, Amit Pande wrote:
> My apologies if I missed any conclusion here.
>
> From the description of address attribute on HTTP connector:
>
> "For servers with more than one IP address, this attribute specifies which
> address will be used for listening on the specified port. By default, the
> connector will listen all local addresses. Unless the JVM is configured
> otherwise using system properties, the Java based connectors (NIO, NIO2) will
> listen on both IPv4 and IPv6 addresses when configured with either 0.0.0.0 or
> ::. The APR/native connector will only listen on IPv4 addresses if configured
> with 0.0.0.0 and will listen on IPv6 addresses (and optionally IPv4 addresses
> depending on the setting of ipv6v6only) if configured with ::."
>
>
> Is it possible to update the behavior to listen to loopback address only like
> was done for AJP connectors.
>
> On my Tomcat 9.0.78 netstat output - I see Tomcat using 0.0.0.0 by default
> unless we define address as "127.0.0.1" :
>
> tcp0 0 0.0.0.0:39054 0.0.0.0:* LISTEN
> 28539/java
Given the documentation quoted above, I would expect that Tomcat would bind to
::1 unless otherwise specified ("all LOCAL addresses", emphasis mine). The
behavior you demonstrate above, and the code agree that Tomcat will listen on
all PUBLIC interfaces, not local ones, by default.
I believe the documentation should be changed to reflect reality, because
changing this default could break a lot of installations.
Changing the default AJP binding to localhost made sense because a
publicly-exposed AJP connector is very insecure, while having HTTP(S) exposed
publicly should not present much risk at all.
> Also, is it right that we will need to have two connectors for IPv4 and IPv6
> with address "127.0.0.1" and "::1" respectively to enable binding only on
> loopback addresses?
>
> If we configure two connectors (IPv4 and IPv6 loopback), if one isn't
> available, we see:
>
>
> org.apache.catalina.LifecycleException: Protocol handler
> initialization failed
> at
> org.apache.catalina.connector.Connector.initInternal(Connector.java:1011)
> at
> org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:136)
> at
> org.apache.catalina.core.StandardService.initInternal(StandardService.java:549)
> at
> org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:136)
> at
> org.apache.catalina.core.StandardServer.initInternal(StandardServer.java:1040)
> at
> org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:136)
> at
> org.apache.catalina.startup.Catalina.load(Catalina.java:724)
> at
> org.apache.catalina.startup.Catalina.load(Catalina.java:746)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:307)
> at
> org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:477)
> Caused by: java.net.SocketException: Protocol family unavailable
> at sun.nio.ch.Net.bind0(Native Method)
>
> which has caused confusion/concerns.
>
> What would be a better way to bind on "all available loopback addresses?
That *would* be handy if ::1 would bind to "all local [IPv4 and IPv6, as
appropriate] addresses" just like APR does. Can you please file a BZ ticket for
that? I'm surprised it doesn't already work like that, honestly, because it
seems completely obvious to me that's how it /should/ work.
-chris
> -Original Message-
> From: Christopher Schultz
> Sent: Monday, November 28, 2022 5:21 PM
> To: users@tomcat.apache.org
> Subject: [External] Re: listeni
RE: [External] Re: listening all local addresses by default is not security best practice
My apologies if I missed any conclusion here. >From the description of address attribute on HTTP connector: "For servers with more than one IP address, this attribute specifies which address will be used for listening on the specified port. By default, the connector will listen all local addresses. Unless the JVM is configured otherwise using system properties, the Java based connectors (NIO, NIO2) will listen on both IPv4 and IPv6 addresses when configured with either 0.0.0.0 or ::. The APR/native connector will only listen on IPv4 addresses if configured with 0.0.0.0 and will listen on IPv6 addresses (and optionally IPv4 addresses depending on the setting of ipv6v6only) if configured with ::." Is it possible to update the behavior to listen to loopback address only like was done for AJP connectors. On my Tomcat 9.0.78 netstat output - I see Tomcat using 0.0.0.0 by default unless we define address as "127.0.0.1" : tcp0 0 0.0.0.0:39054 0.0.0.0:* LISTEN 28539/java Also, is it right that we will need to have two connectors for IPv4 and IPv6 with address "127.0.0.1" and "::1" respectively to enable binding only on loopback addresses? If we configure two connectors (IPv4 and IPv6 loopback), if one isn't available, we see: org.apache.catalina.LifecycleException: Protocol handler initialization failed at org.apache.catalina.connector.Connector.initInternal(Connector.java:1011) at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:136) at org.apache.catalina.core.StandardService.initInternal(StandardService.java:549) at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:136) at org.apache.catalina.core.StandardServer.initInternal(StandardServer.java:1040) at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:136) at org.apache.catalina.startup.Catalina.load(Catalina.java:724) at org.apache.catalina.startup.Catalina.load(Catalina.java:746) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:307) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:477) Caused by: java.net.SocketException: Protocol family unavailable at sun.nio.ch.Net.bind0(Native Method) which has caused confusion/concerns. What would be a better way to bind on "all available loopback addresses? Thanks, Amit -Original Message- From: Christopher Schultz Sent: Monday, November 28, 2022 5:21 PM To: users@tomcat.apache.org Subject: [External] Re: listening all local addresses by default is not security best practice To whom it may concern, On 11/23/22 14:31, tommydu1...@outlook.com wrote: > Hi there, > > Product:<https://nam12.safelinks.protection.outlook.com/?url=https%3A% > 2F%2Fbz.apache.org%2Fbugzilla%2Fdescribecomponents.cgidata=05%7C0 > 1%7CAmit.Pande%40veritas.com%7C13ea9fddeb604e4b7dca08dad1978243%7Cfc8e > 13c0422c4c55b3eaca318e6cac32%7C0%7C0%7C638052745907718347%7CUnknown%7C > TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVC > I6Mn0%3D%7C3000%7C%7C%7Csdata=o%2FwWU7LgTdFLS3L5njjEruLLho9JnSw2O > LV0%2BO%2BnR5c%3Dreserved=0> > > [snip] > The default behaviour of http connector is listenning all interfaces. False. > It is found in the description of "address" in attributes section. > (https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftom > cat.apache.org%2Ftomcat-9.0-doc%2Fconfig%2Fhttp.html%23SSL_Support > ;data=05%7C01%7CAmit.Pande%40veritas.com%7C13ea9fddeb604e4b7dca08dad19 > 78243%7Cfc8e13c0422c4c55b3eaca318e6cac32%7C0%7C0%7C638052745907718347% > 7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik > 1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=p3R8MryiKpauAppYJLbrGLP > FzIUJpONDxvQj%2BlYepnI%3Dreserved=0) It's listed in another section, and does not say all interfaces. > In terms of security default, it could be not best practice. In case of > unexpected mistakes made by people, default behaviour of exposing the server > to every possible network may pose a potential threat on security. Good thing Tomcat does not default to that configuration. > CWE-1327: Binding to an Unrestricted IP Address: > https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwe. > mitre.org%2Fdata%2Fdefinitions%2F1327.htmldata=05%7C01%7CAmit.Pan >
RE: [External] Re: Using dedicated SSL handshake failure logger
Yes, I have verified that CATALINA_HOME is set correctly. And just for testing purposes, I changed the prefix to something like: 1catalina.org.apache.juli.AsyncFileHandler.prefix = catalina.amit. And I do see a catalina.amit.2023-08-03.log file created under web server logs. Thanks, Amit -Original Message- From: Mark Thomas Sent: Thursday, August 3, 2023 2:14 PM To: users@tomcat.apache.org Subject: [External] Re: Using dedicated SSL handshake failure logger On 03/08/2023 16:53, Amit Pande wrote: > What am I missing in the logger configuration? Do we have to have the console > handler configured? Is CATALINA_HOME set correctly? Do you see any log file at all in the expected location? Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Using dedicated SSL handshake failure logger
Hello all,
Facing an odd issue with logging the SSL handshake details:
I have this in my logging.properties:
handlers = 1catalina.org.apache.juli.AsyncFileHandler
.handlers = 1catalina.org.apache.juli.AsyncFileHandler
1catalina.org.apache.juli.AsyncFileHandler.level = FINE
1catalina.org.apache.juli.AsyncFileHandler.directory = ${catalina.home}/logs
1catalina.org.apache.juli.AsyncFileHandler.prefix = catalina.
org.apache.tomcat.util.net.NioEndpoint.handshake.level = FINE
org.apache.tomcat.util.net.NioEndpoint.certificate.level = FINE
With above configuration, I don't see the SSL handshake failures details in
logs.
However, when I add the console handler like:
handlers = 1catalina.org.apache.juli.AsyncFileHandler,\
java.util.logging.ConsoleHandler
.handlers = 1catalina.org.apache.juli.AsyncFileHandler,
java.util.logging.ConsoleHandler
1catalina.org.apache.juli.AsyncFileHandler.level = FINE
1catalina.org.apache.juli.AsyncFileHandler.directory = ${catalina.home}/logs
1catalina.org.apache.juli.AsyncFileHandler.prefix = catalina.
java.util.logging.ConsoleHandler.level = FINE
org.apache.tomcat.util.net.NioEndpoint.handshake.level = FINE
org.apache.tomcat.util.net.NioEndpoint.certificate.level = FINE
I see the SSL handshake failure logs e.g.
FINE: Handshake failed for client connection from IP address [127.0.0.1] and
port [37136]
javax.net.ssl.SSLHandshakeException: Received fatal alert: unknown_ca
at sun.security.ssl.Alert.createSSLException(Alert.java:131)
at sun.security.ssl.Alert.createSSLException(Alert.java:117)
at sun.security.ssl.TransportContext.fatal(TransportContext.java:364)
at sun.security.ssl.Alert$AlertConsumer.consume(Alert.java:293)
at sun.security.ssl.TransportContext.dispatch(TransportContext.java:203)
at sun.security.ssl.SSLTransport.decode(SSLTransport.java:155)
at sun.security.ssl.SSLEngineImpl.decode(SSLEngineImpl.java:597)
at sun.security.ssl.SSLEngineImpl.readRecord(SSLEngineImpl.java:552)
at sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:418)
at sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:397)
at javax.net.ssl.SSLEngine.unwrap(SSLEngine.java:626)
at
org.apache.tomcat.util.net.SecureNioChannel.handshakeUnwrap(SecureNioChannel.java:483)
at
org.apache.tomcat.util.net.SecureNioChannel.handshake(SecureNioChannel.java:215)
at
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1766)
at
org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:52)
at
org.apache.tomcat.util.threads.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1191)
at
org.apache.tomcat.util.threads.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:659)
at
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.lang.Thread.run(Thread.java:750)
What am I missing in the logger configuration? Do we have to have the console
handler configured?
Thanks,
Amit
RE: [External] Re: Supporting Proxy Protocol in Tomcat
Yes, understood. Thank you for clarifying. Even I was referring to initial consensus without any timeline or approach conclusion. Thanks, Amit -Original Message- From: Mark Thomas Sent: Friday, July 28, 2023 2:48 PM To: users@tomcat.apache.org Subject: Re: [External] Re: Supporting Proxy Protocol in Tomcat On 28/07/2023 19:21, Amit Pande wrote: > Thank you all for the valuable discussion on this topic. > > Is it okay to say that we're agreeing to adding proxy protocol support in > Tomcat? I think that is a little too strong. At this point there is a proposed approach and no one is objecting but until there is an actual patch to discuss... Keep in mind that any committer can veto a change. My sense is that it should be possible to implement this feature while addressing any concerns that may be raised but it is not guaranteed. Mark > > Thanks, > Amit > > -Original Message- > From: Christopher Schultz > Sent: Thursday, July 27, 2023 4:13 PM > To: users@tomcat.apache.org > Subject: Re: [External] Re: Supporting Proxy Protocol in Tomcat > > All, > > On 7/27/23 12:39, Mark Thomas wrote: >> On 27/07/2023 16:27, Jonathan S. Fisher wrote: >>> On the topic of security, may we consider a trustedProxies setting? >> >> Seems reasonable. > > We should probably look at what httpd did for all of this. > > -chris > >>> This >>> would be an analog to the internalProxies setting on RemoteIpValve. >>> It would need to be able to function with APR/NIO listening in a >>> Unix Domain Socket. >>> >>> I'm not sure if this is super useful, but the goal would be an added >>> layer of security to prevent Proxy Protocol header injection. >>> >>> On Thu, Jul 27, 2023 at 3:47 AM Mark Thomas wrote: >>> >>>> On 26/07/2023 21:53, Christopher Schultz wrote: >>>>> Mark, >>>>> >>>>> On 7/26/23 13:58, Mark Thomas wrote: >>>>>> I'm not a huge fan of this feature in general. I prefer >>>>>> supporting features backed by specifications rather than vendor specific >>>>>> hacks. >>>>> >>>>> I think the PROXY protocol is fairly standard, even if it's not >>>>> backed by an RFC. It's published by haproxy, but supported by >>>>> nginx, >>>>> (obviously) haproxy, AWS, httpd[1], and a whole bunch of others ( >>>> https://ww/ >>>> w.haproxy.com%2Fblog%2Fuse-the-proxy-protocol-to-preserve-a-clients >>>> - >>>> ip-address=05%7C01%7CAmit.Pande%40veritas.com%7C51dbcc5eeac14f >>>> a >>>> b5aa708db8ee67aae%7Cfc8e13c0422c4c55b3eaca318e6cac32%7C0%7C0%7C6382 >>>> 6 >>>> 0892775883704%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV >>>> 2 >>>> luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=RWHWpILa >>>> 0 >>>> rLRM0xPgFAeXdk0y1l2ob%2BNcQHZP55fQDg%3D=0 >>>> ). >>>> >>>> ACK. That reduces my concerns somewhat. >>>> >>>>> Well, the reality is that people want to use this in the real >>>>> world and this is essentially the only way to do it, barring >>>>> coming up with a whole new protocol for the purpose (I'm looking at /you/ >>>>> AJP!). >>>> >>>> Indeed. >>>> >>>>> So why not use /the/ protocol that (a) exists and (b) is supported >>>>> by every single product that currently supports this type of thing? >>>>> >>>>>> My support for any patch is going to depend on the specifics of >>>>>> the patch. >>>>>> >>>>>> In addition to the comments in the BZ >>>>>> - exposing the data as a request attribute is inconsistent with >>>>>> other >>>>>> mechanisms that solve the same problem (e.g. see >>>>>> RemoteIpFilter) >>>>> >>>>> +1 >>>>> >>>>> The whole point of PROXY is to kind of mix-together the >>>>> capabilities of both the RemoteIPFilter/Valve (which uses HTTP >>>>> headers for >>>>> source-information) and the top-level idea of a Connector >>>>> (something that binds to a socket and pushes bytes around). >>>>> >>>>> The confusing thing here is that those two jobs are performed at >>>>> relatively different levels in Tomcat at the moment, as I >>>>> understand things. >>>> >>>> Yes
RE: [External] Re: Supporting Proxy Protocol in Tomcat
Thank you all for the valuable discussion on this topic.
Is it okay to say that we're agreeing to adding proxy protocol support in
Tomcat?
Thanks,
Amit
-Original Message-
From: Christopher Schultz
Sent: Thursday, July 27, 2023 4:13 PM
To: users@tomcat.apache.org
Subject: Re: [External] Re: Supporting Proxy Protocol in Tomcat
All,
On 7/27/23 12:39, Mark Thomas wrote:
> On 27/07/2023 16:27, Jonathan S. Fisher wrote:
>> On the topic of security, may we consider a trustedProxies setting?
>
> Seems reasonable.
We should probably look at what httpd did for all of this.
-chris
>> This
>> would be an analog to the internalProxies setting on RemoteIpValve.
>> It would need to be able to function with APR/NIO listening in a Unix
>> Domain Socket.
>>
>> I'm not sure if this is super useful, but the goal would be an added
>> layer of security to prevent Proxy Protocol header injection.
>>
>> On Thu, Jul 27, 2023 at 3:47 AM Mark Thomas wrote:
>>
>>> On 26/07/2023 21:53, Christopher Schultz wrote:
>>>> Mark,
>>>>
>>>> On 7/26/23 13:58, Mark Thomas wrote:
>>>>> I'm not a huge fan of this feature in general. I prefer supporting
>>>>> features backed by specifications rather than vendor specific hacks.
>>>>
>>>> I think the PROXY protocol is fairly standard, even if it's not
>>>> backed by an RFC. It's published by haproxy, but supported by
>>>> nginx,
>>>> (obviously) haproxy, AWS, httpd[1], and a whole bunch of others (
>>> https://ww/
>>> w.haproxy.com%2Fblog%2Fuse-the-proxy-protocol-to-preserve-a-clients-
>>> ip-address=05%7C01%7CAmit.Pande%40veritas.com%7C51dbcc5eeac14fa
>>> b5aa708db8ee67aae%7Cfc8e13c0422c4c55b3eaca318e6cac32%7C0%7C0%7C63826
>>> 0892775883704%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2
>>> luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=RWHWpILa0
>>> rLRM0xPgFAeXdk0y1l2ob%2BNcQHZP55fQDg%3D=0
>>> ).
>>>
>>> ACK. That reduces my concerns somewhat.
>>>
>>>> Well, the reality is that people want to use this in the real world
>>>> and this is essentially the only way to do it, barring coming up
>>>> with a whole new protocol for the purpose (I'm looking at /you/ AJP!).
>>>
>>> Indeed.
>>>
>>>> So why not use /the/ protocol that (a) exists and (b) is supported
>>>> by every single product that currently supports this type of thing?
>>>>
>>>>> My support for any patch is going to depend on the specifics of
>>>>> the patch.
>>>>>
>>>>> In addition to the comments in the BZ
>>>>> - exposing the data as a request attribute is inconsistent with
>>>>> other
>>>>> mechanisms that solve the same problem (e.g. see
>>>>> RemoteIpFilter)
>>>>
>>>> +1
>>>>
>>>> The whole point of PROXY is to kind of mix-together the
>>>> capabilities of both the RemoteIPFilter/Valve (which uses HTTP
>>>> headers for
>>>> source-information) and the top-level idea of a Connector
>>>> (something that binds to a socket and pushes bytes around).
>>>>
>>>> The confusing thing here is that those two jobs are performed at
>>>> relatively different levels in Tomcat at the moment, as I
>>>> understand things.
>>>
>>> Yes and no. RemoteIP[Filter|Valve] insert/modify the data at a
>>> higher level because that is where they sit but the data originates
>>> from the SocketWrapper.
>>>
>>>> If some kind of UberConnector could be built which essentially does
>>>> something like the following, it would be ideal:
>>>>
>>>> public void accept(Socket s) {
>>>> ProxyHeader proxyHeader = readProxyHeader(s);
>>>>
>>>> Connector realConnector = getRealConnector();
>>>>
>>>> realConnector.setRemoteIP(proxyHeader.getRemoteIP());
>>>> realConnector.setRemotePort(proxyHeader.getRemotePort());
>>>>
>>>> realConnector.takeItAway(s);
>>>> }
>>>>
>>>> I'm sure there are other pieces of information that would be good
>>>> to pass-through, but the identity of the remote client is the most
>>>> interesting one.
>>>
>>> Yes, that is the general idea. Just a couple of minor tweaks to use
>>> the SocketWrapper rather than the Connector and to do it in a
>>> slightly dif
RE: [External] Re: Supporting Proxy Protocol in Tomcat
Missed to ask this: Looking the patch, it involves modifying Tomcat code. Was wondering if it would be possible to refactor this patch and/or allow Tomcat core code to extend and plug-in the proxy protocol support? Thanks, Amit -Original Message- From: Amit Pande Sent: Wednesday, July 26, 2023 11:43 AM To: Tomcat Users List Subject: RE: [External] Re: Supporting Proxy Protocol in Tomcat Chris, Mark, Any thoughts on this? Mark, if we clean up the patch and re-submit, do you will have any concerns (specially security wise)? Thanks, Amit -Original Message- From: Jonathan S. Fisher Sent: Monday, July 24, 2023 12:41 PM To: Tomcat Users List Subject: Re: [External] Re: Supporting Proxy Protocol in Tomcat Just a side note, because we're also very interested in this patch! Awhile back, I was successfully able to apply this patch and terminate TCP/TLS using HaProxy. We then had Tomcat listen on a unix domain socket and the Proxy protocol provided *most *of the relevant/required information to tomcat. I believe we had to add a Valve to tomcat to set the Remote IP however as the patch didn't handle that case. I can find my notes from that experiment, but I do remember getting a significant boost in throughput and decrease in latency. +1 for this patch and willing to help out! On Mon, Jul 24, 2023 at 11:22 AM Amit Pande wrote: > Thank you, Chris, again for inputs. > And sorry to circle back on this, late. > > One related question is - does it make sense to use the patch attached > in > https://bz.apache.org/bugzilla/show_bug.cgi?id=57830 ? > And potentially, get it integrated into Tomcat versions? > > There are concerns from Mark about using the patch in its current > state, but I see last comment (#24) on the issue and looks like there > are some more points to be concluded. > > Thanks, > Amit > > -Original Message- > From: Christopher Schultz > Sent: Wednesday, May 10, 2023 4:21 PM > To: users@tomcat.apache.org > Subject: Re: [External] Re: Supporting Proxy Protocol in Tomcat > > Amit, > > On 5/10/23 12:59, Amit Pande wrote: > > Yes, we intended to have Tomcat run behind a (transparent) TCP proxy e.g. > > > https://www/. > envoyproxy.io%2Fdocs%2Fenvoy%2Flatest%2Fintro%2Farch_overview%2Fother_ > features%2Fip_transparency=05%7C01%7CAmit.Pande%40veritas.com%7Ca > 85e610757b348137b4008db8c6d8156%7Cfc8e13c0422c4c55b3eaca318e6cac32%7C0 > %7C0%7C638258174209955308%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAi > LCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=W > NEV4UQ5q4Nl8SEFHMz7C%2Fj3Qr7pCHpfyvQLeBn56uQ%3D=0 > which supports the proxy protocol. > > > > Since there is not much action on this > https://bz.a/ > pache.org%2Fbugzilla%2Fshow_bug.cgi%3Fid%3D57830=05%7C01%7CAmit.Pande%40veritas.com%7Ca85e610757b348137b4008db8c6d8156%7Cfc8e13c0422c4c55b3eaca318e6cac32%7C0%7C0%7C638258174209955308%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=mH7TRJny1YUOsG%2BeFXno4xdvsLAjz%2BRkQgCnLfehXvQ%3D=0, > does it imply that most of the times Tomcat is running behind HTTP proxies > and not TCP proxies? > > Or does it mean that, Tomcat or applications running in Tomcat does > > not > need the remote client address information? > > I can't speak for anybody else, but I use Apache httpd as my > reverse-proxy and I do terminate TLS. I also use it for > load-balancing/fail-over, caching, some authorization, etc. I wouldn't > be able to use a TCP load-balancer because I hide multiple services > behind my reverse-proxy which run in different places. It's not just s dumb > pass-through. > > Hope that helps, > -chris > > > -Original Message- > > From: Christopher Schultz > > Sent: Monday, May 8, 2023 3:40 PM > > To: users@tomcat.apache.org > > Subject: [External] 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/. > >> a%2F=05%7C01%7CAmit.Pande%40veritas.com%7C07ebe3c927ed4b787206 > >> 08 > >> db519ccce8%7Cfc8e13c0422c4c55b3eaca318e6cac32%7C0%7C0%7C63819350613 > >> 56 > >> 24269%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiL > >> CJ > >> BTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=3UFyiGJ9ZgtLqUzY9 > >> JM > >> CK2MfwKN3OAOKdr6JmTUGkPw%3D=0 > >> pache.org%2Fbugzilla%2Fshow_bug.cgi%3Fid%3D57830=05%7C01%7CAmit. > >> P > >> ande%40veritas.com%7Cab789327b86845e8ad7208db50046f55%7Cfc8e13c0422 > >> c4 > >> c > >> 55b3eaca318e6cac32%7C0%7C0%7C6381917522066692
RE: [External] Re: Supporting Proxy Protocol in Tomcat
Chris, Mark, Any thoughts on this? Mark, if we clean up the patch and re-submit, do you will have any concerns (specially security wise)? Thanks, Amit -Original Message- From: Jonathan S. Fisher Sent: Monday, July 24, 2023 12:41 PM To: Tomcat Users List Subject: Re: [External] Re: Supporting Proxy Protocol in Tomcat Just a side note, because we're also very interested in this patch! Awhile back, I was successfully able to apply this patch and terminate TCP/TLS using HaProxy. We then had Tomcat listen on a unix domain socket and the Proxy protocol provided *most *of the relevant/required information to tomcat. I believe we had to add a Valve to tomcat to set the Remote IP however as the patch didn't handle that case. I can find my notes from that experiment, but I do remember getting a significant boost in throughput and decrease in latency. +1 for this patch and willing to help out! On Mon, Jul 24, 2023 at 11:22 AM Amit Pande wrote: > Thank you, Chris, again for inputs. > And sorry to circle back on this, late. > > One related question is - does it make sense to use the patch attached > in > https://bz.apache.org/bugzilla/show_bug.cgi?id=57830 ? > And potentially, get it integrated into Tomcat versions? > > There are concerns from Mark about using the patch in its current > state, but I see last comment (#24) on the issue and looks like there > are some more points to be concluded. > > Thanks, > Amit > > -Original Message- > From: Christopher Schultz > Sent: Wednesday, May 10, 2023 4:21 PM > To: users@tomcat.apache.org > Subject: Re: [External] Re: Supporting Proxy Protocol in Tomcat > > Amit, > > On 5/10/23 12:59, Amit Pande wrote: > > Yes, we intended to have Tomcat run behind a (transparent) TCP proxy e.g. > > > https://www/. > envoyproxy.io%2Fdocs%2Fenvoy%2Flatest%2Fintro%2Farch_overview%2Fother_ > features%2Fip_transparency=05%7C01%7CAmit.Pande%40veritas.com%7Ca > 85e610757b348137b4008db8c6d8156%7Cfc8e13c0422c4c55b3eaca318e6cac32%7C0 > %7C0%7C638258174209955308%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAi > LCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=W > NEV4UQ5q4Nl8SEFHMz7C%2Fj3Qr7pCHpfyvQLeBn56uQ%3D=0 > which supports the proxy protocol. > > > > Since there is not much action on this > https://bz.a/ > pache.org%2Fbugzilla%2Fshow_bug.cgi%3Fid%3D57830=05%7C01%7CAmit.Pande%40veritas.com%7Ca85e610757b348137b4008db8c6d8156%7Cfc8e13c0422c4c55b3eaca318e6cac32%7C0%7C0%7C638258174209955308%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=mH7TRJny1YUOsG%2BeFXno4xdvsLAjz%2BRkQgCnLfehXvQ%3D=0, > does it imply that most of the times Tomcat is running behind HTTP proxies > and not TCP proxies? > > Or does it mean that, Tomcat or applications running in Tomcat does > > not > need the remote client address information? > > I can't speak for anybody else, but I use Apache httpd as my > reverse-proxy and I do terminate TLS. I also use it for > load-balancing/fail-over, caching, some authorization, etc. I wouldn't > be able to use a TCP load-balancer because I hide multiple services > behind my reverse-proxy which run in different places. It's not just s dumb > pass-through. > > Hope that helps, > -chris > > > -Original Message- > > From: Christopher Schultz > > Sent: Monday, May 8, 2023 3:40 PM > > To: users@tomcat.apache.org > > Subject: [External] 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/. > >> a%2F=05%7C01%7CAmit.Pande%40veritas.com%7C07ebe3c927ed4b787206 > >> 08 > >> db519ccce8%7Cfc8e13c0422c4c55b3eaca318e6cac32%7C0%7C0%7C63819350613 > >> 56 > >> 24269%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiL > >> CJ > >> BTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=3UFyiGJ9ZgtLqUzY9 > >> JM > >> CK2MfwKN3OAOKdr6JmTUGkPw%3D=0 > >> pache.org%2Fbugzilla%2Fshow_bug.cgi%3Fid%3D57830=05%7C01%7CAmit. > >> P > >> ande%40veritas.com%7Cab789327b86845e8ad7208db50046f55%7Cfc8e13c0422 > >> c4 > >> c > >> 55b3eaca318e6cac32%7C0%7C0%7C638191752206669206%7CUnknown%7CTWFpbGZ > >> sb > >> 3 > >> d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3 > >> D% > >> 7 > >> C3000%7C%7C%7C=6TXyKzlyjY3AIi6zQMFn2j9BhtwYo6Jkrd1V3nOl4mY%3D > >> > >> e > >> served=0 > >> > >> Is there any plan to add this support in Tomcat in future releases? &g
RE: [External] Re: Supporting Proxy Protocol in Tomcat
Thank you, Chris, again for inputs. And sorry to circle back on this, late. One related question is - does it make sense to use the patch attached in https://bz.apache.org/bugzilla/show_bug.cgi?id=57830 ? And potentially, get it integrated into Tomcat versions? There are concerns from Mark about using the patch in its current state, but I see last comment (#24) on the issue and looks like there are some more points to be concluded. Thanks, Amit -Original Message- From: Christopher Schultz Sent: Wednesday, May 10, 2023 4:21 PM To: users@tomcat.apache.org Subject: Re: [External] Re: Supporting Proxy Protocol in Tomcat Amit, On 5/10/23 12:59, Amit Pande wrote: > Yes, we intended to have Tomcat run behind a (transparent) TCP proxy e.g. > https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/other_features/ip_transparency > which supports the proxy protocol. > > Since there is not much action on this > https://bz.apache.org/bugzilla/show_bug.cgi?id=57830, does it imply that most > of the times Tomcat is running behind HTTP proxies and not TCP proxies? > Or does it mean that, Tomcat or applications running in Tomcat does not need > the remote client address information? I can't speak for anybody else, but I use Apache httpd as my reverse-proxy and I do terminate TLS. I also use it for load-balancing/fail-over, caching, some authorization, etc. I wouldn't be able to use a TCP load-balancer because I hide multiple services behind my reverse-proxy which run in different places. It's not just s dumb pass-through. Hope that helps, -chris > -Original Message- > From: Christopher Schultz > Sent: Monday, May 8, 2023 3:40 PM > To: users@tomcat.apache.org > Subject: [External] 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/. >> a%2F=05%7C01%7CAmit.Pande%40veritas.com%7C07ebe3c927ed4b78720608 >> db519ccce8%7Cfc8e13c0422c4c55b3eaca318e6cac32%7C0%7C0%7C6381935061356 >> 24269%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJ >> BTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=3UFyiGJ9ZgtLqUzY9JM >> CK2MfwKN3OAOKdr6JmTUGkPw%3D=0 >> pache.org%2Fbugzilla%2Fshow_bug.cgi%3Fid%3D57830=05%7C01%7CAmit. >> P >> ande%40veritas.com%7Cab789327b86845e8ad7208db50046f55%7Cfc8e13c0422c4 >> c >> 55b3eaca318e6cac32%7C0%7C0%7C638191752206669206%7CUnknown%7CTWFpbGZsb >> 3 >> d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D% >> 7 >> C3000%7C%7C%7C=6TXyKzlyjY3AIi6zQMFn2j9BhtwYo6Jkrd1V3nOl4mY%3D >> e >> served=0 >> >> 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 > > > - > 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
Setting security response headers when Valve returns error..
Hello, Wanted some inputs on setting HSTS (or other response headers) when returning error from a valve. The server.xml has the valve "org.apache.catalina.valves.RemoteAddrValve" configured with a deny status of HTTP 404. Also, the Tomcat's web.xml has "org.apache.catalina.filters.HttpHeaderSecurityFilter" confugred. The requirement is to set the security related headers even when the request is denied from the "org.apache.catalina.valves.RemoteAddrValve", which I don't see being set. What is the right way to address such requirement? Did I miss anything here? Thanks, Amit
Re: [External] Re: Rate Limiting support in Tomcat 9.x
Thank you Mark for quick response. Yes, I see that in the change log for 9.0.76 (dev). Thanks, Amit From: Mark Thomas Sent: Tuesday, May 23, 2023 2:29:21 AM To: users@tomcat.apache.org Subject: [External] Re: Rate Limiting support in Tomcat 9.x On 22/05/2023 21:16, Amit Pande wrote: > Hello, > > https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftomcat.apache.org%2F=05%7C01%7CAmit.Pande%40veritas.com%7C0da8e5a4fd5e45bc1dd608db5b5f8404%7Cfc8e13c0422c4c55b3eaca318e6cac32%7C0%7C0%7C638204238018843721%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=QeFGIGH1ie78xPTb9rSf%2BYALkWaPa4Wj8eHwpkp%2BV7s%3D=0<https://tomcat.apache.org/> > I see rate limiting support added in Tomcat 10.1.9 . > > (Side note: The Apache Tomcat Project is proud to announce the release of > version 10.1.8 of Apache Tomcat - I think it should be 10.1.9) Thanks. The typo has been fixed. > Are there any plans to add this filter in 9.x? Could an enhancement request > be raised to get this in next Tomcat 9.x release? It is already included in 9.0.x (and 8.5.x). Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Rate Limiting support in Tomcat 9.x
Hello, https://tomcat.apache.org/ I see rate limiting support added in Tomcat 10.1.9 . (Side note: The Apache Tomcat Project is proud to announce the release of version 10.1.8 of Apache Tomcat - I think it should be 10.1.9) Are there any plans to add this filter in 9.x? Could an enhancement request be raised to get this in next Tomcat 9.x release? Thanks, Amit
RE: [External] Re: Supporting Proxy Protocol in Tomcat
Thank you, Chris, for the inputs. Yes, we intended to have Tomcat run behind a (transparent) TCP proxy e.g. https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/other_features/ip_transparency which supports the proxy protocol. Since there is not much action on this https://bz.apache.org/bugzilla/show_bug.cgi?id=57830, does it imply that most of the times Tomcat is running behind HTTP proxies and not TCP proxies? Or does it mean that, Tomcat or applications running in Tomcat does not need the remote client address information? Thanks, Amit -Original Message- From: Christopher Schultz Sent: Monday, May 8, 2023 3:40 PM To: users@tomcat.apache.org Subject: [External] 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.a/ > pache.org%2Fbugzilla%2Fshow_bug.cgi%3Fid%3D57830=05%7C01%7CAmit.P > ande%40veritas.com%7Cab789327b86845e8ad7208db50046f55%7Cfc8e13c0422c4c > 55b3eaca318e6cac32%7C0%7C0%7C638191752206669206%7CUnknown%7CTWFpbGZsb3 > d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7 > C3000%7C%7C%7C=6TXyKzlyjY3AIi6zQMFn2j9BhtwYo6Jkrd1V3nOl4mY%3D > served=0 > > 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 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Supporting Proxy Protocol in Tomcat
Hello, 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? 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? Appreciate any feedback. Thanks, Amit
RE: [External] Re: Customizing CorsFilter
Thank you, again! -Original Message- From: Mark Thomas Sent: Wednesday, September 7, 2022 6:31 AM To: users@tomcat.apache.org Subject: Re: [External] Re: Customizing CorsFilter On 07/09/2022 12:22, Amit Pande wrote: > Thank you, Mark! Will do some more research on this and see if I can leverage > this. > > However, are we still okay refactoring the CorsFilter for extension? Yes, I am sure the committers will consider any such proposal. Mark > > Thanks, > Amit > > > > -Original Message- > From: Mark Thomas > Sent: Wednesday, September 7, 2022 6:18 AM > To: users@tomcat.apache.org > Subject: Re: [External] Re: Customizing CorsFilter > > On 07/09/2022 11:42, Amit Pande wrote: >> Could you please share more details on "web.xml" changes and dynamic reload >> of applications? Some documentation link or something would be helpful. I >> couldn't find anything online. > > The documentation is rather sparse. > > See conf/web.xml and look at the nested WatchedResource elements. > > If a reload of a running application is triggered the following happens: > - new requests are allowed but made to wait > - existing requests are allowed to complete > - the web application is stopped > - the web application is started (picking up any new configuration) > - any waiting new requests are allowed to proceed > > By default, any open sessions will be lost. If using the > StandardManager you can configure it to persist session across web > application (and > Tomcat) restarts. > >> Also, wanted to check with the community - how they handle such a >> requirement where the CORS allowed origins can change over time -presumably >> infrequently but still. >> Manual edit of web.xml and leverage the reload of apps? Or server restart? >> What is the best/safe way to edit the main web.xml? > > Personally, I'd just edit web.xml but I only manage my own very lightly used > web applications. Provided you don't have long running requests I'd recommend > that approach. > > For editing web.xml, if you want to be sure use a schema aware XML editor. > That should a) ensure it is syntactically correct and b) provide > auto-completion options. I normally use an IDE. > > Mark > > >> >> Thanks, >> Amit >> >> -Original Message- >> From: Mark Thomas >> Sent: Wednesday, September 7, 2022 1:37 AM >> To: users@tomcat.apache.org >> Subject: [External] Re: Customizing CorsFilter >> >> >> >> On 07/09/2022 07:31, Mark Thomas wrote: >>> On 06/09/2022 18:42, Amit Pande wrote: >>>> Hello all, >>>> >>>> I am currently using the Tomcat 9.0.65 (9.x) and looking at the >>>> possibility of extending the >>>> CorsFilter<https://nam12.safelinks.protection.outlook.com/?url=http >>>> s >>>> % >>>> 3A%2F%2Ftomcat.apache.org%2Ftomcat-9.0-doc%2Fconfig%2Ffilter.html%2 >>>> 3 >>>> C >>>> ORS_Filterdata=05%7C01%7CAmit.Pande%40veritas.com%7C05dd6e26b6 >>>> 6 >>>> e >>>> 49dcaced08da909b854b%7Cfc8e13c0422c4c55b3eaca318e6cac32%7C0%7C0%7C6 >>>> 3 >>>> 7 >>>> 981294884520628%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjo >>>> i >>>> V >>>> 2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=UVY >>>> m M wnGj19cJCuA0Nlc%2Few5SMMGF2nXyJiFasO11hc%3Dreserved=0>, >>>> specially the configuration part. >>>> >>>> I am looking at the ability to initialize the parameters of >>>> Tomcat's CorsFilter from a source other than "web.xml" (one under >>>> TOMCAT_INSTALL_DIR/conf - so that settings apply for all >>>> applications inside this web server). E.g., the configuration could >>>> a key-value data store (or a simple property file). >>>> >>>> Hand-editing the "web.xml" could be calling for trouble if not done >>>> carefully. And AFAICT, there isn't any tooling/interface to allow >>>> easily and reliably editing the "web.xml". >>>> >>>> Also, ability to poll the external configuration source allows >>>> dynamically reload the CorsFilter configuration without requiring >>>> the Tomcat restart. In certain product deployments, web server is >>>> just a part and having to restart for some configuration changes to >>>> take effect isn't desired, though isn't not a must-have. >>>> >>>> >>>> I was looking for somethi
RE: [External] Re: Customizing CorsFilter
Thank you, Mark! Will do some more research on this and see if I can leverage
this.
However, are we still okay refactoring the CorsFilter for extension?
Thanks,
Amit
-Original Message-
From: Mark Thomas
Sent: Wednesday, September 7, 2022 6:18 AM
To: users@tomcat.apache.org
Subject: Re: [External] Re: Customizing CorsFilter
On 07/09/2022 11:42, Amit Pande wrote:
> Could you please share more details on "web.xml" changes and dynamic reload
> of applications? Some documentation link or something would be helpful. I
> couldn't find anything online.
The documentation is rather sparse.
See conf/web.xml and look at the nested WatchedResource elements.
If a reload of a running application is triggered the following happens:
- new requests are allowed but made to wait
- existing requests are allowed to complete
- the web application is stopped
- the web application is started (picking up any new configuration)
- any waiting new requests are allowed to proceed
By default, any open sessions will be lost. If using the StandardManager you
can configure it to persist session across web application (and
Tomcat) restarts.
> Also, wanted to check with the community - how they handle such a requirement
> where the CORS allowed origins can change over time -presumably infrequently
> but still.
> Manual edit of web.xml and leverage the reload of apps? Or server restart?
> What is the best/safe way to edit the main web.xml?
Personally, I'd just edit web.xml but I only manage my own very lightly used
web applications. Provided you don't have long running requests I'd recommend
that approach.
For editing web.xml, if you want to be sure use a schema aware XML editor. That
should a) ensure it is syntactically correct and b) provide auto-completion
options. I normally use an IDE.
Mark
>
> Thanks,
> Amit
>
> -Original Message-
> From: Mark Thomas
> Sent: Wednesday, September 7, 2022 1:37 AM
> To: users@tomcat.apache.org
> Subject: [External] Re: Customizing CorsFilter
>
>
>
> On 07/09/2022 07:31, Mark Thomas wrote:
>> On 06/09/2022 18:42, Amit Pande wrote:
>>> Hello all,
>>>
>>> I am currently using the Tomcat 9.0.65 (9.x) and looking at the
>>> possibility of extending the
>>> CorsFilter<https://nam12.safelinks.protection.outlook.com/?url=https
>>> %
>>> 3A%2F%2Ftomcat.apache.org%2Ftomcat-9.0-doc%2Fconfig%2Ffilter.html%23
>>> C
>>> ORS_Filterdata=05%7C01%7CAmit.Pande%40veritas.com%7C05dd6e26b66
>>> e
>>> 49dcaced08da909b854b%7Cfc8e13c0422c4c55b3eaca318e6cac32%7C0%7C0%7C63
>>> 7
>>> 981294884520628%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoi
>>> V
>>> 2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=UVYm
>>> M wnGj19cJCuA0Nlc%2Few5SMMGF2nXyJiFasO11hc%3Dreserved=0>,
>>> specially the configuration part.
>>>
>>> I am looking at the ability to initialize the parameters of Tomcat's
>>> CorsFilter from a source other than "web.xml" (one under
>>> TOMCAT_INSTALL_DIR/conf - so that settings apply for all
>>> applications inside this web server). E.g., the configuration could
>>> a key-value data store (or a simple property file).
>>>
>>> Hand-editing the "web.xml" could be calling for trouble if not done
>>> carefully. And AFAICT, there isn't any tooling/interface to allow
>>> easily and reliably editing the "web.xml".
>>>
>>> Also, ability to poll the external configuration source allows
>>> dynamically reload the CorsFilter configuration without requiring
>>> the Tomcat restart. In certain product deployments, web server is
>>> just a part and having to restart for some configuration changes to
>>> take effect isn't desired, though isn't not a must-have.
>>>
>>>
>>> I was looking for something like:
>>>
>>> public class CustomCorsFilter extends CorsFilter {
>>>
>>> @Override
>>> public void init() {
>>>
>>> // load configuration from some other persistence store //
>>> initialize fields from super class (which are then used in the
>>> actual CORS
>>> validation) }
>>>
>>> @Override
>>> public void doFilter(ServletRequest request, ServletResponse
>>> response, FilterChain chain)
>>> throws IOException, ServletException {
>>> super.doFilter(request, response, chain);
>>> }
>>>
>>> }
>>>
>>> // Additionally, the init can be called periodically which could
>>> re-initialize t
RE: [External] Re: Customizing CorsFilter
Thank you Mark for the inputs.
Agree on your points about enhancing the CORS filter for extension.
And, yes, thread-safety could be tricky for any dynamic configuration.
Could you please share more details on "web.xml" changes and dynamic reload of
applications? Some documentation link or something would be helpful. I couldn't
find anything online.
Also, wanted to check with the community - how they handle such a requirement
where the CORS allowed origins can change over time -presumably infrequently
but still.
Manual edit of web.xml and leverage the reload of apps? Or server restart? What
is the best/safe way to edit the main web.xml?
Thanks,
Amit
-Original Message-
From: Mark Thomas
Sent: Wednesday, September 7, 2022 1:37 AM
To: users@tomcat.apache.org
Subject: [External] Re: Customizing CorsFilter
On 07/09/2022 07:31, Mark Thomas wrote:
> On 06/09/2022 18:42, Amit Pande wrote:
>> Hello all,
>>
>> I am currently using the Tomcat 9.0.65 (9.x) and looking at the
>> possibility of extending the
>> CorsFilter<https://nam12.safelinks.protection.outlook.com/?url=https%
>> 3A%2F%2Ftomcat.apache.org%2Ftomcat-9.0-doc%2Fconfig%2Ffilter.html%23C
>> ORS_Filterdata=05%7C01%7CAmit.Pande%40veritas.com%7C05dd6e26b66e
>> 49dcaced08da909b854b%7Cfc8e13c0422c4c55b3eaca318e6cac32%7C0%7C0%7C637
>> 981294884520628%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV
>> 2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=UVYmM
>> wnGj19cJCuA0Nlc%2Few5SMMGF2nXyJiFasO11hc%3Dreserved=0>,
>> specially the configuration part.
>>
>> I am looking at the ability to initialize the parameters of Tomcat's
>> CorsFilter from a source other than "web.xml" (one under
>> TOMCAT_INSTALL_DIR/conf - so that settings apply for all applications
>> inside this web server). E.g., the configuration could a key-value
>> data store (or a simple property file).
>>
>> Hand-editing the "web.xml" could be calling for trouble if not done
>> carefully. And AFAICT, there isn't any tooling/interface to allow
>> easily and reliably editing the "web.xml".
>>
>> Also, ability to poll the external configuration source allows
>> dynamically reload the CorsFilter configuration without requiring the
>> Tomcat restart. In certain product deployments, web server is just a
>> part and having to restart for some configuration changes to take
>> effect isn't desired, though isn't not a must-have.
>>
>>
>> I was looking for something like:
>>
>> public class CustomCorsFilter extends CorsFilter {
>>
>> @Override
>> public void init() {
>>
>> // load configuration from some other persistence store // initialize
>> fields from super class (which are then used in the actual CORS
>> validation) }
>>
>> @Override
>> public void doFilter(ServletRequest request, ServletResponse
>> response, FilterChain chain)
>> throws IOException, ServletException {
>> super.doFilter(request, response, chain);
>> }
>>
>> }
>>
>> // Additionally, the init can be called periodically which could
>> re-initialize the fields from CorsFilter class.
>>
>> However, currently, the configuration fields are private and there
>> are no setters.
>>
>> Before I explore the option of looking for adding interface to "edit"
>> the web.xml, wanted to check if it's possible to update the
>> CorsFilter and make some methods protected (e.g.
>> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit
>> hub.com%2Fapache%2Ftomcat%2Fblob%2F9.0.65%2Fjava%2Forg%2Fapache%2Fcat
>> alina%2Ffilters%2FCorsFilter.java%23L712data=05%7C01%7CAmit.Pand
>> e%40veritas.com%7C05dd6e26b66e49dcaced08da909b854b%7Cfc8e13c0422c4c55
>> b3eaca318e6cac32%7C0%7C0%7C637981294884520628%7CUnknown%7CTWFpbGZsb3d
>> 8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7
>> C3000%7C%7C%7Csdata=SaFrY7oHvHmErLFKaesA55hFPM9o7JiT%2F3M%2BCJ4s
>> WgY%3Dreserved=0)
>> for extension.
>
> Refactoring the CorsFilter to make it extensible is certainly an option.
> Some things to keep in mind:
>
> - Increasing the visibility of methods is unlikely to be controversial
>
> - Getters and setters are preferred to non-private fields
>
> - Any changes need to be backwards compatible
>
> - Supporting dynamic reconfiguration means ensuring that any such
> configuration changes are made in a thread-safe manner. Note that the
> configuration could change in the middle of a request being processed
> by the filter.
>
> That last point is t
Customizing CorsFilter
Hello all,
I am currently using the Tomcat 9.0.65 (9.x) and looking at the possibility of
extending the
CorsFilter<https://tomcat.apache.org/tomcat-9.0-doc/config/filter.html#CORS_Filter>,
specially the configuration part.
I am looking at the ability to initialize the parameters of Tomcat's CorsFilter
from a source other than "web.xml" (one under TOMCAT_INSTALL_DIR/conf - so that
settings apply for all applications inside this web server). E.g., the
configuration could a key-value data store (or a simple property file).
Hand-editing the "web.xml" could be calling for trouble if not done carefully.
And AFAICT, there isn't any tooling/interface to allow easily and reliably
editing the "web.xml".
Also, ability to poll the external configuration source allows dynamically
reload the CorsFilter configuration without requiring the Tomcat restart. In
certain product deployments, web server is just a part and having to restart
for some configuration changes to take effect isn't desired, though isn't not a
must-have.
I was looking for something like:
public class CustomCorsFilter extends CorsFilter {
@Override
public void init() {
// load configuration from some other persistence store
// initialize fields from super class (which are then used in the actual CORS
validation)
}
@Override
public void doFilter(ServletRequest request, ServletResponse response,
FilterChain chain)
throws IOException, ServletException {
super.doFilter(request, response, chain);
}
}
// Additionally, the init can be called periodically which could re-initialize
the fields from CorsFilter class.
However, currently, the configuration fields are private and there are no
setters.
Before I explore the option of looking for adding interface to "edit" the
web.xml, wanted to check if it's possible to update the CorsFilter and make
some methods protected (e.g.
https://github.com/apache/tomcat/blob/9.0.65/java/org/apache/catalina/filters/CorsFilter.java#L712)
for extension.
Thanks,
Amit
RE: [External] Re: SSL Handshake Failure - Logging Level
I mean this log is helpful troubleshooting issues in production systems. We
can't have Tomcat log level set to DEBUG in this case.
And debugging on local/development environments. Agree, in this case, we could
change the Tomcat logging configuration and get this log.
Thanks,
Amit
-Original Message-
From: Mark Thomas
Sent: Saturday, June 4, 2022 6:13 AM
To: users@tomcat.apache.org
Subject: Re: [External] Re: SSL Handshake Failure - Logging Level
On 03/06/2022 21:29, Amit Pande wrote:
> Thank you, Mark.
>
> I agree changing the log level to error could cause problems you mentioned.
> But option like logHandshakeFailuresAtError will be useful to
> troubleshooting/debugging assuming DoS attacks are handled differently.
If the purpose of this is debugging / troubleshooting they why not just enable
debug logging when needed?
Why does this need to be separately configurable?
Mark
>
> Thinking if this could be a connector level attribute or attribute at SSL
> host config level in "server.xml".
>
> Thanks,
> Amit
>
> -Original Message-
> From: Mark Thomas
> Sent: Friday, June 3, 2022 12:24 PM
> To: users@tomcat.apache.org
> Subject: [External] Re: SSL Handshake Failure - Logging Level
>
>
>
> On 03/06/2022 15:33, Amit Pande wrote:
>> Hello,
>>
>> First, thank you to Mark for adding the access logs in case of SSL handshake
>> failures
>> (https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Ftomcat%2Fcommit%2Facf6076d7118571ebc881984b96792f861b72bb2%23data=05%7C01%7CAmit.Pande%40veritas.com%7C4a3b22cfe34644c1530508da461b3fe9%7Cfc8e13c0422c4c55b3eaca318e6cac32%7C0%7C0%7C637899380101620149%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=ZUT9Z1PWQBYpJPWZgAgVX93SJkhDnq%2BQxXJv8BanV9o%3Dreserved=0).
>> Really useful enhancement.
>>
>> On a related note, I am trying to understand if we can log the SSL handshake
>> failure at ERROR level instead of current DEBUG level.
>>
>> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit
>> h
>> ub.com%2Fapache%2Ftomcat%2Fblob%2Fmain%2Fjava%2Forg%2Fapache%2Ftomcat
>> %
>> 2Futil%2Fnet%2FNio2Endpoint.javadata=05%7C01%7CAmit.Pande%40veri
>> t
>> as.com%7Cc90c525c37304f89d53e08da4586d120%7Cfc8e13c0422c4c55b3eaca318
>> e
>> 6cac32%7C0%7C0%7C637898742608266230%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiM
>> C
>> 4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C
>> %
>> 7Csdata=beoiMNczfYunL9CN7I8mJCLwNsyXr%2FjlGRzDy1ZHEmg%3Dres
>> e
>> rved=0
>>
>> if (log.isDebugEnabled()) {
>>
>> log.debug(sm.getString("endpoint.err.handshake"), x); }
>>
>> Are there any issues logging this at error level?
>
> Yes. We generally don't log user triggerable exceptions above debug level as
> that can expose the server to a potential DoS - either by filling the disk
> with log messages or the performance impact of triggering the exceptions.
>
> I guess we could make the log level for that message configurable.
> logHandshakeFailuresAtError or something.
>
> 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
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
RE: [External] Re: SSL Handshake Failure - Logging Level
Thank you, Mark.
I agree changing the log level to error could cause problems you mentioned.
But option like logHandshakeFailuresAtError will be useful to
troubleshooting/debugging assuming DoS attacks are handled differently.
Thinking if this could be a connector level attribute or attribute at SSL host
config level in "server.xml".
Thanks,
Amit
-Original Message-
From: Mark Thomas
Sent: Friday, June 3, 2022 12:24 PM
To: users@tomcat.apache.org
Subject: [External] Re: SSL Handshake Failure - Logging Level
On 03/06/2022 15:33, Amit Pande wrote:
> Hello,
>
> First, thank you to Mark for adding the access logs in case of SSL handshake
> failures
> (https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Ftomcat%2Fcommit%2Facf6076d7118571ebc881984b96792f861b72bb2%23data=05%7C01%7CAmit.Pande%40veritas.com%7Cc90c525c37304f89d53e08da4586d120%7Cfc8e13c0422c4c55b3eaca318e6cac32%7C0%7C0%7C637898742608266230%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=eVNkn8ZtEi6l1IZ5N8tdmVZ%2B0xj%2FeOFC7G2YdBQxZ0Y%3Dreserved=0).
> Really useful enhancement.
>
> On a related note, I am trying to understand if we can log the SSL handshake
> failure at ERROR level instead of current DEBUG level.
>
> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
> ub.com%2Fapache%2Ftomcat%2Fblob%2Fmain%2Fjava%2Forg%2Fapache%2Ftomcat%
> 2Futil%2Fnet%2FNio2Endpoint.javadata=05%7C01%7CAmit.Pande%40verit
> as.com%7Cc90c525c37304f89d53e08da4586d120%7Cfc8e13c0422c4c55b3eaca318e
> 6cac32%7C0%7C0%7C637898742608266230%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC
> 4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%
> 7Csdata=beoiMNczfYunL9CN7I8mJCLwNsyXr%2FjlGRzDy1ZHEmg%3Drese
> rved=0
>
> if (log.isDebugEnabled()) {
>
> log.debug(sm.getString("endpoint.err.handshake"), x); }
>
> Are there any issues logging this at error level?
Yes. We generally don't log user triggerable exceptions above debug level as
that can expose the server to a potential DoS - either by filling the disk with
log messages or the performance impact of triggering the exceptions.
I guess we could make the log level for that message configurable.
logHandshakeFailuresAtError or something.
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
SSL Handshake Failure - Logging Level
Hello,
First, thank you to Mark for adding the access logs in case of SSL handshake
failures
(https://github.com/apache/tomcat/commit/acf6076d7118571ebc881984b96792f861b72bb2#).
Really useful enhancement.
On a related note, I am trying to understand if we can log the SSL handshake
failure at ERROR level instead of current DEBUG level.
https://github.com/apache/tomcat/blob/main/java/org/apache/tomcat/util/net/Nio2Endpoint.java
if (log.isDebugEnabled()) {
log.debug(sm.getString("endpoint.err.handshake"), x);
}
Are there any issues logging this at error level?
Thanks,
Amit
RE: [External] Re: Maximum header size in Tomcat 9
Thank you, Mark! -Original Message- From: Mark Thomas Sent: Thursday, May 26, 2022 6:10 AM To: users@tomcat.apache.org Subject: Re: [External] Re: Maximum header size in Tomcat 9 On 25/05/2022 16:21, Amit Pande wrote: > Hello Mark, > > Could we slightly update the description - to say that this size is total > size (in bytes)of all the request (and response) headers combined (including > the header name and values)? > In the past, I incorrectly assumed that this size limit applies for one > header value. > > maxHttpHeaderSize > The maximum size of the request and response HTTP header, specified in bytes. > If not specified, this attribute is set to 8192 (8 KB). Done. Mark > > Thanks, > Amit > > -Original Message- > From: Mark Thomas > Sent: Wednesday, May 25, 2022 6:16 AM > To: users@tomcat.apache.org > Subject: [External] Re: Maximum header size in Tomcat 9 > > On 25/05/2022 12:08, Aditya Kumar wrote: >> Thanks! Sorry I misread that article. >> >> So I suppose it's the same for maxHttpRequestHeaderSize and >> maxHttpResponseHeaderSize? > > Correct. > > Mark > > >> >> >> >> On Wed, May 25, 2022 at 10:45 AM Mark Thomas wrote: >> >>> On 25/05/2022 10:33, Aditya Kumar wrote: >>>> I'm sorry I'm not sure what you mean by Integer.MAX_VALUE? >>> >>> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdo >>> c >>> s.oracle.com%2Fjavase%2F8%2Fdocs%2Fapi%2Fjava%2Flang%2FInteger.html% >>> 2 >>> 3MAX_VALUEdata=05%7C01%7CAmit.Pande%40veritas.com%7Ce18ae152bff >>> 0 >>> 402dad6908da3e3ff7e3%7Cfc8e13c0422c4c55b3eaca318e6cac32%7C0%7C0%7C63 >>> 7 >>> 890741724402644%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoi >>> V >>> 2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=pfV4 >>> K >>> ul5InBqXlyW958TnV57bbZbe6F%2FrurIJqJ70xg%3Dreserved=0 >>> >>>> Looking at >>>> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Ft >>>> o >>>> mcat.apache.org%2Ftomcat-9.0-doc%2Fconfig%2Fhttp.htmldata=05%7 >>>> C >>>> 01%7CAmit.Pande%40veritas.com%7Ce18ae152bff0402dad6908da3e3ff7e3%7C >>>> f >>>> c8e13c0422c4c55b3eaca318e6cac32%7C0%7C0%7C637890741724402644%7CUnkn >>>> o >>>> wn%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haW >>>> w >>>> iLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=VXFY%2Bew8f1HxXiUYsyCmgiV >>>> D >>>> B%2FqQUJr4rhbB8LbZmkA%3Dreserved=0 >>> all I >>>> see is this:- >>>> "maxHttpHeaderSize >>>> >>>> The maximum size of the request and response HTTP header, specified >>>> in bytes. If not specified, this attribute is set to 8192 (8 KB)." >>>> This does not explain possible values. Can you give me an actual >>>> number >>> for >>>> the maximum? >>> >>> See above. >>> >>> The theoretical maximum is so far above any sensible value there is >>> not much point documenting it. >>> >>>> Also I saw in this article: >>>> >>> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fco >>> m >>> munity.jaspersoft.com%2Fwiki%2Fhow-pass-big-number-values-apache-tom >>> c >>> at-url-stringdata=05%7C01%7CAmit.Pande%40veritas.com%7Ce18ae152 >>> b >>> ff0402dad6908da3e3ff7e3%7Cfc8e13c0422c4c55b3eaca318e6cac32%7C0%7C0%7 >>> C >>> 637890741724402644%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQI >>> j >>> oiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=I >>> 6 >>> %2FHM6WSIVucDyEU17ENL0NGNbBDqtAEZ2snU6FFUF4%3Dreserved=0 >>>> >>>> " A value of less than 0 means no limit." >>> >>> That text is copied directly from the Tomcat documentation and is >>> part of the description for maxParameterCount, not maxHttpHeaderSize. >>> What makes you think it might apply to maxHttpHeaderSize? >>> >>> Mark >>> >>> >>>> >>>> >>>> On Wed, May 25, 2022 at 10:19 AM Mark Thomas wrote: >>>> >>>>> On 25/05/2022 09:51, Aditya Kumar wrote: >>>>>> Hi >>>>>> >>>>>> I'm using Tomcat 9.0.46 and I want to know what is the maximum >>>>>> possible value for
RE: [External] Re: Maximum header size in Tomcat 9
Hello Mark, Could we slightly update the description - to say that this size is total size (in bytes)of all the request (and response) headers combined (including the header name and values)? In the past, I incorrectly assumed that this size limit applies for one header value. maxHttpHeaderSize The maximum size of the request and response HTTP header, specified in bytes. If not specified, this attribute is set to 8192 (8 KB). Thanks, Amit -Original Message- From: Mark Thomas Sent: Wednesday, May 25, 2022 6:16 AM To: users@tomcat.apache.org Subject: [External] Re: Maximum header size in Tomcat 9 On 25/05/2022 12:08, Aditya Kumar wrote: > Thanks! Sorry I misread that article. > > So I suppose it's the same for maxHttpRequestHeaderSize and > maxHttpResponseHeaderSize? Correct. Mark > > > > On Wed, May 25, 2022 at 10:45 AM Mark Thomas wrote: > >> On 25/05/2022 10:33, Aditya Kumar wrote: >>> I'm sorry I'm not sure what you mean by Integer.MAX_VALUE? >> >> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdoc >> s.oracle.com%2Fjavase%2F8%2Fdocs%2Fapi%2Fjava%2Flang%2FInteger.html%2 >> 3MAX_VALUEdata=05%7C01%7CAmit.Pande%40veritas.com%7Ce18ae152bff0 >> 402dad6908da3e3ff7e3%7Cfc8e13c0422c4c55b3eaca318e6cac32%7C0%7C0%7C637 >> 890741724402644%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV >> 2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=pfV4K >> ul5InBqXlyW958TnV57bbZbe6F%2FrurIJqJ70xg%3Dreserved=0 >> >>> Looking at >>> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fto >>> mcat.apache.org%2Ftomcat-9.0-doc%2Fconfig%2Fhttp.htmldata=05%7C >>> 01%7CAmit.Pande%40veritas.com%7Ce18ae152bff0402dad6908da3e3ff7e3%7Cf >>> c8e13c0422c4c55b3eaca318e6cac32%7C0%7C0%7C637890741724402644%7CUnkno >>> wn%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWw >>> iLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=VXFY%2Bew8f1HxXiUYsyCmgiVD >>> B%2FqQUJr4rhbB8LbZmkA%3Dreserved=0 >> all I >>> see is this:- >>> "maxHttpHeaderSize >>> >>> The maximum size of the request and response HTTP header, specified >>> in bytes. If not specified, this attribute is set to 8192 (8 KB)." >>> This does not explain possible values. Can you give me an actual >>> number >> for >>> the maximum? >> >> See above. >> >> The theoretical maximum is so far above any sensible value there is >> not much point documenting it. >> >>> Also I saw in this article: >>> >> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcom >> munity.jaspersoft.com%2Fwiki%2Fhow-pass-big-number-values-apache-tomc >> at-url-stringdata=05%7C01%7CAmit.Pande%40veritas.com%7Ce18ae152b >> ff0402dad6908da3e3ff7e3%7Cfc8e13c0422c4c55b3eaca318e6cac32%7C0%7C0%7C >> 637890741724402644%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIj >> oiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=I6 >> %2FHM6WSIVucDyEU17ENL0NGNbBDqtAEZ2snU6FFUF4%3Dreserved=0 >>> >>> " A value of less than 0 means no limit." >> >> That text is copied directly from the Tomcat documentation and is >> part of the description for maxParameterCount, not maxHttpHeaderSize. >> What makes you think it might apply to maxHttpHeaderSize? >> >> Mark >> >> >>> >>> >>> On Wed, May 25, 2022 at 10:19 AM Mark Thomas wrote: >>> >>>> On 25/05/2022 09:51, Aditya Kumar wrote: >>>>> Hi >>>>> >>>>> I'm using Tomcat 9.0.46 and I want to know what is the maximum >>>>> possible value for maxHttpHeaderSize >>>> >>>> Integer.MAX_VALUE >>>> >>>>> I have Tomcat setup using kerberos authentication and for some >>>>> users >> the >>>>> Authorisation header is too large (too many AD groups). >>>>> >>>>> I have seen various articles when googling but I want something >>>>> from official documentation to state what the possible values for >>>>> this field are. Is it true that setting a value of "-1" causes a >>>>> limitless maximum header size value? >>>> >>>> Where did you read that? I don't see that in the documentation. >>>> >>>> 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 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: [OT] web app big memory usage?
Have you enabled the " Enable 'keep unreachable objects'" setting of MAT? https://blog.gceasy.io/2015/12/11/eclipse-mat-titbits/ Thanks, Amit -Original Message- From: Berneburg, Cris J. - US Sent: Thursday, May 27, 2021 2:24 PM To: users@tomcat.apache.org Subject: [EXTERNAL] [OT] web app big memory usage? Hi Folks :-) One of our web apps is using a "lot" of memory, specifically a big user query. We'd like to find out why. The Tomcat Web Application Manager Find leaks button said that "No web applications appear to have triggered a memory leak on stop, reload or undeploy." Tomcat Manager Server Status shows that 1.7GB (82%) of G1 Old Gen space is being used that has not been recycled yet. I grabbed a heap dump and used Eclipse Memory Analyzer, and it shows that only 94MB of memory is being used when G1 Old Gen space used 1.8GB. MAT seems to be looking only at the active objects, not the discarded ones. IOW, we're looking at what the app is doing ATM, not what it already did. I want to explore the 1.7GB garbage pile to see what's being thrown away, not what things are still being used, to determine wastefulness. 1. Is there a way to analyze uncollected garbage? 2. Is that a reasonable way to identify potential memory usage problems? Some technical specifics: * TC 8.5.63 * Java 1.8.0_291 * AWS EC2 instance. * Windows Server 2016. * Instance started as Windows Service. * There are other TC instances on the same server. * Each TC instance has multiple apps. Thanks for reading this far. :-) -- Cris Berneburg CACI Senior Software Engineer This electronic message contains information from CACI International Inc or subsidiary companies, which may be company sensitive, proprietary, privileged or otherwise protected from disclosure. The information is intended to be used solely by the recipient(s) named above. If you are not an intended recipient, be aware that any review, disclosure, copying, distribution or use of this transmission or its contents is prohibited. If you have received this transmission in error, please notify the sender immediately. - 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: Not able to make JSESSIONID cookie secure
Hi, Thanks for the reply. We tried the settings on multiple machines. And found that the same configuration machines gave different results. We are getting multiple jsessionid cookies being created. In our application, we have a multi tenant application. For each tenant we have an nginx running calling the application url. URL being hit on browser is like *.myapp.com <http://myapp.com>* We are able to see 2 JSESSIONID cookies being generated for this call on some machines. 1. domain: /myapp which is having secure flag. 2. domain: /myapp/ which is NOT having secure flag. Strangely, in most machines, we are finding the second cookie being generated but the first cookie not generated. Only when we saw on one of the machines, the first cookie, we found that the secure jsessionid cookie being generated on that particular environment. The environment having 2 cookies and the one with one cookie are identical. Can you please help me fix the creation of the second cookie and also how to ensure that the first cookie is generated in all environments? On Tue, Jan 5, 2021 at 1:24 AM Christopher Schultz < ch...@christopherschultz.net> wrote: > Mark, > > On 1/4/21 03:17, Mark Thomas wrote: > > On 04/01/2021 06:02, Amit Khosla wrote: > >> Hi, > >> > >> We are still facing this issue. Can someone please help us? > > > > In a clean 8.5.x install, session cookies are only marked as secure if > > the request that triggered the session creation is made over a secure > > channel (typically HTTPS). > > > > If you amend the session configuration in $CATALINA_BASE/conf/web.xml > from: > > > > > > 30 > > > > > > to > > > > > > 30 > > > > true > > > > > > > > then session cookies will be generated with the secure flag whether or > > not the request that triggered the the session creation was made over a > > secure channel. > > > > Reviewing the thread: > > > > Are you sure you are amending the correct web.xml file? One way to check > > this is to make a deliberate error in the file and confirm that this > > error is reported when Tomcat starts. > > > > Note that you can only use once in a web.xml file. If > > the web.xml file already contains a element you must > > add to that existing element. > > > > Configuration in the application's web.xml file will override the global > > web.xml file. Make sure that the application's web.xml either does not > > specify a value for secure or specifies true. > > > > If you still have issues: > > - start with a clean Tomcat 8.5.x install > > - confirm that > >http://localhost:8080/examples/servlets/servlet/SessionExample > >generates a set-cookie header without the secure attribute > > - stop Tomcat > > - close the browser > > - amend conf/web.xml as above > > - start Tomcat > > - confirm that > >http://localhost:8080/examples/servlets/servlet/SessionExample > >generates a set-cookie header with the secure attribute > > - retest with your application > > > > You must close the browser between each request you expect to generate a > > session cookie to prevent any existing session from being used. > > You may be able to avoid this with either of: > > 1. "Private" browsing mode: use a new "private" tab/window each time > > 2. Under developer tools / Storage (you may have to poke around for > this), you should be able to see the cookies for the host and, if > appropriate, delete them. > > > If this test fails then you'll need to check the application source > > code. It is possible that the application is overriding your attempts to > > make the session cookie secure. > > +1 > > Other possibilities include a reverse proxy where the client is using > HTTPS to communicate with the proxy, but HTTPS is not being used between > the proxy and the Tomcat server. > > -chris > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > -- Thanks & Regards Amit Khosla
Re: Not able to make JSESSIONID cookie secure
Hi, We are still facing this issue. Can someone please help us? Thanks & Regards Amit On Fri, Jan 1, 2021 at 8:22 PM Amit Khosla wrote: > Thanks for reply! > > We did changes in /conf/web.xml. > But when the changes did not reflect, we made changes in specific app as > well. But we could not see the cookie as secure. > > We verified by the response headers seen in chrome developer tool. The > cookie JSESSIONID does not have a secure flag. > > By the way, Happy New Year! > > On Thu, Dec 31, 2020 at 5:01 PM Darryl Lewis > wrote: > >> >> Did you make the changes to /conf/web.xml ? It seems you >> may have made them just to that specific our_app application >> >> Are you sure you are testing it correctly? >> Can you try https://gf.dev/http-headers-test >> >> >> On 31/12/20, 8:29 pm, "Amit Khosla" wrote: >> >> Thanks for reply, >> we did restarted server while trying. The issue is still there even >> after >> restart. >> >> On Thu, Dec 31, 2020 at 11:14 AM Darryl Lewis < >> darryl.le...@unsw.edu.au> >> wrote: >> >> > >> > >> > true >> > true >> > >> > >> > >> > Restart the server. >> > >> > On 31/12/20, 3:50 pm, "Amit Khosla" >> wrote: >> > >> > Hi Team, >> > >> > >> > >> > As we are looking forward for JSESSIONID to be secure. >> > >> > >> > >> > We made changes in web.xml in tomcat/conf >> > >> > >> > >> > >> > >> > true >> > >> > true >> > >> > >> > >> > >> > >> > >> > >> > But even after the changes, we are not able to get the >> JSESSIONID >> > cookie as >> > secure. >> > >> > We also tried changes in web.xml of our application, i.e, >> > tomcat/webapps/our_app/WEB-INF/web.xml; but still we are not >> getting it >> > secure. >> > >> > >> > >> > Tomcat version we are using is 8.5.53. >> > >> > We are getting same issue on windows as well as linux machine. >> > >> > >> > >> > Can you please guide us what can be done as this is required as >> per >> > security compliance? >> > >> > >> > >> > Thanks & Regards >> > >> > Amit >> > >> > >> >> -- >> Thanks & Regards >> Amit Khosla >> >> > > -- > Thanks & Regards > Amit Khosla > -- Thanks & Regards Amit Khosla Ph: 9911797132
Re: Not able to make JSESSIONID cookie secure
Thanks for reply! We did changes in /conf/web.xml. But when the changes did not reflect, we made changes in specific app as well. But we could not see the cookie as secure. We verified by the response headers seen in chrome developer tool. The cookie JSESSIONID does not have a secure flag. By the way, Happy New Year! On Thu, Dec 31, 2020 at 5:01 PM Darryl Lewis wrote: > > Did you make the changes to /conf/web.xml ? It seems you > may have made them just to that specific our_app application > > Are you sure you are testing it correctly? > Can you try https://gf.dev/http-headers-test > > > On 31/12/20, 8:29 pm, "Amit Khosla" wrote: > > Thanks for reply, > we did restarted server while trying. The issue is still there even > after > restart. > > On Thu, Dec 31, 2020 at 11:14 AM Darryl Lewis < > darryl.le...@unsw.edu.au> > wrote: > > > > > > > true > > true > > > > > > > > Restart the server. > > > > On 31/12/20, 3:50 pm, "Amit Khosla" > wrote: > > > > Hi Team, > > > > > > > > As we are looking forward for JSESSIONID to be secure. > > > > > > > > We made changes in web.xml in tomcat/conf > > > > > > > > > > > > true > > > > true > > > > > > > > > > > > > > > > But even after the changes, we are not able to get the JSESSIONID > > cookie as > > secure. > > > > We also tried changes in web.xml of our application, i.e, > > tomcat/webapps/our_app/WEB-INF/web.xml; but still we are not > getting it > > secure. > > > > > > > > Tomcat version we are using is 8.5.53. > > > > We are getting same issue on windows as well as linux machine. > > > > > > > > Can you please guide us what can be done as this is required as > per > > security compliance? > > > > > > > > Thanks & Regards > > > > Amit > > > > > > -- > Thanks & Regards > Amit Khosla > > -- Thanks & Regards Amit Khosla
Re: Not able to make JSESSIONID cookie secure
Thanks for reply, we did restarted server while trying. The issue is still there even after restart. On Thu, Dec 31, 2020 at 11:14 AM Darryl Lewis wrote: > > > true > true > > > > Restart the server. > > On 31/12/20, 3:50 pm, "Amit Khosla" wrote: > > Hi Team, > > > > As we are looking forward for JSESSIONID to be secure. > > > > We made changes in web.xml in tomcat/conf > > > > > > true > > true > > > > > > > > But even after the changes, we are not able to get the JSESSIONID > cookie as > secure. > > We also tried changes in web.xml of our application, i.e, > tomcat/webapps/our_app/WEB-INF/web.xml; but still we are not getting it > secure. > > > > Tomcat version we are using is 8.5.53. > > We are getting same issue on windows as well as linux machine. > > > > Can you please guide us what can be done as this is required as per > security compliance? > > > > Thanks & Regards > > Amit > > -- Thanks & Regards Amit Khosla
Not able to make JSESSIONID cookie secure
Hi Team, As we are looking forward for JSESSIONID to be secure. We made changes in web.xml in tomcat/conf true true But even after the changes, we are not able to get the JSESSIONID cookie as secure. We also tried changes in web.xml of our application, i.e, tomcat/webapps/our_app/WEB-INF/web.xml; but still we are not getting it secure. Tomcat version we are using is 8.5.53. We are getting same issue on windows as well as linux machine. Can you please guide us what can be done as this is required as per security compliance? Thanks & Regards Amit
RE: [EXTERNAL] Re: Can Tomcat 9 be FIPS compliant without OpenSSL?
Thank you George for letting us know on -Dorg.bouncycastle.rsa.allow_multi_use=true" JVM option. Will explore this further and update the document (https://github.com/amitlpande/tomcat-9-fips/blob/master/README.md) appropriately. Albeit reluctantly, we have given in to use BCFIPS (over PKCS12) for our key stores as it is the only format meeting our FIPS requirements. Thanks, Amit -Original Message- From: George Stanchev Sent: Saturday, December 5, 2020 11:17 AM To: Tomcat Users List Subject: RE: [EXTERNAL] Re: Can Tomcat 9 be FIPS compliant without OpenSSL? Chris -Original Message- From: Christopher Schultz Sent: Friday, December 04, 2020 1:20 PM To: users@tomcat.apache.org Subject: Re: [EXTERNAL] Re: Can Tomcat 9 be FIPS compliant without OpenSSL? > With the pluggability of Java's crypto interface, I seriously doubt > Oracle is going to certify a JCE module in the future, esp. with free > 3rd party solutions such as BCFIPS. Is BC actually certified? It seems unlikely to me that a group of volunteers from Australia are going to bother to go through that module-certification process. GS: While the project is open sourced they had a company (Crypto Workshop) that earned a living through paid support and consulting. They were recently acquired (https://www.prnewswire.com/news-releases/primekey-acquires-crypto-workshop-300988188.html). And yes they are certified (https://csrc.nist.gov/projects/cryptographic-module-validation-program/Certificate/2768) and currently working on the next certification, expected out next year. > I found it non-trivial and the toolsets to be very specific, and even > after following all instructions from several wikis and web pages I > kept running into issues resulting in overall failure. Yes, the build process for OpenSSL is horrible. I have no idea why they decided to use Perl as their build system. On Windows? I have only tried to build the OpenSSL binary, not the FIPS-compliant module. Having done it on Linux (where it's "easy") I can say I'm glad I'm not responsible for doing it on Windows. GS: Sadly, OpenSSL and the FIPS module built just fine. I forgot the details but it was the ARP or the tcnative itself that failed me. There is also a bug in OpenSSL or tomcat's glue code that if cacerts contain more than a certain number of certificates to fail the handshake with timeout (http://tomcat.10.x6.nabble.com/Client-Cert-TLS-issue-td5090609.html) > Also, keep in mind that OpenSSL 1.0.1 is EOLed and the FIPS module is > only available for that version line. OpenSSL still produces security > fixes to paid support subscribers (we are) but they are not available > for the general public. OpenSSL 3.0 will have a refreshed re-certified > FIPS module but it is not due until later next year, so for now > general public is left hanging with the last public version of > 1.0.1+FIPS. :( This is why we can't have nice things. > The workaround could be to use a different password based key > derivation function - PBKDF2. However, there is nothing in the PKCS12 > spec that allows to encode another algorithm OID in MacData. In > essence, you cannot use any other algorithm other than the one defined > in spec which is not FIPS compliant. And something which is ironically FIPS-compliant is to use a PEM file with no protection whatsoever. GS: Well, the keys in the PEM files are still encrypted but you're right no protection of the overall container like in BCFKS or PKCS12 George B CB [ X ܚX KK[XZ[ \ \ ][ X ܚX P X ] \X K ܙ B ܈Y][ۘ[ [X[ K[XZ[ \ \ Z[ X ] \X K ܙ B - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: [EXTERNAL] Re: Bouncy Castle FIPS on RHEL 7.3
Thank you Stefan, Chris for the inputs. As I understood from our security experts, there is no moving away from /dev/random (anything else isn't (strongly) FIPS compliant) for us. Thanks, Amit -Original Message- From: Christopher Schultz Sent: Wednesday, December 2, 2020 10:29 AM To: users@tomcat.apache.org Subject: Re: [EXTERNAL] Re: Bouncy Castle FIPS on RHEL 7.3 Stefan, On 11/30/20 19:17, Stefan Mayr wrote: > Hi, > > Am 30.11.2020 um 17:09 schrieb Amit Pande: >> I guess I will have to investigate the RHEL 7.3 entropy issue separately >> (possibly as hobby project) and look for other options to make progress. >> >> I still find it odd that something related to randomness (entropy >> generation) is so consistent (the slowness is equally slow or more on >> multiple RHEL 7.3 systems I have, maybe I need to look for machines from >> different data center or a physical 7.3 server). >> >> And yes, the 10 year certificate validity is just for testing >> purposes. >> >> Thank you for your inputs. Indeed helpful in evaluating our choices. >> >> Thanks, >> Amit > > you might have a look at rng-tools (rngd) or haveged to boost your > entropy pool. > > We use haveged in a VMware virtualized environment and this reduces a > plain tomcat startup from multiple minutes to just a few secondes. > > I think Red Hat preferes rngd but there should be some articles on > access.redhat.com to help you depending on the used hypervisor. I would think long and hard about whether or not you want to use any of these tools. There are already ways to get "a lot of entropy really quickly" from the Linux kernel; specifically, /dev/urandom. The whole point of both /dev/random and /dev/urandom existing side by side is so that the application can pick whether it wants "high quality entropy" (by using /dev/random) or "good enough randomness" (by using /dev/urandom). Tools like haveged and rngd basically make /dev/random behave like /dev/urandom so the application can never have "high quality entropy" even when it asks for it. Have a look at this discussion on security.stackexchange to get you started down the path to paranoia: https://security.stackexchange.com/questions/34523 My question has always been "if these things are both safe and a good idea, why does the Linux kernel not implement them directly?" There must be a reason why the kernel devs have decided not to "speed up" /dev/random using the techniques used by both haveged and rngd. Maybe their argument is essentially "you can always just use haveged/rngd" but my guess is there is a more fundamental reason for not adopting these techniques directly in the kernel. -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: [EXTERNAL] Re: Bouncy Castle FIPS on RHEL 7.3
I guess I will have to investigate the RHEL 7.3 entropy issue separately (possibly as hobby project) and look for other options to make progress. I still find it odd that something related to randomness (entropy generation) is so consistent (the slowness is equally slow or more on multiple RHEL 7.3 systems I have, maybe I need to look for machines from different data center or a physical 7.3 server). And yes, the 10 year certificate validity is just for testing purposes. Thank you for your inputs. Indeed helpful in evaluating our choices. Thanks, Amit -Original Message- From: Christopher Schultz Sent: Wednesday, November 25, 2020 9:42 PM To: users@tomcat.apache.org Subject: Re: [EXTERNAL] Re: Bouncy Castle FIPS on RHEL 7.3 Amit, On 11/25/20 12:40, Amit Pande wrote: > Thank you Chris for the inputs. Admittedly, I didn’t know the internals of > Sun JCE/JSSE vs BC JCE. > > Pasting sample output and it indeed is taking minutes on RHEL 7.3. Not sure > if I am indeed missing some trick here. > > > RHEL 7.3 --- > > test-host-1:~ # date ; /usr/openv/java/jre/bin/keytool -providerpath > /root/Downloads/bc-fips-1.0.2.jar -providerclass > org.bouncycastle.jcajce.provider.BouncyCastleFipsProvider -genkeypair > -keyalg RSA -keypass "Test123" -validity 3650 -dname > "CN=Amit_HostName, ou=My_Org_Unit, o=My_Org" -storepass "Test123" > -keystore "/tmp/test_bc.bcfks" -storetype BCFKS -v -alias abcd ; date > > Wed Nov 25 10:52:56 CST 2020 (START TIME) > > Generating 2,048 bit RSA key pair and self-signed certificate (SHA256withRSA) > with a validity of 3,650 days > for: CN=Amit_HostName, OU=My_Org_Unit, O=My_Org [Storing > /tmp/test_bc.bcfks] > > Wed Nov 25 10:58:11 CST 2020 (END TIME) (Almost 6 minutes) > > test-host-1:~ # uname -a > Linux test-host-1 3.10.0-514.el7.x86_64 #1 SMP Wed Oct 19 11:24:13 EDT > 2016 x86_64 x86_64 x86_64 GNU/Linux test-host-1:~ # cat > /etc/redhat-release Red Hat Enterprise Linux Server release 7.3 > (Maipo) test-host-1:~ # test-host-1:~ # /usr/openv/java/jre/bin/java > -version java version "1.8.0_271" > Java(TM) SE Runtime Environment (build 1.8.0_271-b09) Java HotSpot(TM) > 64-Bit Server VM (build 25.271-b09, mixed mode) test-host-1:~ # > > > RHEL 7.2 - > > [root@test-host-2 ~]# date ; /usr/openv/java/jre/bin/keytool > -providerpath /root/bc-fips-1.0.2.jar -providerclass > org.bouncycastle.jcajce.provider.BouncyCastleFipsProvider -genkeypair > -keyalg RSA -keypass "Test123" -validity 3650 -dname > "CN=Amit_HostName, ou=My_Org_Unit, o=My_Org" -storepass "Test123" > -keystore "/tmp/test_bc.bcfks" -storetype BCFKS -v -alias abcd ; date > > Wed Nov 25 11:20:06 CST 2020 (START TIME) > > Generating 2,048 bit RSA key pair and self-signed certificate (SHA256withRSA) > with a validity of 3,650 days > for: CN=Amit_HostName, OU=My_Org_Unit, O=My_Org [Storing > /tmp/test_bc.bcfks] > > Wed Nov 25 11:20:10 CST 2020 (END TIME)(Almost 4 seconds) > > [root@test-host-2 ~]# uname -a > Linux test-host-2 3.10.0-327.el7.x86_64 #1 SMP Thu Oct 29 17:29:29 > EDT 2015 x86_64 x86_64 x86_64 GNU/Linux > [root@test-host-2 ~]# cat /etc/redhat-release Red Hat Enterprise Linux > Server release 7.2 (Maipo) > [root@test-host-2 ~]# > > Red Hat Enterprise Linux Server release 7.2 (Maipo) > [root@test-host-2 ~]# /usr/openv/java/jre/bin/java -version java > version "1.8.0_261" > Java(TM) SE Runtime Environment (build 1.8.0_261-b33) Java HotSpot(TM) > 64-Bit Server VM (build 25.261-b33, mixed mode) > [root@test-host-2 ~]# > > > Since the keytool is literally taking minutes (specifically on RHEL > 7.3 as you can see above), enabling FIPS OOTB has become a challenge > as it has resulted in some our test suites timing out. What I see is that on two servers were everything is the same (except for the RHEL version... weird; RHEL 7.2 and 7.3 have identical kernel versions?), two identical command-lines take different amounts of time. In both cases, you are using BC with FIPS enabled. The reason is that one of the servers is starved for entropy and the other one is not. Some operations require a LOT of entropy (like generating an RSA key) and others require less entropy, but each of those operations consumes some of the system's entropy as they occur. When you run out, processes block waiting for it, and it's only created slowly as random hardware events are sampled to generate that "high quality randomness". So it can take a while. Some servers have hardware that generates entropy faster, some servers have usage profiles that cause certain hardware events to occur more often and t
RE: [EXTERNAL] Re: Bouncy Castle FIPS on RHEL 7.3
Thank you Chris for the inputs. Admittedly, I didn’t know the internals of Sun JCE/JSSE vs BC JCE. Pasting sample output and it indeed is taking minutes on RHEL 7.3. Not sure if I am indeed missing some trick here. RHEL 7.3 --- test-host-1:~ # date ; /usr/openv/java/jre/bin/keytool -providerpath /root/Downloads/bc-fips-1.0.2.jar -providerclass org.bouncycastle.jcajce.provider.BouncyCastleFipsProvider -genkeypair -keyalg RSA -keypass "Test123" -validity 3650 -dname "CN=Amit_HostName, ou=My_Org_Unit, o=My_Org" -storepass "Test123" -keystore "/tmp/test_bc.bcfks" -storetype BCFKS -v -alias abcd ; date Wed Nov 25 10:52:56 CST 2020 (START TIME) Generating 2,048 bit RSA key pair and self-signed certificate (SHA256withRSA) with a validity of 3,650 days for: CN=Amit_HostName, OU=My_Org_Unit, O=My_Org [Storing /tmp/test_bc.bcfks] Wed Nov 25 10:58:11 CST 2020 (END TIME) (Almost 6 minutes) test-host-1:~ # uname -a Linux test-host-1 3.10.0-514.el7.x86_64 #1 SMP Wed Oct 19 11:24:13 EDT 2016 x86_64 x86_64 x86_64 GNU/Linux test-host-1:~ # cat /etc/redhat-release Red Hat Enterprise Linux Server release 7.3 (Maipo) test-host-1:~ # test-host-1:~ # /usr/openv/java/jre/bin/java -version java version "1.8.0_271" Java(TM) SE Runtime Environment (build 1.8.0_271-b09) Java HotSpot(TM) 64-Bit Server VM (build 25.271-b09, mixed mode) test-host-1:~ # RHEL 7.2 - [root@test-host-2 ~]# date ; /usr/openv/java/jre/bin/keytool -providerpath /root/bc-fips-1.0.2.jar -providerclass org.bouncycastle.jcajce.provider.BouncyCastleFipsProvider -genkeypair -keyalg RSA -keypass "Test123" -validity 3650 -dname "CN=Amit_HostName, ou=My_Org_Unit, o=My_Org" -storepass "Test123" -keystore "/tmp/test_bc.bcfks" -storetype BCFKS -v -alias abcd ; date Wed Nov 25 11:20:06 CST 2020 (START TIME) Generating 2,048 bit RSA key pair and self-signed certificate (SHA256withRSA) with a validity of 3,650 days for: CN=Amit_HostName, OU=My_Org_Unit, O=My_Org [Storing /tmp/test_bc.bcfks] Wed Nov 25 11:20:10 CST 2020 (END TIME)(Almost 4 seconds) [root@test-host-2 ~]# uname -a Linux test-host-2 3.10.0-327.el7.x86_64 #1 SMP Thu Oct 29 17:29:29 EDT 2015 x86_64 x86_64 x86_64 GNU/Linux [root@test-host-2 ~]# cat /etc/redhat-release Red Hat Enterprise Linux Server release 7.2 (Maipo) [root@test-host-2 ~]# Red Hat Enterprise Linux Server release 7.2 (Maipo) [root@test-host-2 ~]# /usr/openv/java/jre/bin/java -version java version "1.8.0_261" Java(TM) SE Runtime Environment (build 1.8.0_261-b33) Java HotSpot(TM) 64-Bit Server VM (build 25.261-b33, mixed mode) [root@test-host-2 ~]# Since the keytool is literally taking minutes (specifically on RHEL 7.3 as you can see above), enabling FIPS OOTB has become a challenge as it has resulted in some our test suites timing out. Tomcat is very much a core of our product and configuration and starting Tomcat in timely manner (FIPS or no FIPS) has been a critical requirement. And now, with this issue, test suites timing out, hard to convince to get the suite timeouts increased. Thanks, Amit -Original Message- From: Christopher Schultz Sent: Wednesday, November 25, 2020 10:33 AM To: users@tomcat.apache.org Subject: [EXTERNAL] Re: Bouncy Castle FIPS on RHEL 7.3 Amit, On 11/24/20 11:21, Amit Pande wrote: > Probably not directly related to Tomcat but still sharing. Advanced > apologies for that. > > I am using bouncy castle FIPS library and observed that specifically > on RHEL 7.3, the library usage is causing tremendous slowness. Note that BC is pure-Java, so you should pretty much expect "tremendous slowness". The reason that the Sun JCE/JSSE provider is (or can be) very fast is because it's using both native code (which is only marginally faster than well-JIT'ed Java bytecode, if at all) and also hardware support when it's available. There is no way that I know of for BC's pure-Java crypto implementations to use hardware acceleration. AES on silicon is *much* faster than AES in software. > e.g. below key tool command taking several minutes to finish. Uhh... that's not software versus hardware. You might expect an order of magnitude difference between BC and hardware-accelerated SunJCE. But minutes to generate a 2048-bit RSA key? Something is wrong. > keytool -providerpath /root/Downloads/bc-fips-1.0.2.jar -providerclass > org.bouncycastle.jcajce.provider.BouncyCastleFipsProvider -genkeypair > -keyalg RSA -keypass "Test123" -validity 3650 -dname > "CN=Test_HostName, ou=My Org Unit, o=My Org" -storepass "Test123" > -keystore "/tmp/test_bc.bcfks" -storetype BCFKS -v -alias test_entry > > However, when I add the JVM option > -J-Djava.security.egd=file:/dev/./urandom instead of the default > /dev/random, all problems go
RE: [EXTERNAL] Re: Can Tomcat 9 be FIPS compliant without OpenSSL?
Avik, Did you happen to try out the steps in README https://github.com/amitlpande/tomcat-9-fips here? I am looking for feedback from the community before I could add these steps (and some more) on Tomcat Security FAQ page. So, really appreciate your (and others') feedback. The steps above rely purely on JSSE and JCA/JCE providers, no OpenSSL use. These steps will enable a plain vanilla Tomcat to run in FIPS compliant mode. And as Chris mentioned below, we need to ensure any web app deployed within the Tomcat use FIPS compliant constructs. Thanks, Amit -Original Message- From: Christopher Schultz Sent: Friday, November 6, 2020 3:40 PM To: Tomcat Users List ; Avik Ray Subject: [EXTERNAL] Re: Can Tomcat 9 be FIPS compliant without OpenSSL? Avik, On 11/6/20 14:50, Avik Ray wrote: > Thanks a lot Anil for the detailed readme, and Martin for pointing me to it. > > We have done most of these configs. Are these steps sufficient to > ensure that all incoming and outgoing TLS connections are FIPS compliant? This isn't something that the Tomcat community can really comment on. If you have a requirement to be FIPS-compliant, then you will need to evaluate whether of not you have met that requirement yourself. > Or is there also a need to compile an APR connector with an underlying > implementation of openssl? You do not NEED to do this, but it is a possibility that will allow you to definitely put the crypto engine into "FIPS mode". > Is the APR approach just an alternative to the JSSE approach covered > in Anil's readme, and both hold equally good to be FIPS compliant? Theoretically, yes. It's also possible, I believe, to make The Sun/Oracle JSSE provider FIPS compliant. Hmm maybe not: https://stackoverflow.com/a/5047855/276232 (FYI Stephen Colebourne tends to know what he's talking about.) It's a little unclear to me whether or not this is possible, while OpenSSL has very good documentation for how to build a FIPS-compliant binary library and then put it in the right mode. How FIPS-compliant do you actually need to be? It's pretty trivial to make sure that you support certain algorithms, etc. and that you disable other ones. FIPS, however, technically requires that you enable certain algorithms that really should no longer be used. These days, strict FIPS compliance is IMHO a risk to be avoided. -chris > On Fri, 6 Nov, 2020, 12:51 Martin Grigorov, wrote: > >> Hi, >> >> On Fri, Nov 6, 2020 at 8:57 AM Avik Ray wrote: >> >>> Dear team, >>> Sending this query again after subscribing to the mailing list. Sent >>> it originally 3 days back, but just saw an error response in the >>> spam folder asking to subscribe first. >>> >>> We are using Tomcat 9.0.37 x64 on Windows Server 2016 OS and the NIO >>> connector with JSSE, without an underlying OpenSSL. >>> >>> As per Tomcat 9 docs, the only mention of FIPS compliant operation I >>> see is in the config of APR lifecycle listener, with the expectation >>> of an underlying OpenSSL implementation that can be set to FIPS >>> enabled mode. Ref: >>> https://tomcat.apache.org/tomcat-9.0-doc/config/listeners.html >>> >>> Is it possible to be FIPS compliant with the usage of Tomcat, >>> without the above setting? We were thinking of using BouncyCastle >>> FIPS as the underlying Java crypto provider instead of OpenSSL for >>> multiple reasons. >>> >>> Are there any other dependencies Tomcat has on the underlying stack, >>> besides that provided by a Java crypto provider like BC-FIPS, having >>> a bearing on FIPS compliance? >>> >>> Please advise, as this is urgent for a FIPS compliance decision. >>> >> >> Please check the README of this project - >> https://github.com/amitlpande/tomcat-9-fips >> Amit Pande recently shared it here at users@. >> >> Regards, >> Martin >> >> >>> >>> Thanks, >>> Avik Ray >>> >>> >>> - 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
Bouncy Castle FIPS on RHEL 7.3
Probably not directly related to Tomcat but still sharing. Advanced apologies for that. I am using bouncy castle FIPS library and observed that specifically on RHEL 7.3, the library usage is causing tremendous slowness. e.g. below key tool command taking several minutes to finish. keytool -providerpath /root/Downloads/bc-fips-1.0.2.jar -providerclass org.bouncycastle.jcajce.provider.BouncyCastleFipsProvider -genkeypair -keyalg RSA -keypass "Test123" -validity 3650 -dname "CN=Test_HostName, ou=My Org Unit, o=My Org" -storepass "Test123" -keystore "/tmp/test_bc.bcfks" -storetype BCFKS -v -alias test_entry However, when I add the JVM option -J-Djava.security.egd=file:/dev/./urandom instead of the default /dev/random, all problems go away. It's rather strange that multiple 7.3 RHEL systems are showing this behavior very consistently. RHEL 7.2, 8.0 seem just fine in my testing. No issues when using /dev/random along with JKS type key stores (including RHEL 7.3). Even Tomcat is flagging the slowness to generate the secure random numbers. "17-Nov-2020 19:24:59.142 WARNING [Catalina-utility-2] org.apache.catalina.util.SessionIdGeneratorBase.createSecureRandom Creation of SecureRandom instance for session ID generation using [SHA1PRNG] took [68,745] milliseconds." Apparently, according to FIPS experts we should not use /dev/./urandom. So, while I continue to explore further, sharing this in case any one has seen this behavior or be aware of such potential issue as it may tie in to their Tomcat (or web apps to be deployed in Tomcat). Thanks, Amit
Re: [EXTERNAL] Re: Embedded vs Standalone Tomcat
Thank you so much Igal for the inputs. Thanks, Amit Thanks, Amit From: Igal Sapir Sent: Sunday, October 18, 2020 11:36:22 AM To: Tomcat Users List Subject: [EXTERNAL] Re: Embedded vs Standalone Tomcat Amit, On Fri, Oct 16, 2020 at 8:32 AM Amit Pande wrote: > My apologies in advance if this has been already discussed in the group. I > am looking for experiences of the community, any nitpicks, etc. > > Currently we are using standalone Tomcat version (9.x) to host a web > applications which are essentially hosting REST APIs. > We plan to move to micro services model where each web application > (logical unit of related APIs) will be hosted as a different process. > > With this mind, I wanted to evaluate the embedded version of Tomcat. > The code for both is the same. The part that we refer to as "Embedded" Tomcat contains most of the implementation. The "Standalone" simply adds a wrapper around the "Embedded" code that allows you to easily run Tomcat using configuration files, startup scripts, service installers, etc. > 1. Is there any guidance around when to use what? > If you have a standard deployment then use "Standalone". If you deploy a different application and Tomcat is used as a component in it, you can consider adding the wrapper and launch code yourself, using the "Embedded" version. If you plan to write a wrapper for "Embedded" that will do exactly what the "Standalone" version does then you will likely spend much resources for no reason, possibly introducing bugs during the process. > 2. Are there any feature disparities between standalone Tomcat and > embedded version? We have fairly extended Tomcat classes for use cases like > automatic certificate renewal, not having to mention is plain-text password > in server.xml for key stores, hooking in custom security provider (for > FIPS) for Tomcat JVM. etc. So we ideally wouldn't want to lose any of such > capabilities when we move to the embedded version. > Same code, I don't see any reason to believe that something would not work as long as the wrapper code that you add to launch the "Embedded" code knows how to utilize those. > 3. Currently, we have written a Windows SCM service wrapper and manage > our Tomcat JVM via that (on Windows). Would there be any issue with > embedded Tomcat if we want to have SCM service wrapper? > Same as above. > 4. How is the upgrade process different for embedded version? > Currently, we ship Tomcat with our product and have a well-defined process > to upgrade Tomcat even with older versions of our product deployed in > customers' environment. > Very similar process - you will have to update the Tomcat JARs and restart the service. As always you will have to check and test that no breaking changes were made in the newer version, though those are rather rare IMO. > 5. Externalizing the configuration (like we can do that via web.xml, > server.xml, context.xml) - any issues, limitations here? > You can set the "Embedded" Tomcat to use the web.xml. If you want to use server.xml and context.xml then you should really revisit question/answer 1) above. > 6. Any differences with resource usages (e.g. heap)? > Nope. It's still a JVM. If you use the same JVM args for both then you should expect similar results. HTH, Igal > > Any help is greatly appreciated. > > Thanks, > Amit > >
Embedded vs Standalone Tomcat
My apologies in advance if this has been already discussed in the group. I am looking for experiences of the community, any nitpicks, etc. Currently we are using standalone Tomcat version (9.x) to host a web applications which are essentially hosting REST APIs. We plan to move to micro services model where each web application (logical unit of related APIs) will be hosted as a different process. With this mind, I wanted to evaluate the embedded version of Tomcat. 1. Is there any guidance around when to use what? 2. Are there any feature disparities between standalone Tomcat and embedded version? We have fairly extended Tomcat classes for use cases like automatic certificate renewal, not having to mention is plain-text password in server.xml for key stores, hooking in custom security provider (for FIPS) for Tomcat JVM. etc. So we ideally wouldn't want to lose any of such capabilities when we move to the embedded version. 3. Currently, we have written a Windows SCM service wrapper and manage our Tomcat JVM via that (on Windows). Would there be any issue with embedded Tomcat if we want to have SCM service wrapper? 4. How is the upgrade process different for embedded version? Currently, we ship Tomcat with our product and have a well-defined process to upgrade Tomcat even with older versions of our product deployed in customers' environment. 5. Externalizing the configuration (like we can do that via web.xml, server.xml, context.xml) - any issues, limitations here? 6. Any differences with resource usages (e.g. heap)? Any help is greatly appreciated. Thanks, Amit
RE: [EXTERNAL] Re: Enabling FIPS for Tomcat
Thank you Mark! Will work on getting this added to the Wiki page. Would appreciate feedback from all to confirm accuracy/usefulness. Thanks, Amit -Original Message- From: Mark Thomas Sent: Tuesday, September 29, 2020 1:40 PM To: users@tomcat.apache.org Subject: [EXTERNAL] Re: Enabling FIPS for Tomcat On 29/09/2020 16:25, Amit Pande wrote: > Dear all, > > The link below documents how to enable FIPS (using Bouncy Castle) for Tomcat. > > https://github.com/amitlpande/tomcat-9-fips > > Kindly let me know your inputs if this needs any corrections, enhancements. > > Also, a request to Tomcat leads: It is possible for these steps to be > part of (extended) Tomcat documentation? Even if currently it uses > Bouncy Castle as FIPS JCA/JCE provider, with minor changes it would > work for any other provider too (e.g. CryptoComply for Java / CCJ from > Safelogic) You can always create a page in the wiki. Maybe "FAQ > Security > FIPS". You'll need to create an account and then ask (on this list is fine) for write access. 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
Enabling FIPS for Tomcat
Dear all, The link below documents how to enable FIPS (using Bouncy Castle) for Tomcat. https://github.com/amitlpande/tomcat-9-fips Kindly let me know your inputs if this needs any corrections, enhancements. Also, a request to Tomcat leads: It is possible for these steps to be part of (extended) Tomcat documentation? Even if currently it uses Bouncy Castle as FIPS JCA/JCE provider, with minor changes it would work for any other provider too (e.g. CryptoComply for Java / CCJ from Safelogic) Thanks, Amit
Mitigating slow HTTP headers vulnerability
(My apologies if this has been discussed already.)
Slow HTTP headers vulnerability was reported by scanner tool, on Tomcat 8.5.54.
There might be not any perfect solution to address this issue, but wanted to
understand some of the best practices to mitigate this vulnerability.
https://stackoverflow.com/questions/49442855/mitigating-slow-http-post-vulnerability-on-tomcat-8
Some recommendations from above link seem reasonable ("We reduced the
connectionTimeout="8000" and scan is passed" - This didn't sound very
convincing, though). Is there anything more than can be done to address this?
We're trying to avoid putting reverse proxy in front of Tomcat as we do have
our own pass-through proxy but it doesn't have any special capabilities to
avoid this vulnerability like some reverse proxies (e.g. ngnix) have.
Appreciate the inputs here.
Thanks,
Amit
RE: [EXTERNAL] Re: Ensuring clean Tomcat shutdown
Thank you Luis for the inputs. Yes, we do use the listeners and "contextDestroyed" and clean up the resources. But with many team members working, wanted to have some automated check to ensure cleaning up wasn't missed. Thanks, Amit -Original Message- From: Luis Rodríguez Fernández Sent: Monday, June 8, 2020 3:42 AM To: Tomcat Users List Subject: [EXTERNAL] Re: Ensuring clean Tomcat shutdown Hello Amit, Well, your approach will work. Personally, I do not like very much to parse logs. We, for instance, in our tomcat instances we provide an application that queries the status of the deployed apps, see below. If you have control in the code of "AAA" application I would suggest you to implement contextDestroyed [1] and make a clean up of your resources (db connections, etc.) The catalina stop works beautifully in linux. I must to confess that it is being a while since I do not have a look at the catalina.bat one :) Hope it helps, Luis [1] https://tomcat.apache.org/tomcat-9.0-doc/servletapi/javax/servlet/ServletContextListener.html#contextDestroyed-javax.servlet.ServletContextEvent- // From Registry javadocs: It provides methods to create and // manipulate model mbeans and simplify their use.protected transient Registry registry;private static final String ALL_WEB_MODULES_QRY = "*:j2eeType=WebModule,*"; // Get all modules (contexts) // Retrieve the MBean serverregistry = Registry.getRegistry(null, null);mBeanServer = Registry.getRegistry(null, null).getMBeanServer();Set objectNames = mBeanServer.queryNames(new ObjectName(ALL_WEB_MODULES_QRY), null); El dom., 7 jun. 2020 a las 3:50, Amit Pande () escribió: > When the application does not clean up the resources, during shutdown, > we see WARNINGs in Catalina logs: > > "WARNING [Catalina-utility-21] > org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThread > s The web application [AAA] appears to have started a thread named > [BBB] but has failed to stop it. This is very likely to create a > memory leak. Stack trace of thread:" > > I wanted to ensure a clean Tomcat shutdown and thinking of an > automated > test: > > 1. Stop Tomcat > 2. Parse/grep Catalina logs for warnings like above > 3. If found, fail the test, if not pass > > Is there a better/elegant way to achieve this? E.g. using life cycle > listeners? > > Also, the catalina stop option (where a kill is attempted after n > seconds are passed) works for all platforms, is my understanding correct? > > Thanks, > Amit > -- "Ever tried. Ever failed. No matter. Try Again. Fail again. Fail better." - Samuel Beckett
Ensuring clean Tomcat shutdown
When the application does not clean up the resources, during shutdown, we see WARNINGs in Catalina logs: "WARNING [Catalina-utility-21] org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The web application [AAA] appears to have started a thread named [BBB] but has failed to stop it. This is very likely to create a memory leak. Stack trace of thread:" I wanted to ensure a clean Tomcat shutdown and thinking of an automated test: 1. Stop Tomcat 2. Parse/grep Catalina logs for warnings like above 3. If found, fail the test, if not pass Is there a better/elegant way to achieve this? E.g. using life cycle listeners? Also, the catalina stop option (where a kill is attempted after n seconds are passed) works for all platforms, is my understanding correct? Thanks, Amit
Re: [EXTERNAL] Re: Query regarding bindOnInit default value..
Thanks for the inputs, Mark. Thanks, Amit > On Mar 29, 2020, at 5:06 PM, Mark Thomas wrote: > > On 29/03/2020 08:11, Amit Pande wrote: >> Hello all, >> >> I was exploring Tomcat configuration which doesn't accept requests until the >> web application is deployed. >> >> >> "bindOnInit" connector attributes when set to false, makes socket bind when >> the connector starts and not when the connector is initialized. >> >> Wanted to know, why the default value of this is not set to false? What are >> the use cases where the default of "true" is useful? > > When you want to change the connector configuration (stop, change > config, start) without refusing any new connections. Typically reverse > proxy scenarios. There should be some discussion on this in the archives > (quite a while ago now), I think around the time the feature was introduced. > >> Setting this value to false, I could see "connection refused" error on >> client side when they made requests to Tomcat when the application >> deployment was in-progress. >> When this is set to "true", all requests during when the application >> deployment wasn't complete, I could see failed SSL handshakes in access logs. > > That indicates that the time taken for the applications to deploy > exceeds the client read timeout (or write timeout if it is trying to > post something bigger than the network buffers can hold). > > Mark > > >> >> Wanted to understand more about the current default of true before I change >> the default. >> >> Thanks, >> Amit >> > > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org >
Query regarding bindOnInit default value..
Hello all, I was exploring Tomcat configuration which doesn't accept requests until the web application is deployed. "bindOnInit" connector attributes when set to false, makes socket bind when the connector starts and not when the connector is initialized. Wanted to know, why the default value of this is not set to false? What are the use cases where the default of "true" is useful? Setting this value to false, I could see "connection refused" error on client side when they made requests to Tomcat when the application deployment was in-progress. When this is set to "true", all requests during when the application deployment wasn't complete, I could see failed SSL handshakes in access logs. Wanted to understand more about the current default of true before I change the default. Thanks, Amit
RE: [EXTERNAL] Re: Uploads breaking post upgrade to 9.0.31
Thank you so much Mark! Moving to Tomcat 9.0.33 indeed solved the problem I was facing. Thanks, Amit -Original Message- From: Mark Thomas Sent: Tuesday, March 17, 2020 1:06 PM To: users@tomcat.apache.org Subject: Re: [EXTERNAL] Re: Uploads breaking post upgrade to 9.0.31 On 17/03/2020 17:56, Amit Pande wrote: > Using Tomcat 9.0.31. > > When using large JSON payload (little less than 2 MB) for POST requests, randomly (all random failures seen are on Windows and not on *ix), we are seeing: > > JSON parse error: Unexpected end-of-input in VALUE_STRING; nested exception is com.fasterxml.jackson.databind.JsonMappingException: Unexpected end-of-input in VALUE_STRING at [Source: (PushbackInputStream); line: 1, column: 17] (through reference chain: com.abc.xyz ["str"]) - JSON parse error: Unexpected end-of-input in VALUE_STRING; nested exception is com.fasterxml.jackson.databind.JsonMappingException: Unexpected end-of-input in VALUE_STRING at [Source: (PushbackInputStream); line: 1, column: 17] (through reference chain: com.abc.xyz["str"])at > > For smaller payloads, no issues are observed. > > Will this also be addressed by upgrading to 9.0.32/33? Maybe. The only way for you to be sure that the issue you describe is the same as Bug 64202 is for you to download 9.0.33 and test it in your test environment. Mark > > Thanks, > Amit > > -Original Message- > From: Manuel Dominguez Sarmiento > Sent: Tuesday, March 17, 2020 10:52 AM > To: Tomcat Users List ; Christopher Schultz > Subject: [EXTERNAL] Re: Uploads breaking post upgrade to 9.0.31 > > Great, I just saw that :-) > > On 17/03/2020 11:24, Christopher Schultz wrote: > Manuel. > > On 3/17/20 09:25, Manuel Dominguez Sarmiento wrote: >>>> Hi Mark, when is 9.0.32 expected to be released? We've seen this >>>> issue reported by several users, even if we haven't run into this >>>> particular case directly (yet) > 9.0.33 was announced about 20 minutes ago :) > > -chris > >>>> On 17/03/2020 09:51, Mark Thomas wrote: >>>>> https://bz.apache.org/bugzilla/show_bug.cgi?id=64202 >>>>> >>>>> Mark >>>>> >>>>> On 17/03/2020 11:46, Srijith Kochunni wrote: >>>>>> Hi All, >>>>>> >>>>>> >>>>>> >>>>>> This is to seek help on a strange issue that we are observing. >>>>>> We recently did a minor upgrade of Tomcat from 9.0.30 to 9.0.31, >>>>>> in our application, in order to address vulnerability in AJP >>>>>> connector. Ever since then we have started seeing upload failures >>>>>> with our upload servlet when processing large files. >>>>>> Small files do get uploaded, but when we upload large files and >>>>>> we do Multipart file upload, we are randomly and yet consistently >>>>>> seeing that we get the following exception. >>>>>> >>>>>> >>>>>> >>>>>> [org.apache.commons.fileupload.FileUploadBase$IOFileUploadException: >>>>>> >>>>>> > Processing of multipart/form-data request failed. Stream ended >>>>>> unexpectedly >>>>>> >>>>>> at >>>>>> org.apache.commons.fileupload.FileUploadBase.parseRequest(FileUpl >>>>>> oa >>>>>> d > Base.java:351) >>>>>> >>>>>> >>>>>> > >>>>>> Caused by: >>>>>> org.apache.commons.fileupload.MultipartStream$MalformedStreamExce >>>>>> pt >>>>>> i > on: >>>>>> > Stream ended unexpectedly >>>>>> at >>>>>> org.apache.commons.fileupload.MultipartStream$ItemInputStream.mak >>>>>> eA >>>>>> v > ailable(MultipartStream.java:1005) >>>>>> >>>>>> >>>>>> > at >>>>>> org.apache.commons.fileupload.MultipartStream$ItemInputStream.rea >>>>>> d( >>>>>> M > ultipartStream.java:903) >>>>>> >>>>>> >>>>>> > at java.io.InputStream.read(InputStream.java:101) >>>>>> at >>>>>> org.apache.commons.fileupload.util.Streams.copy(Streams.java:100) >>>>>> >>>>>> >>>>>> > at >>>>>> org.apache.commo
RE: [EXTERNAL] Re: Uploads breaking post upgrade to 9.0.31
Using Tomcat 9.0.31. When using large JSON payload (little less than 2 MB) for POST requests, randomly (all random failures seen are on Windows and not on *ix), we are seeing: JSON parse error: Unexpected end-of-input in VALUE_STRING; nested exception is com.fasterxml.jackson.databind.JsonMappingException: Unexpected end-of-input in VALUE_STRING at [Source: (PushbackInputStream); line: 1, column: 17] (through reference chain: com.abc.xyz ["str"]) - JSON parse error: Unexpected end-of-input in VALUE_STRING; nested exception is com.fasterxml.jackson.databind.JsonMappingException: Unexpected end-of-input in VALUE_STRING at [Source: (PushbackInputStream); line: 1, column: 17] (through reference chain: com.abc.xyz["str"])at For smaller payloads, no issues are observed. Will this also be addressed by upgrading to 9.0.32/33? Thanks, Amit -Original Message- From: Manuel Dominguez Sarmiento Sent: Tuesday, March 17, 2020 10:52 AM To: Tomcat Users List ; Christopher Schultz Subject: [EXTERNAL] Re: Uploads breaking post upgrade to 9.0.31 Great, I just saw that :-) On 17/03/2020 11:24, Christopher Schultz wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Manuel. > > On 3/17/20 09:25, Manuel Dominguez Sarmiento wrote: >> Hi Mark, when is 9.0.32 expected to be released? We've seen this >> issue reported by several users, even if we haven't run into this >> particular case directly (yet) > 9.0.33 was announced about 20 minutes ago :) > > - -chris > >> On 17/03/2020 09:51, Mark Thomas wrote: >>> https://bz.apache.org/bugzilla/show_bug.cgi?id=64202 >>> >>> Mark >>> >>> On 17/03/2020 11:46, Srijith Kochunni wrote: >>>> Hi All, >>>> >>>> >>>> >>>> This is to seek help on a strange issue that we are observing. >>>> We recently did a minor upgrade of Tomcat from 9.0.30 to 9.0.31, in >>>> our application, in order to address vulnerability in AJP >>>> connector. Ever since then we have started seeing upload failures >>>> with our upload servlet when processing large files. >>>> Small files do get uploaded, but when we upload large files and we >>>> do Multipart file upload, we are randomly and yet consistently >>>> seeing that we get the following exception. >>>> >>>> >>>> >>>> [org.apache.commons.fileupload.FileUploadBase$IOFileUploadException: >>>> >>>> > Processing of multipart/form-data request failed. Stream ended >>>> unexpectedly >>>> >>>> at >>>> org.apache.commons.fileupload.FileUploadBase.parseRequest(FileUploa >>>> d > Base.java:351) >>>> >>>> >>>> > >>>> Caused by: >>>> org.apache.commons.fileupload.MultipartStream$MalformedStreamExcept >>>> i > on: >>>> > Stream ended unexpectedly >>>> at >>>> org.apache.commons.fileupload.MultipartStream$ItemInputStream.makeA >>>> v > ailable(MultipartStream.java:1005) >>>> >>>> >>>> > at >>>> org.apache.commons.fileupload.MultipartStream$ItemInputStream.read( >>>> M > ultipartStream.java:903) >>>> >>>> >>>> > at java.io.InputStream.read(InputStream.java:101) >>>> at >>>> org.apache.commons.fileupload.util.Streams.copy(Streams.java:100) >>>> >>>> >>>> > at >>>> org.apache.commons.fileupload.util.Streams.copy(Streams.java:70) >>>> >>>> >>>> > at >>>> org.apache.commons.fileupload.FileUploadBase.parseRequest(FileUploa >>>> d > Base.java:347) >>>> >>>> >>>> >>>> >>>> > It appears that the connection is getting reset in the >>>> middle of the upload, but the client is very much up and we get >>>> PR_CONNECT_RESET_ERROR on the browser. >>>> >>>> >>>> >>>> My code on the server side is as simple as >>>> >>>> >>>> >>>> DiskFileItemFactory factory = new DiskFileItemFactory(); >>>> >>>> ServletFileUpload fileUpload = new ServletFileUpload(factory); >>>> >>>> >>>> >>>> List fileItems = fileUpload.parseRequest(originalRequest); >>>> >>>> >>>> >>>> >>>> >>>> We would like to know if anyone else has observed this and if there >>
Re: [EXTERNAL] [SECURITY] CVE-2019-10072 Apache Tomcat HTTP/2 DoS
Could you please clarify: Affected versions 8.5.0 to 8.5.40 Mitigation says: 8.5.40 or later What am I missing? > On Jun 20, 2019, at 2:25 PM, Mark Thomas wrote: > > CVE-2019-10072 Apache Tomcat HTTP/2 DoS > > Severity: Important > > Vendor: The Apache Software Foundation > > Versions Affected: > Apache Tomcat 9.0.0.M1 to 9.0.19 > Apache Tomcat 8.5.0 to 8.5.40 > > Description: > The fix for CVE-2019-0199 was incomplete and did not address connection > window exhaustion on write. By not sending WINDOW_UPDATE messages for > the connection window (stream 0) clients were able > to cause server-side threads to block eventually leading to thread > exhaustion and a DoS. > > Mitigation: > Users of affected versions should apply one of the following mitigations: > - Upgrade to Apache Tomcat 9.0.20 or later > - Upgrade to Apache Tomcat 8.5.40 or later > > Credit: > John Simpson of Trend Micro Security Research working with Trend > Micro's Zero Day Initiative > > References: > [1] http://tomcat.apache.org/security-9.html > [2] http://tomcat.apache.org/security-8.html > > - > 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: [EXTERNAL] Re: Request header too large..
Thanks Mark for the update. Seems like there is a potential bug in our client components which happened to keep on adding to existing header list. https://tomcat.apache.org/tomcat-8.5-doc/config/http.html From the documentation: maxHttpHeaderSize :The maximum size of the request and response HTTP header, specified in bytes. If not specified, this attribute is set to 8192 (8 KB). Although some online searches (e.g. https://serverfault.com/questions/56691/whats-the-maximum-url-length-in-tomcat) suggest that this maxHttpHeaderSize applies to request line as well, could the documentation be made more elaborate? Can we mention that this attribute puts the upper bound on combined size of all request headers and the request line? Thanks, Amit On 11/3/18, 4:39 AM, "Mark Thomas" wrote: On 03/11/2018 01:35, Amit Pande wrote: > Thanks Chris. Yes, I will soon send out the patch for review. Logically, I can see some hurdles for such a patch that are going to be difficult to overcome. Tomcat will process all of the received data up to the limit. It is on the subsequent read to get more data that the exception is thrown. The issue is how to determine which header is actually the problem as it may not be the one currently being read. Consider the following: ReqLine - 1024 bytes Headers - 5 * 128 bytes Header - 1 * 6*1024 bytes Headers - 5 * 128 bytes Is the problem the 6k header? The 1k request line? Has the client duplicated the block of 5 128 byte headers? Or is the request valid and Tomcat's limit too low? There is no way for Tomcat to determine where the root cause lies. The only reliable way to figure out what went wrong is for a knowledgeable system admin to look at the complete set of headers. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [EXTERNAL] Re: Request header too large..
Thanks Chris. Yes, I will soon send out the patch for review.
Thanks,
Amit
On 11/2/18, 5:25 PM, "Christopher Schultz"
wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Amit,
On 11/2/18 17:16, Amit Pande wrote:
> As per current implementation (below snippet is from 8.5.28), if
> the request header is too large (by default >8K, the default
> maxHttpHeaderSize), is thrown below error message is seen.
>
>
> For request -- 02-Nov-2018 15:15:47.649 INFO [catalina-exec-40]
> org.apache.coyote.http11.Http11Processor.service Error parsing HTTP
> request header Note: further occurrences of HTTP header parsing
> errors will be logged at DEBUG level.
> java.lang.IllegalArgumentException: Request header is too large at
> org.apache.coyote.http11.Http11InputBuffer.parseHeaders(Http11InputBuf
fer.java:575)
>
>
at
org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:70
3)
> at
> org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLigh
t.java:66)
>
>
at
org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractPro
tocol.java:790)
>
> For response—
>
> 02-Nov-2018 15:15:47.867 SEVERE [catalina-exec-40]
> org.apache.coyote.http11.Http11Processor.endRequest Error finishing
> response org.apache.coyote.http11.HeadersTooLargeException: An
> attempt was made to write more data to the response headers than
> there was room available in the buffer. Increase maxHttpHeaderSize
> on the connector or write less data into the response headers. at
> org.apache.coyote.http11.Http11OutputBuffer.checkLengthBeforeWrite(Htt
p11OutputBuffer.java:544)
>
>
at
org.apache.coyote.http11.Http11OutputBuffer.write(Http11OutputBuffer.jav
a:481)
> at
> org.apache.coyote.http11.Http11OutputBuffer.sendStatus(Http11OutputBuf
fer.java:361)
>
>
at
org.apache.coyote.http11.Http11Processor.prepareResponse(Http11Processor
.java:1339)
> at
> org.apache.coyote.AbstractProcessor.action(AbstractProcessor.java:260)
>
>
at
org.apache.coyote.http11.Http11Processor.endRequest(Http11Processor.java
:1523)
>
>
> However, this doesn’t tell us the name of the offending header
> which I think is valuable in debugging the issues.
>
> Do you feel it’s worth the enhancement request?
>
> Also, I noticed the comments
>
> “ // (1) Headers plus request line size does not exceed its limit
>
>
>
> // (2) There are enough bytes to avoid expanding the buffer when
>
>
> // reading body “
>
> It says request line size ..does that mean maxHttpHeaderSize comes
> in play for request line (which includes query params) as well?
Yes.
The request headers are read before selecting which context will
service the request. The request line, which not formally a part of
the "headers" per the HTTP spec, are considered to be "part of the
headers" as far as Tomcat is concerned, because they all share the
same buffer.
To locate the offending header, look at the end of the request, then
re-wind to the previous "\r\nheader:". If you don't find
"\r\nheader:", then it was the request line. But it could be request +
partial-header-name, so you'd have to be careful.
I'm not sure it's worth it to add a debugging enhancement (you
probably already know what your huge headers are), but I am by no
means the King of Tomcat: feel free to request that enhancement in BZ
and see if you can get some support.
If you write a patch/PR for it, it will almost certainly be added as
long as its not too intrusive :)
- -chris
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlvcztQACgkQHPApP6U8
pFhj+Q//QIMUy44I2SDH5kM7UeMk2SCB/5J5hW79RGfIGITFpmEMttBONF8wilg7
U7ldyjDuu2Msn+ynRPVg5lxf9pq3OQJKySv7xFc3AG4C44em4xRrJI8aHGsLxH5N
dQyyJY/oP61HzeiiiyDLYxQY3sidC+4gieOEJ2oG5ZsXJwFpvfc0Q1LyiIzN8fXa
o2PkH0B2kPsksgXD8WZLPXAFMgAUdmUu0wVzM0lt/kBvlG9LGW/vEd+fVeLrG93s
UEs3IrWT2aTWnOVyZl2LAPhL2GynfrDUmsmsc8EF6kljXiX3IWphaH9z1nbCpLFM
zDsUoIRpqm1sgXObV52zW8YbnaUzIEAZaI7lIlrOctRvc9ACeCvKkIc+aVylgnmR
zpEhFz/gOchl1T6x2+MXLHavch653F8OgYY52/TCqxQheVKSHjc2jJu9UTcb+7z0
EBbfeWvUeEdNd7edGORhKx6tJLotbRhF1Yr2sjxxkY8I31RGHv+ZlNStOuxr5uoI
0c68L2XGbe9gBaLbjopYOfb+Y8y73iX3wfJPKIlvXl8LkupA1wyg0NAwOn+ZDL2E
Rl865F3+DaaVaFoSRkpgp7pUrKfh9wi/N2CdCJ13hH6WY32/JD8+Z2X+YuRfMu6+
6dh+NiVvrQc998/gutkx+OnH+RTC0STJ
Request header too large..
As per current implementation (below snippet is from 8.5.28), if the request header is too large (by default >8K, the default maxHttpHeaderSize), is thrown below error message is seen. For request -- 02-Nov-2018 15:15:47.649 INFO [catalina-exec-40] org.apache.coyote.http11.Http11Processor.service Error parsing HTTP request header Note: further occurrences of HTTP header parsing errors will be logged at DEBUG level. java.lang.IllegalArgumentException: Request header is too large at org.apache.coyote.http11.Http11InputBuffer.parseHeaders(Http11InputBuffer.java:575) at org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:703) at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:66) at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:790) For response— 02-Nov-2018 15:15:47.867 SEVERE [catalina-exec-40] org.apache.coyote.http11.Http11Processor.endRequest Error finishing response org.apache.coyote.http11.HeadersTooLargeException: An attempt was made to write more data to the response headers than there was room available in the buffer. Increase maxHttpHeaderSize on the connector or write less data into the response headers. at org.apache.coyote.http11.Http11OutputBuffer.checkLengthBeforeWrite(Http11OutputBuffer.java:544) at org.apache.coyote.http11.Http11OutputBuffer.write(Http11OutputBuffer.java:481) at org.apache.coyote.http11.Http11OutputBuffer.sendStatus(Http11OutputBuffer.java:361) at org.apache.coyote.http11.Http11Processor.prepareResponse(Http11Processor.java:1339) at org.apache.coyote.AbstractProcessor.action(AbstractProcessor.java:260) at org.apache.coyote.http11.Http11Processor.endRequest(Http11Processor.java:1523) However, this doesn’t tell us the name of the offending header which I think is valuable in debugging the issues. Do you feel it’s worth the enhancement request? Also, I noticed the comments “ // (1) Headers plus request line size does not exceed its limit // (2) There are enough bytes to avoid expanding the buffer when // reading body “ It says request line size ..does that mean maxHttpHeaderSize comes in play for request line (which includes query params) as well? Thanks, Amit
Re: [EXTERNAL] Re: Hostnames with underscores
Yes, I did check the description, but did not find reference to underscore.
From the documentation:
“The value may be any combination of the following characters: " < > [ \ ] ^ `
{ | } . “
But I admit that I did not actually verify it and will see if these attributes
work for underscore too.
Thanks,
Amit
On Oct 26, 2018, at 12:02 PM, M. Manna
mailto:manme...@gmail.com>> wrote:
Have you checked the connector config doc for relaxedPathChars and
relaxedQueryChars?
On Fri, 26 Oct 2018 at 18:00, Amit Pande
mailto:amit.pa...@veritas.com>> wrote:
Hello all,
Recent Tomcat versions (8.5.32 I think) has made a stricter validation for
hostnames with underscores in it. (
https://bz.apache.org/bugzilla/show_bug.cgi?id=62371)
This is understandably for addressing security issues (
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-6816) and
enforcing RFC compliance, in some way.
Our recent upgrade to Tomcat (8.5.34), we observed:
Note: further occurrences of request parsing errors will be logged at
DEBUG level.
java.lang.IllegalArgumentException: The character [_] is never valid in a
domain name.
at
org.apache.tomcat.util.http.parser.HttpParser$DomainParseState.next(HttpParser.java:946)
at
org.apache.tomcat.util.http.parser.HttpParser.readHostDomainName(HttpParser.java:842)
at org.apache.tomcat.util.http.parser.Host.parse(Host.java:66)
at org.apache.tomcat.util.http.parser.Host.parse(Host.java:40)
at
org.apache.coyote.AbstractProcessor.parseHost(AbstractProcessor.java:286)
at
org.apache.coyote.http11.Http11Processor.prepareRequest(Http11Processor.java:1203)
at
org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:776)
at
org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:66)
at
org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:806)
at org.apache.tomcat.util.net<http://org.apache.tomcat.util.net>
.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1498)
at org.apache.tomcat.util.net<http://org.apache.tomcat.util.net>
.SocketProcessorBase.run(SocketProcessorBase.java:49)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.lang.Thread.run(Thread.java:748)
The main issue for us now is that, since we ship Tomcat with our product
(IOW Tomcat runs in customer environments), this will break our product
functionality if customers have hostnames with underscore. Ideally, they
should correct the host names (to be RFC compliant) but customers would be
really averse to change hostname as it might a widespread change in their
environments.
With Spring also, we ran into same issue but in later releases of Spring
this was fixed. I
Would it be a good idea to make this strict check configurable so that we
can continue to cater to our customers without breaking the functionality?
Are there any other alternates to help solve this issue?
Thanks,
Amit
Hostnames with underscores
Hello all, Recent Tomcat versions (8.5.32 I think) has made a stricter validation for hostnames with underscores in it. (https://bz.apache.org/bugzilla/show_bug.cgi?id=62371) This is understandably for addressing security issues (https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-6816) and enforcing RFC compliance, in some way. Our recent upgrade to Tomcat (8.5.34), we observed: Note: further occurrences of request parsing errors will be logged at DEBUG level. java.lang.IllegalArgumentException: The character [_] is never valid in a domain name. at org.apache.tomcat.util.http.parser.HttpParser$DomainParseState.next(HttpParser.java:946) at org.apache.tomcat.util.http.parser.HttpParser.readHostDomainName(HttpParser.java:842) at org.apache.tomcat.util.http.parser.Host.parse(Host.java:66) at org.apache.tomcat.util.http.parser.Host.parse(Host.java:40) at org.apache.coyote.AbstractProcessor.parseHost(AbstractProcessor.java:286) at org.apache.coyote.http11.Http11Processor.prepareRequest(Http11Processor.java:1203) at org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:776) at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:66) at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:806) at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1498) at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) at java.lang.Thread.run(Thread.java:748) The main issue for us now is that, since we ship Tomcat with our product (IOW Tomcat runs in customer environments), this will break our product functionality if customers have hostnames with underscore. Ideally, they should correct the host names (to be RFC compliant) but customers would be really averse to change hostname as it might a widespread change in their environments. With Spring also, we ran into same issue but in later releases of Spring this was fixed. I Would it be a good idea to make this strict check configurable so that we can continue to cater to our customers without breaking the functionality? Are there any other alternates to help solve this issue? Thanks, Amit
Re: [EXTERNAL] Re: Tomcat custom location for configuration
Thank you once again, Chris and Mark!
https://tomcat.apache.org/tomcat-9.0-doc/introduction.html#CATALINA_HOME_and_CATALINA_BASE
Was able to meet our requirement of moving Tomcat configuration to a custom
location using a different CATALINA_BASE.
The "-config" option will be cleaned up in next Tomcat release(s), right?
Thanks,
Amit
On 10/4/18, 12:15 PM, "Christopher Schultz"
wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Amit,
On 10/4/18 12:17, Amit Pande wrote:
> Thanks! I will take a detailed relook at using CATALINA_BASE and
> keep you posted.
>
>
> Also, since the "-config" option is there since 4.0.x time till
> now, would it be safe to assume that this option won't be
> deprecated since some users (admittedly not too many) might
> actually be using it? If it's going to stay, do you feel it's worth
> documenting (till the time it isn't actually deprecated with some
> alternate)?
>
> I agree while not desirable at the moment, using "-config" solves
> our problem. So, we might have to use this as last fallback
> option.
It sounds like this feature barely works and probably doesn't work in
many situations.
My vote would be to deprecate it immediately and remove it completely
in Tomcat 10.
I'm sorry, but I don't think I understand why you cannot use
CATALINA_BASE as "usual" in your situation.
- -chris
> On 10/4/18, 8:38 AM, "Mark Thomas" wrote:
>
> On 03/10/18 17:18, Amit Pande wrote:
>> Thank you so much, Mark!
>>
>> In our case, the server.xml contains some information which is
>> generated run time (pre-config before Tomcat is started) like the
>> paths to key store and trust store, cipher suites, etc.
>>
>> Also, we have an active-passive cluster setup in which only the
>> currently active node has the access to a shared disk which has
>> all our product configuration data including the key store,
>> trust store files needed in server.xml.
>>
>> We have a requirement to share the configuration across both the
>> nodes of the cluster to avoid keeping duplicate copies of
>> configuration (server.xml). And since some of the server.xml
>> configuration is generated runtime, it isn’t trivial in our case
>> to keep these copies in sync.
>>
>> This is the prime reason to have a shared Tomcat configuration.
>> We may also want, in future, to spawn and additional instance of
>> Tomcat with re-usable configuration (except adjusting the port
>> numbers ).
>>
>> The not-so-elegant choice we might have is to move the entire
>> Tomcat installation to this cluster aware shared storage but
>> defeats the purpose of having a shared disk for configuration
>> data and not the binaries.
>>
>> What alternates should we explore?
>
> You could look at using separate CATALINA_HOME and CATALINA_BASE.
> See
>
>
> Whether have the web applications on the node or the shared
> storage is arguable either way. If you want it on the node, just
> use an absolute path that points to someone on the node for
> appBase.
>
> 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
>
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlu2SrwACgkQHPApP6U8
pFjlHw/+OZ8FgsTCHvzIIAYBRdAQ+If0M3Q7Wpp7w/tqUYjbHgERPBiof2arPft5
ir2tfUh11M0YiUvTPXfzzq7BHe5sXsDQHTxLimN1gq6+WOlZVd3k//giFQUmcwsK
RZtKUQUnGWUsjJ/n7z4rWna+gdleukWQ0k7qgbRR/dAiaAUd2mRfy4LgKpHvTVex
y6SXSmcGZ963vzPuZurMIyfPY2iUxb7Y1dbC8Pv7J0vAWhw1we08t33oMJa3Pcp4
vgV2Ylc6nwyw4LpFcTdNOzWaLIKBwJ4zwv2rQW9Tp8zhiU6O5BfVmzP3Zo04K18x
z1Zvw9mhOISIWn0vE+k6WxU/t17UVKYonPUBwJ0JelVNBE/tGsCSwiHK67gBhs0F
K/+QN8+625TDcUmxYtTMdXQVel/ZvWCrdVZKCJlM3uHSsSySoPhkQU+gCt9PExx9
YIgxzzViI3NiIkeobf8VmBMtZKaYWLWa6+eSoVVmj8UA7Glj5/tvT8o1AXDerYEk
kNWojPCOMx1l6rgysrlX6pRY3ltDnqGmlkzhxrU72afUXMpZ9VhKVawZ5457SEan
mYWGR5o09lmUE4VBFt
Re: [EXTERNAL] Re: Tomcat custom location for configuration
Thanks! I will take a detailed relook at using CATALINA_BASE and keep you posted. Also, since the "-config" option is there since 4.0.x time till now, would it be safe to assume that this option won't be deprecated since some users (admittedly not too many) might actually be using it? If it's going to stay, do you feel it's worth documenting (till the time it isn't actually deprecated with some alternate)? I agree while not desirable at the moment, using "-config" solves our problem. So, we might have to use this as last fallback option. Thanks, Amit On 10/4/18, 8:38 AM, "Mark Thomas" wrote: On 03/10/18 17:18, Amit Pande wrote: > Thank you so much, Mark! > > In our case, the server.xml contains some information which is generated run time (pre-config before Tomcat is started) like the paths to key store and trust store, cipher suites, etc. > > Also, we have an active-passive cluster setup in which only the currently active node has the access to a shared disk which has all our product configuration data including the key store, trust store files needed in server.xml. > > We have a requirement to share the configuration across both the nodes of the cluster to avoid keeping duplicate copies of configuration (server.xml). And since some of the server.xml configuration is generated runtime, it isn’t trivial in our case to keep these copies in sync. > > This is the prime reason to have a shared Tomcat configuration. We may also want, in future, to spawn and additional instance of Tomcat with re-usable configuration (except adjusting the port numbers ). > > The not-so-elegant choice we might have is to move the entire Tomcat installation to this cluster aware shared storage but defeats the purpose of having a shared disk for configuration data and not the binaries. > > What alternates should we explore? You could look at using separate CATALINA_HOME and CATALINA_BASE. See https://tomcat.apache.org/tomcat-9.0-doc/introduction.html#CATALINA_HOME_and_CATALINA_BASE Whether have the web applications on the node or the shared storage is arguable either way. If you want it on the node, just use an absolute path that points to someone on the node for appBase. 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: [EXTERNAL] Re: Tomcat custom location for configuration
Thank you so much, Mark! In our case, the server.xml contains some information which is generated run time (pre-config before Tomcat is started) like the paths to key store and trust store, cipher suites, etc. Also, we have an active-passive cluster setup in which only the currently active node has the access to a shared disk which has all our product configuration data including the key store, trust store files needed in server.xml. We have a requirement to share the configuration across both the nodes of the cluster to avoid keeping duplicate copies of configuration (server.xml). And since some of the server.xml configuration is generated runtime, it isn’t trivial in our case to keep these copies in sync. This is the prime reason to have a shared Tomcat configuration. We may also want, in future, to spawn and additional instance of Tomcat with re-usable configuration (except adjusting the port numbers ). The not-so-elegant choice we might have is to move the entire Tomcat installation to this cluster aware shared storage but defeats the purpose of having a shared disk for configuration data and not the binaries. What alternates should we explore? Thanks, Amit On 10/3/18, 10:16 AM, "Mark Thomas" wrote: On 02/10/18 17:41, Amit Pande wrote: > Hello SMEs, > > I am looking at Tomcat documentation to see if there is a way to move the “/conf” to a custom location and use this path while running the startup/shutdown scripts. Why? What problem are you trying to solve? > I have looked at the https://github.com/apache/tomcat85/blob/TOMCAT_8_5_34/java/org/apache/catalina/startup/Catalina.java and confirmed we can pass a -config to the Tomcat scripts (catalina.bat/sh, startup.bat/sh, etc). > > Wanted to confirm: > > > 1. Why is “-config” option not documented as part of help of the startup/shutdown scripts? Is this a supported configuration that we can use without worrying about future breaking changes in this? It appears that this dates back to Tomcat 4.0.x (I couldn't find it in 3.3.x). It isn't something that I have seen used very much. If I had to guess, I'd say the option was added either when server.xml was the only configuration file or the location of the other configuration files could be specified in server.xml. Over the years additional configuration files were added to the default location and, because the -config option was little used, the requirement to make that location configurable wasn't considered. > 2. Currently, as part of “-config” option we’re able to pass on the path to server.xml only. What is required to be done so that entire Tomcat configuration (conf directory) can be moved to a custom location? Looks like a fair amount of work as $CATALINA_BASE/conf/ is hard-coded in a *lot* of places. Making it configurable is going to be very invasive. There would need to be a very strong justification for a change along those lines. > 3. I am still debugging why, but on Linux setups, I have observed “configtest” script isn’t working with “-config ”. I am seeing “WARNING: Unable to load server configuration from [path_to_server_dot_xml] Configuration error detected!”. Is this know issue on Linux system? It seemed to work fine for Windows. I suspect it is a bug. > Appreciate your inputs. At this point my recommendation would be to look at alternative solutions rather than using -config. Once we know what the requirement is, we can provide some advice. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Tomcat custom location for configuration
Hello SMEs, I am looking at Tomcat documentation to see if there is a way to move the “/conf” to a custom location and use this path while running the startup/shutdown scripts. I have looked at the https://github.com/apache/tomcat85/blob/TOMCAT_8_5_34/java/org/apache/catalina/startup/Catalina.java and confirmed we can pass a -config to the Tomcat scripts (catalina.bat/sh, startup.bat/sh, etc). Wanted to confirm: 1. Why is “-config” option not documented as part of help of the startup/shutdown scripts? Is this a supported configuration that we can use without worrying about future breaking changes in this? 2. Currently, as part of “-config” option we’re able to pass on the path to server.xml only. What is required to be done so that entire Tomcat configuration (conf directory) can be moved to a custom location? 3. I am still debugging why, but on Linux setups, I have observed “configtest” script isn’t working with “-config ”. I am seeing “WARNING: Unable to load server configuration from [path_to_server_dot_xml] Configuration error detected!”. Is this know issue on Linux system? It seemed to work fine for Windows. Appreciate your inputs. Thanks, Amit
Re: [EXTERNAL] Using CLIENT-CERT
Thank you so much Chris and Mark! Sincerely appreciate the inputs. Sent from my iPhone > On Apr 11, 2018, at 8:16 AM, Christopher Schultz > <ch...@christopherschultz.net> wrote: > > Mark and Amit, > >> On 4/10/18 2:21 AM, Mark Thomas wrote: >>> On 9 April 2018 23:29:43 BST, Amit Pande <amit.pa...@veritas.com> wrote: >>> Some more debugging here and I got some stuff working here. >>> >>> Only one question: >>> >>> It is not really clear from the documentation of "clientAuth" >>> >>> "Set to true if you want the SSL stack to require a valid certificate >>> chain from the client before accepting a connection. Set to want if you >>> want the SSL stack to request a client Certificate, but not fail if one >>> isn't presented. A false value (which is the default) will not require >>> a certificate chain unless the client requests a resource protected by >>> a security constraint that uses CLIENT-CERT authentication. See the SSL >>> HowTo for an example. That SSL HowTo also contains tips on using >>> per-user or per-session certificate-based clientAuth." >>> >>> So, if I am using a clientAuth="false" and relying on "CLIENT-CERT" >>> configuration, does that mean browsers won't prompt users to supply the >>> certificate when a protected resource is accessed? >> >> In that scenario the browser will prompt the user for a certificate if >> everything is correctly configured. >> >> However, it is possible that the browser will determine that it has no >> matching certificates and therefore decide not to display the certificate >> prompt. > > Also, sometimes browsers will "remember" your choice from a prior > interaction during the same browser session. So for example if you have > clientAuth="want" and you press "No/Cancel/[escape]/[close window]" the > browser may "remember" that you don't want to present a certificate. > > -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
Re: [EXTERNAL] Using CLIENT-CERT
Some more debugging here and I got some stuff working here. Only one question: It is not really clear from the documentation of "clientAuth" "Set to true if you want the SSL stack to require a valid certificate chain from the client before accepting a connection. Set to want if you want the SSL stack to request a client Certificate, but not fail if one isn't presented. A false value (which is the default) will not require a certificate chain unless the client requests a resource protected by a security constraint that uses CLIENT-CERT authentication. See the SSL HowTo for an example. That SSL HowTo also contains tips on using per-user or per-session certificate-based clientAuth." So, if I am using a clientAuth="false" and relying on "CLIENT-CERT" configuration, does that mean browsers won't prompt users to supply the certificate when a protected resource is accessed? Is it because in case of "CLIENT-CERT", the client is always expected to supply a certificate? If yes, is there any recommended practice to configure browser for this? Or application needs to take care of supplying one when accessing such a protected resource? Appreciate your inputs. On 4/8/18, 6:44 PM, "Amit Pande" <amit.pa...@veritas.com> wrote: I am trying to setup Tomcat (8.5.28) and the web-app correctly in order to get the mutual authentication (using client certificates) done but only for some recourses and not all. For instance, I have a “authenticate” API for which I want to enable the client certificate authentication. So, I want only a “/authenticate” URL to ask for a client certificate from the browser. I want to first validate if this client certificate is issued by a trusted CA. If yes, accept the request and invoke the “/authenticate” business logic which further validates the certificate/user against our own user database. Looking at Tomcat documentation “clientAuth=want” in server.xml seemed a potential option but the issue with that is when this results in asking for user certificate for all the URLs being invoked from the Browser (unless we tell Browser to remember the decision). Also, this approach results in renegotiation for every request. This is when I came across, “CLIENT-CERT” alternate, which can be configured only for certain URL (e.g. “/authenticate” in my case). However, I am not able to get it configured as expected. I issued a client certificate and imported in browser but still unable to get the browser pop-up which asks for the certificate to be sent. Debugging SSL level did not yield much. https://stackoverflow.com/questions/41438536/protecting-webresource-in-tomcat-8-5-with-client-cert This is the link that closely matches the requirement and I saw Chris’ input there. However, “Realm className="org.apache.catalina.realm.UserDatabaseRealm" allRolesMode="authOnly" resourceName="UserDatabase" /> “ In server.xml And My Secure Area /authenticate CONFIDENTIAL * In my web app’s web.xml. When I access the URL from browser, I expected to see a dialog asking for client-certificate and then a successful invocation of the “/authenticate”. However, from browser, I don’t get a pop-up and I get a HTTP 401 with below message. Message Cannot authenticate with the provided credentials Description The request has not been applied because it lacks valid authentication credentials for the target resource. Appreciate your help on this. Thanks, Amit - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Using CLIENT-CERT
I am trying to setup Tomcat (8.5.28) and the web-app correctly in order to get the mutual authentication (using client certificates) done but only for some recourses and not all. For instance, I have a “authenticate” API for which I want to enable the client certificate authentication. So, I want only a “/authenticate” URL to ask for a client certificate from the browser. I want to first validate if this client certificate is issued by a trusted CA. If yes, accept the request and invoke the “/authenticate” business logic which further validates the certificate/user against our own user database. Looking at Tomcat documentation “clientAuth=want” in server.xml seemed a potential option but the issue with that is when this results in asking for user certificate for all the URLs being invoked from the Browser (unless we tell Browser to remember the decision). Also, this approach results in renegotiation for every request. This is when I came across, “CLIENT-CERT” alternate, which can be configured only for certain URL (e.g. “/authenticate” in my case). However, I am not able to get it configured as expected. I issued a client certificate and imported in browser but still unable to get the browser pop-up which asks for the certificate to be sent. Debugging SSL level did not yield much. https://stackoverflow.com/questions/41438536/protecting-webresource-in-tomcat-8-5-with-client-cert This is the link that closely matches the requirement and I saw Chris’ input there. However, “Realm className="org.apache.catalina.realm.UserDatabaseRealm" allRolesMode="authOnly" resourceName="UserDatabase" /> “ In server.xml And My Secure Area /authenticate CONFIDENTIAL * In my web app’s web.xml. When I access the URL from browser, I expected to see a dialog asking for client-certificate and then a successful invocation of the “/authenticate”. However, from browser, I don’t get a pop-up and I get a HTTP 401 with below message. Message Cannot authenticate with the provided credentials Description The request has not been applied because it lacks valid authentication credentials for the target resource. Appreciate your help on this. Thanks, Amit
Bug 45014 - Request and Response classes should have wrappers for use in Valves
https://bz.apache.org/bugzilla/show_bug.cgi?id=45014 Any plans/thoughts on merging Chris' mod in Tomcat 9.x branch? It is really a nice to have built in support for Valves to have wrapper classes for Request and Response. We also had a requirement to read the request payload at a valve level (to make it application independent) which essentially meant wrapping the request body to make it available to subsequent components. But, no built-in support meant we had to move the implementation at a filter level. Thanks, Amit
Re: Tomcat 8.5 : Jasper errors
Any help on this as this worked in 8.0.x as expected but broke in 8.5.x (Checked with 8.5.9 and 8.5.11). This is preventing us from upgrade to Tomcat 8.5. I see Jasper binaries have updated in 8.5.x. Is this a bug in catalina-jasper component? To elaborate further, we have a customTag.jar with following layout. We just jasper task on this to generated Java files. customTag.jar ---META-INF --- gui.tld (This tld file has a reference to tag file under META-INF/tags directory) ---tags_directory abc.tag ( The actual tag file) The jasper ant task is as follows -→ (This directory has the above mentioned jar file) On 2/25/17, 7:32 AM, "Amit Pande" <amit.pa...@veritas.com> wrote: When upgraded from Tomcat 8.0.x to 8.5.x, while building our custom tags, the build is failing with below stack trace. The exception file not found does not give any clue on what’s the problem with the custom tag definition. I tried setting verbose attribute in jspc ant task as well as tried running ant with debug/verbose on. Did not see any helpful information. Appreciate any help on this. E:\test\ant\build.xml:407: org .apache.jasper.JasperException: File [/META-INF/tags/abc.tag] not found at org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorH andler.java:55) at org.apache.jasper.compiler.ErrorDispatcher.dispatch(ErrorDispatcher.j ava:293) at org.apache.jasper.compiler.ErrorDispatcher.jspError(ErrorDispatcher.j ava:80) at org.apache.jasper.compiler.TagFileProcessor.parseTagFileDirectives(Ta gFileProcessor.java:500) at org.apache.jasper.compiler.TagLibraryInfoImpl.createTagFileInfo(TagLi braryInfoImpl.java:328) at org.apache.jasper.compiler.TagLibraryInfoImpl.(TagLibraryInfoIm pl.java:204) at org.apache.jasper.compiler.Parser.parseTaglibDirective(Parser.java:43 4) at org.apache.jasper.compiler.Parser.parseDirective(Parser.java:492) at org.apache.jasper.compiler.Parser.parseElements(Parser.java:1448) at org.apache.jasper.compiler.Parser.parse(Parser.java:145) at org.apache.jasper.compiler.ParserController.doParse(ParserController. java:244) at org.apache.jasper.compiler.ParserController.parse(ParserController.ja va:105) at org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:201) at org.apache.jasper.compiler.Compiler.compile(Compiler.java:372) at org.apache.jasper.JspC.processFile(JspC.java:1263) at org.apache.jasper.JspC.execute(JspC.java:1415) at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291) at sun.reflect.GeneratedMethodAccessor7.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.jav a:106) at org.apache.tools.ant.Task.perform(Task.java:348) at org.apache.tools.ant.Target.execute(Target.java:390) at org.apache.tools.ant.Target.performTasks(Target.java:411) at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1399) at org.apache.tools.ant.helper.SingleCheckExecutor.executeTargets(Single CheckExecutor.java:38) at org.apache.tools.ant.Project.executeTargets(Project.java:1251) at org.apache.tools.ant.taskdefs.Ant.execute(Ant.java:442) at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291) at sun.reflect.GeneratedMethodAccessor7.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.jav a:106) at org.apache.tools.ant.Task.perform(Task.java:348) at org.apache.tools.ant.Target.execute(Target.java:390) at org.apache.tools.ant.Target.performTasks(Target.java:411) at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1399) at org.apache.tools.ant.Project.executeTarget(Project.java:1368) at org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExe cutor.java:41) at org.apache.tools.ant.Project.executeTargets(Project.java:1251) at org.apache.tools.ant.Main.runBuild(Main.java:809) at org.apache.tools.ant.Main.startA
Tomcat 8.5 : Jasper errors
When upgraded from Tomcat 8.0.x to 8.5.x, while building our custom tags, the build is failing with below stack trace. The exception file not found does not give any clue on what’s the problem with the custom tag definition. I tried setting verbose attribute in jspc ant task as well as tried running ant with debug/verbose on. Did not see any helpful information. Appreciate any help on this. E:\test\ant\build.xml:407: org .apache.jasper.JasperException: File [/META-INF/tags/abc.tag] not found at org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorH andler.java:55) at org.apache.jasper.compiler.ErrorDispatcher.dispatch(ErrorDispatcher.j ava:293) at org.apache.jasper.compiler.ErrorDispatcher.jspError(ErrorDispatcher.j ava:80) at org.apache.jasper.compiler.TagFileProcessor.parseTagFileDirectives(Ta gFileProcessor.java:500) at org.apache.jasper.compiler.TagLibraryInfoImpl.createTagFileInfo(TagLi braryInfoImpl.java:328) at org.apache.jasper.compiler.TagLibraryInfoImpl.(TagLibraryInfoIm pl.java:204) at org.apache.jasper.compiler.Parser.parseTaglibDirective(Parser.java:43 4) at org.apache.jasper.compiler.Parser.parseDirective(Parser.java:492) at org.apache.jasper.compiler.Parser.parseElements(Parser.java:1448) at org.apache.jasper.compiler.Parser.parse(Parser.java:145) at org.apache.jasper.compiler.ParserController.doParse(ParserController. java:244) at org.apache.jasper.compiler.ParserController.parse(ParserController.ja va:105) at org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:201) at org.apache.jasper.compiler.Compiler.compile(Compiler.java:372) at org.apache.jasper.JspC.processFile(JspC.java:1263) at org.apache.jasper.JspC.execute(JspC.java:1415) at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291) at sun.reflect.GeneratedMethodAccessor7.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.jav a:106) at org.apache.tools.ant.Task.perform(Task.java:348) at org.apache.tools.ant.Target.execute(Target.java:390) at org.apache.tools.ant.Target.performTasks(Target.java:411) at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1399) at org.apache.tools.ant.helper.SingleCheckExecutor.executeTargets(Single CheckExecutor.java:38) at org.apache.tools.ant.Project.executeTargets(Project.java:1251) at org.apache.tools.ant.taskdefs.Ant.execute(Ant.java:442) at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291) at sun.reflect.GeneratedMethodAccessor7.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.jav a:106) at org.apache.tools.ant.Task.perform(Task.java:348) at org.apache.tools.ant.Target.execute(Target.java:390) at org.apache.tools.ant.Target.performTasks(Target.java:411) at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1399) at org.apache.tools.ant.Project.executeTarget(Project.java:1368) at org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExe cutor.java:41) at org.apache.tools.ant.Project.executeTargets(Project.java:1251) at org.apache.tools.ant.Main.runBuild(Main.java:809) at org.apache.tools.ant.Main.startAnt(Main.java:217) at org.apache.tools.ant.launch.Launcher.run(Launcher.java:280) at org.apache.tools.ant.launch.Launcher.main(Launcher.java:109)
Re: JIO Connector support in Tomcat 8.5
Thanks Chris. We are indeed evaluating if we can leverage traditional reverse-proxy based solutions. However, continued our POC for the custom NIO endpoint. We extended the NioEndpoint of Tomcat 8.5.x and overrode the following methods: 1. Bind 2. Unbind 3. UnlockAccept 4. Acceptor Intend to use most of the NIO code for poller threads and other start stop logic. One issue faced was that “stopLatch” is not accessible outside the NioEndpoint class. This stopLatch is initialized during “bind” and used during “stop”. But since we override bind and don’t have access to “stopLatch”we’re facing issues while using the default NioEndpoint implementation. Could an enhancement request be filed to make this field protected similar to other fields such as pollerThreadCount, acceptorThreadCount? Reflection seems too hack-ish and don’t see any issues with making this field protected instead of private. Appreciate your thoughts. Thanks, Amit On 2/16/17, 11:48 AM, "Christopher Schultz" <ch...@christopherschultz.net> wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Amit, On 2/13/17 8:19 PM, Amit Pande wrote: > Thanks for a quick reply. > > What does our custom connector do? > > Well, we have a server program which is listening on a port which > is mandatory to be open/accessible for the outside world. Outside > world only talks to this component which in turn hands off (dup > system call) the socket to the other processes. Tomcat being one > such process. > > Our custom connector accepts the handed-off socket and then > resumes the normal processing done by Tomcat. Why not use a more traditional reverse-proxy, which already knows how to handle these kinds of protocols? > Now for NIO connector, seems we need to have a custom > implementation of the SocketChannel but not sure how it might > work. - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJYpeXnAAoJEBzwKT+lPKRY7bQQAKCiCfsy0HZLqRn3qY42IU3E Ab49WJTzbblJJAUF+ryn9jrjEOP/3m/a69r+2qotL2bv5L9qY1TBqNjyNgAzQ3b/ v/WAlDmzV51UUc6vG/1GcHgExgUMAHTLwQ0tvUIBAdcrMiX6EPE3J4/G0Q9T0eSb n6ap/WyL0AAPHrx13/xWQeVd1BByrqLiv6DA3+5VbbqewxBbGLUgL1gy/6DNSnCs lyTlTOqAnW8vN6vEpHW+7lDYgO1vgRwcfN2aZUzWFf8CSgHKhaG+zVOGWv67pbUy sZVmGpgc/v3Xny/sCrKxPTN2LeRIJRbkxffcgSThAmfCCKqswcpKK0XDAhwgVq5+ EXuz0DQ7LC5e85iIo38wZD7OSft5lf0Gp5UViLzys5WVBkaxdI7Gx/0HPPMJA4d3 681FilJm3hbd7ngXLX7is5ptnfIKgXgSrWotYjzZMTDHaWX6jvn8ygptXzOXHnJk Dz29gSUJ7Ciuxv39IS8vWNaZYmNx73nc3bCO+xRjoBzOzylznAw1wtzdH+kXvayY VINusuGur5NlyHERm4/NMQy+T0JSLYvMysEB5UWsUJR4LiAYAMPkNbgiG2sAW7MX EJwHQSPCySukb9ileiBI39HzX16cGpIn3RUpiCKzdBpRzKUtmXge5/48WeqCY5UG M7WwfZGBqtPeJUqfOybg =eMgR -END PGP SIGNATURE- - 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: JIO Connector support in Tomcat 8.5
Any suggestions on this? Could the Tomcat NIO connector be modified to receive the file descriptor from the other process ( mentioned below)? Thanks, Amit Original Message Subject: Re: JIO Connector support in Tomcat 8.5 From: Amit Pande <amit.pa...@veritas.com> Date: Feb 13, 2017, 19:20 To: Tomcat Users List <users@tomcat.apache.org> Thanks for a quick reply. What does our custom connector do? Well, we have a server program which is listening on a port which is mandatory to be open/accessible for the outside world. Outside world only talks to this component which in turn hands off (dup system call) the socket to the other processes. Tomcat being one such process. Our custom connector accepts the handed-off socket and then resumes the normal processing done by Tomcat. Now for NIO connector, seems we need to have a custom implementation of the SocketChannel but not sure how it might work. Thanks, Amit Original Message Subject: Re: JIO Connector support in Tomcat 8.5 From: Christopher Schultz <ch...@christopherschultz.net> Date: Feb 13, 2017, 18:58 To: Tomcat Users List <users@tomcat.apache.org> -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Amit, On 2/13/17 6:55 PM, Amit Pande wrote: > As I understand, the JIO/BIO connector support has been dropped in > Tomcat 8.5 +. Correct. > While I understand the need to push to the NIO based connectors, > just wondering whether the JIO connector support could have been > left as it in Tomcat 8.5 and beyond. No. > We had extended the BIO connector to have a custom implementation > and that is broken now once we move to latest Tomcat versions. You will have to figure something out. Why did you need to create your own connector? > We're evaluating refactoring our custom connector but would > appreciate if there are any suggestions to get the BIO > implementation going even in 8.5 and beyond so that our custom > connector's functionality isn't regressed. BIO is problematic because of many requirements for non-blocking behavior. It's easy to emulate blocking behavior (e.g. ServletRequest.getInputStream) based upon non-blocking building blocks (e.g. NIO connector) but next to impossible to emulate non-blocking behavior (websocket, comet, etc.) using blocking building blocks (BIO connector). Unfortunately, the reality is that a blocking I/O connector is no longer feasible for Tomcat. So... what does your custom connector do? Perhaps there's a better way to achieve your goal, or perhaps Tomcat's connectors could be re-factored to make it easier to customize something specific for you without having to re-write the whole connector. - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJYolY6AAoJEBzwKT+lPKRYpCEQALefIMml43cS3r254mGE/pFS +QWDnaPG2t96oXM8GExUWm6jGBCGarxt7FBxxku112DS8+5NzkmEmP8BdkAkOIeN 7p/1jiGhZ4Koz7ER4JUzAXbbSFmJBjOXWfxYPzecZHrBBdfndoBx2PWRe/Ew4LNY ujJLSwZWuUSlZu1CBzPT/UU0klthqRRsfHH8JrHe64Jm+qZuPIITjr0G15IYSEU3 SihVCFMmA//yQfRb8rNN9UCM8lYYtu4oYwiythPNt30wz0e5XzOemyX+f/MMlFyD yWrKlOI9x+g9OVoMNSYvsq+9EO/TTzTW6mWtW26rnHskEz0i/98QIVqg9XIRIvrM 3mPq6Ufuq6Aq75WIVtJcKUe4voDu9KSmOHb7AKsLPFrB6WbzDluSSWD3VpxM/q5R gluvGG9CcCIRl1ie1ljg3qO90ZPno38RuQl+vxKSsGlY5t/mSce1M4ffBgJdg/T7 GpKZ/+GYTUuDg/jE+9pav/yO2mx8Hj/Oo6TvGCACT4o+sRXtceORcq93c8npCT0L 4+jvS2aJT0Gud3jn2gZ9qZnXGdFWdq59LTnZ1/s6p9gGHglCtWBx9j3fMkS53y1y 41giiY9GXKuEzyHUlSaTT3rLucJCzcJWvHi/k1muqclUn5/Ht2NVHXoLmxVPxgzL K0bIRYJ9K2R/ou+6YPiV =zu1M -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: JIO Connector support in Tomcat 8.5
Thanks for a quick reply. What does our custom connector do? Well, we have a server program which is listening on a port which is mandatory to be open/accessible for the outside world. Outside world only talks to this component which in turn hands off (dup system call) the socket to the other processes. Tomcat being one such process. Our custom connector accepts the handed-off socket and then resumes the normal processing done by Tomcat. Now for NIO connector, seems we need to have a custom implementation of the SocketChannel but not sure how it might work. Thanks, Amit Original Message Subject: Re: JIO Connector support in Tomcat 8.5 From: Christopher Schultz <ch...@christopherschultz.net> Date: Feb 13, 2017, 18:58 To: Tomcat Users List <users@tomcat.apache.org> -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Amit, On 2/13/17 6:55 PM, Amit Pande wrote: > As I understand, the JIO/BIO connector support has been dropped in > Tomcat 8.5 +. Correct. > While I understand the need to push to the NIO based connectors, > just wondering whether the JIO connector support could have been > left as it in Tomcat 8.5 and beyond. No. > We had extended the BIO connector to have a custom implementation > and that is broken now once we move to latest Tomcat versions. You will have to figure something out. Why did you need to create your own connector? > We're evaluating refactoring our custom connector but would > appreciate if there are any suggestions to get the BIO > implementation going even in 8.5 and beyond so that our custom > connector's functionality isn't regressed. BIO is problematic because of many requirements for non-blocking behavior. It's easy to emulate blocking behavior (e.g. ServletRequest.getInputStream) based upon non-blocking building blocks (e.g. NIO connector) but next to impossible to emulate non-blocking behavior (websocket, comet, etc.) using blocking building blocks (BIO connector). Unfortunately, the reality is that a blocking I/O connector is no longer feasible for Tomcat. So... what does your custom connector do? Perhaps there's a better way to achieve your goal, or perhaps Tomcat's connectors could be re-factored to make it easier to customize something specific for you without having to re-write the whole connector. - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJYolY6AAoJEBzwKT+lPKRYpCEQALefIMml43cS3r254mGE/pFS +QWDnaPG2t96oXM8GExUWm6jGBCGarxt7FBxxku112DS8+5NzkmEmP8BdkAkOIeN 7p/1jiGhZ4Koz7ER4JUzAXbbSFmJBjOXWfxYPzecZHrBBdfndoBx2PWRe/Ew4LNY ujJLSwZWuUSlZu1CBzPT/UU0klthqRRsfHH8JrHe64Jm+qZuPIITjr0G15IYSEU3 SihVCFMmA//yQfRb8rNN9UCM8lYYtu4oYwiythPNt30wz0e5XzOemyX+f/MMlFyD yWrKlOI9x+g9OVoMNSYvsq+9EO/TTzTW6mWtW26rnHskEz0i/98QIVqg9XIRIvrM 3mPq6Ufuq6Aq75WIVtJcKUe4voDu9KSmOHb7AKsLPFrB6WbzDluSSWD3VpxM/q5R gluvGG9CcCIRl1ie1ljg3qO90ZPno38RuQl+vxKSsGlY5t/mSce1M4ffBgJdg/T7 GpKZ/+GYTUuDg/jE+9pav/yO2mx8Hj/Oo6TvGCACT4o+sRXtceORcq93c8npCT0L 4+jvS2aJT0Gud3jn2gZ9qZnXGdFWdq59LTnZ1/s6p9gGHglCtWBx9j3fMkS53y1y 41giiY9GXKuEzyHUlSaTT3rLucJCzcJWvHi/k1muqclUn5/Ht2NVHXoLmxVPxgzL K0bIRYJ9K2R/ou+6YPiV =zu1M -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
JIO Connector support in Tomcat 8.5
As I understand, the JIO/BIO connector support has been dropped in Tomcat 8.5 +. While I understand the need to push to the NIO based connectors, just wondering whether the JIO connector support could have been left as it in Tomcat 8.5 and beyond. We had extended the BIO connector to have a custom implementation and that is broken now once we move to latest Tomcat versions. We're evaluating refactoring our custom connector but would appreciate if there are any suggestions to get the BIO implementation going even in 8.5 and beyond so that our custom connector's functionality isn't regressed. Thanks, Amit - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Threadlocal leaks while Tomcat shutdown
This might not be the right forum to ask this question. Yet wanted to if anyone faced this issue. Our application uses Jacorb library to talk to legacy daemons over CORBA. However while stopping the Tomcat, observing following errors. They are from the jacrob.jar ..but not sure how to prevent this. Any thoughts ? SEVERE: The web application [] created a ThreadLocal with key of type [org.jacorb.orb.Delegate$1] (value [org.jacorb.orb.Delegate$1@62305af6]) and a value of type [java.lang.Boolean] (value [false]) but failed to remove it when the web application was stopped. Threads are going to be renewed over time to try and avoid a probable memory leak. Sep 17, 2016 7:04:53 PM org.apache.catalina.loader.WebappClassLoaderBase checkThreadLocalMapForLeaks SEVERE: The web application [] created a ThreadLocal with key of type [org.jacorb.orb.Delegate$1] (value [org.jacorb.orb.Delegate$1@62305af6]) and a value of type [java.lang.Boolean] (value [false]) but failed to remove it when the web application was stopped. Threads are going to be renewed over time to try and avoid a probable memory leak. Thanks, Amit
Tomcat as Windows Service
Hello experts, We have configured the Tomcat to run as a Windows Service. And Windows SCM has a default time of 30 seconds, but the Tomcat process does not start/stop within this time. So, if we restart the service via SCM, we receive the Address in Use exceptions (as previous Tomcat process hasn't been stopped yet). We're using our own custom mechanism to hook the Tomcat process with the Windows SCM and haven't gone the below mentioned way. https://tomcat.apache.org/tomcat-7.0-doc/windows-service-howto.html Any pointers on how to solve this issue ? 1. Increasing Windows SCM timeout for this process might work but doesn't sound really clean solution. 2. Issue a Catalina stop, and if it does not stop in some time , do a task kill or something similar of the corresponding java.exe ? Appreciate your help here. Thanks, Amit
Re: Custom Key Manager
Thanks a lot Chris, will do that. Appreciate your help. Thanks, Amit On 31/07/16 6:37 pm, "Christopher Schultz" <ch...@christopherschultz.net> wrote: >-BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > >Amit, > >On 7/26/16 4:59 AM, Amit Pande wrote: >> >> In Tomcat (7.x+), there is a provision to hook in a custom >> implementation for trust manager by mentioning class name in >> connector's trustManagerClassName attribute. >> >> https://bz.apache.org/bugzilla/show_bug.cgi?id=48208 >> >> https://tomcat.apache.org/tomcat-7.0-doc/config/http.html >> >> >> I need to implement a custom key manager along with custom trust >> manager. Wanted to confirm if there is any way currently to hook >> in custom key manager ? > >I don't see anything like that available. > >> If not, can this enhancement be taken and Tomcat can expose >> something like " keyManagerClassName" ? > >Sure. Can you file an enhancement request in BZ? > >https://bz.apache.org/bugzilla/enter_bug.cgi?product=Tomcat%209 > >Please file the request against Tomcat 9 and request that it be >back-ported all the way to Tomcat 7. > >- -chris >-BEGIN PGP SIGNATURE- >Comment: GPGTools - http://gpgtools.org >Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > >iEYEARECAAYFAled+BMACgkQ9CaO5/Lv0PDrrwCgnzdkaTqdP6f90Es/75EnVHQx >dYkAn03+UD/lBfD/833UF76XIwMUtblH >=8O/5 >-END PGP SIGNATURE- > >- >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: Custom Key Manager
Any pointers here, experts ? On 26/07/16 2:29 pm, "Amit Pande" <amit.pa...@veritas.com> wrote: > >In Tomcat (7.x+), there is a provision to hook in a custom implementation >for trust manager by mentioning class name in connector's >trustManagerClassName attribute. > >https://bz.apache.org/bugzilla/show_bug.cgi?id=48208 > >https://tomcat.apache.org/tomcat-7.0-doc/config/http.html > > >I need to implement a custom key manager along with custom trust >manager. Wanted to confirm if there is any way currently to hook in >custom key manager ? > >If not, can this enhancement be taken and Tomcat can expose something >like " keyManagerClassName" ? > >Appreciate your inputs. > >Thanks, >Amit > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Using JMX to get ONLY running applications
Thanks a lot, Mark for the pointers. And I apologies if the questions here raise a doubt about lack of homework. Personally I do try to use Google and/or read and understand documentation as much as I can. Sometimes however I feel (may be wrongly again), documentation is not enough. E.g. Unless asked here, I would have never known the ³shared² loader is still supported (and undocumented) in latest releases. Same is true with attributes associated with Tomcat Mbeans. Thanks, Amit On 14/07/16 2:18 am, "Mark Thomas" <ma...@apache.org> wrote: >On 13/07/2016 12:14, Amit Pande wrote: >> It seems the stateName attribute of MANAGER or WEBMODULE Mbean is NOT >> getting set correctly if there are any servlet errors. >> >> In particular, when Spring dispatcher servlet is failed to load then the >> applications state should be STOPPED. However, that does not seem to be >> the case. >> >> I even checked the SERVLET Mbean as well did not see the expected state. >> >> Is there anything wrong that I am doing ? > >Yes. > >You are making assumptions based on how you think Tomcat should behave >rather than reading the documentation that tells you how Tomcat actually >behaves. > >Look in the Context and Host docs for the attribute named: >failCtxIfServletStartFails > >> Is this a BUG ? > >No. > >> Using Tomcat 8.0.30. > >Thanks. Not everyone remembers that. > >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: Using JMX to get ONLY running applications
Can someone help here ?
It seems the stateName attribute of MANAGER or WEBMODULE Mbean is NOT
getting set correctly if there are any servlet errors.
In particular, when Spring dispatcher servlet is failed to load then the
applications state should be STOPPED. However, that does not seem to be
the case.
I even checked the SERVLET Mbean as well did not see the expected state.
Is there anything wrong that I am doing ? Is this a BUG ? Using Tomcat
8.0.30.
Thanks,
Amit
On 13/07/16 1:05 pm, "Amit Pande" <amit.pa...@veritas.com> wrote:
>I managed to use jCOnsole and find Mbean names and attributes to get the
>stateName (STARTED/STOPPED) to see if a web app is available or NOT
>(j2eeType=WebModule).
>
>However, I see the stateName of a web module as STARTED even if there are
>errors in start-up.
>
> SEVERE [localhost-startStop-3]
>org.apache.catalina.core.StandardContext.loadOnStartup Servlet
>[dispatcher] in web application [/testApp] threw load() exception
>
>I still see state for testApp as "STARTED".
>
>How can I accurately know if the application is started without any
>errors ?
>
>Appreciate your help.
>
>Thanks,
>Amit
>
>From: Amit Pande <amit.pa...@veritas.com<mailto:amit.pa...@veritas.com>>
>Date: Tuesday, 12 July 2016 9:56 pm
>To: "users@tomcat.apache.org<mailto:users@tomcat.apache.org>"
><users@tomcat.apache.org<mailto:users@tomcat.apache.org>>,
>"users-h...@tomcat.apache.org<mailto:users-h...@tomcat.apache.org>"
><users-h...@tomcat.apache.org<mailto:users-h...@tomcat.apache.org>>
>Subject: Using JMX to get ONLY running applications
>
>Hello all,
>
>I see there are JMX APIs to get the web applications currently deployed
>in Tomcat.
>
>However, I see that even if the applications are failed to deploy, they
>still get listed. Is there any way to get ONLY deployed and RUNNING
>applications ?
>
>Below is sample snippet which gives all the currently deployed apps
>..even if there are some apps which had errors and thus failed to deploy:
>
>
>public List collectAllDeployedApps() throws
>MalformedObjectNameException, AttributeNotFoundException,
>InstanceNotFoundException, MBeanException, ReflectionException {
>List webappNames = new ArrayList<>();
>List servers = MBeanServerFactory.findMBeanServer(null);
>for (MBeanServer server : servers ) {
>Set names = server.queryNames(new
>ObjectName("Catalina:type=Host,*"), null);
>Set hostNames = new HashSet();
>for (ObjectName on : names) {
>hostNames.add(on.getKeyProperty("host"));
>}
>for (String str : hostNames) {
>ObjectName[] webapps = (ObjectName[]) server
>.getAttribute(new ObjectName("Catalina:type=Host,host=" + str),
>"children");
>for (ObjectName ob : webapps) {
>String[] appSpl = ob.getKeyProperty("name").split("//localhost");
>System.out.println(ob.getKeyPropertyList());
>webappNames.add(appSpl[1]);
>}
>}
>}
>return webappNames;
>}
>}
>
>
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Using JMX to get ONLY running applications
I managed to use jCOnsole and find Mbean names and attributes to get the
stateName (STARTED/STOPPED) to see if a web app is available or NOT
(j2eeType=WebModule).
However, I see the stateName of a web module as STARTED even if there are
errors in start-up.
SEVERE [localhost-startStop-3]
org.apache.catalina.core.StandardContext.loadOnStartup Servlet [dispatcher] in
web application [/testApp] threw load() exception
I still see state for testApp as "STARTED".
How can I accurately know if the application is started without any errors ?
Appreciate your help.
Thanks,
Amit
From: Amit Pande <amit.pa...@veritas.com<mailto:amit.pa...@veritas.com>>
Date: Tuesday, 12 July 2016 9:56 pm
To: "users@tomcat.apache.org<mailto:users@tomcat.apache.org>"
<users@tomcat.apache.org<mailto:users@tomcat.apache.org>>,
"users-h...@tomcat.apache.org<mailto:users-h...@tomcat.apache.org>"
<users-h...@tomcat.apache.org<mailto:users-h...@tomcat.apache.org>>
Subject: Using JMX to get ONLY running applications
Hello all,
I see there are JMX APIs to get the web applications currently deployed in
Tomcat.
However, I see that even if the applications are failed to deploy, they still
get listed. Is there any way to get ONLY deployed and RUNNING applications ?
Below is sample snippet which gives all the currently deployed apps ..even if
there are some apps which had errors and thus failed to deploy:
public List collectAllDeployedApps() throws
MalformedObjectNameException, AttributeNotFoundException,
InstanceNotFoundException, MBeanException, ReflectionException {
List webappNames = new ArrayList<>();
List servers = MBeanServerFactory.findMBeanServer(null);
for (MBeanServer server : servers ) {
Set names = server.queryNames(new
ObjectName("Catalina:type=Host,*"), null);
Set hostNames = new HashSet();
for (ObjectName on : names) {
hostNames.add(on.getKeyProperty("host"));
}
for (String str : hostNames) {
ObjectName[] webapps = (ObjectName[]) server
.getAttribute(new ObjectName("Catalina:type=Host,host=" + str), "children");
for (ObjectName ob : webapps) {
String[] appSpl = ob.getKeyProperty("name").split("//localhost");
System.out.println(ob.getKeyPropertyList());
webappNames.add(appSpl[1]);
}
}
}
return webappNames;
}
}
Using JMX to get ONLY running applications
Hello all,
I see there are JMX APIs to get the web applications currently deployed in
Tomcat.
However, I see that even if the applications are failed to deploy, they still
get listed. Is there any way to get ONLY deployed and RUNNING applications ?
Below is sample snippet which gives all the currently deployed apps ..even if
there are some apps which had errors and thus failed to deploy:
public List collectAllDeployedApps() throws
MalformedObjectNameException, AttributeNotFoundException,
InstanceNotFoundException, MBeanException, ReflectionException {
List webappNames = new ArrayList<>();
List servers = MBeanServerFactory.findMBeanServer(null);
for (MBeanServer server : servers ) {
Set names = server.queryNames(new
ObjectName("Catalina:type=Host,*"), null);
Set hostNames = new HashSet();
for (ObjectName on : names) {
hostNames.add(on.getKeyProperty("host"));
}
for (String str : hostNames) {
ObjectName[] webapps = (ObjectName[]) server
.getAttribute(new ObjectName("Catalina:type=Host,host=" + str), "children");
for (ObjectName ob : webapps) {
String[] appSpl = ob.getKeyProperty("name").split("//localhost");
System.out.println(ob.getKeyPropertyList());
webappNames.add(appSpl[1]);
}
}
}
return webappNames;
}
}
Re: Tomcat 8.0 : Custom server.xml path
Any thoughts on this ? On 11/07/16 1:15 pm, "Amit Pande" <amit.pa...@veritas.com> wrote: >Hello all, > > >We have a custom cluster deployment scenario which requires to put config >files on a shared disk. > >With reference to above requirement, we need to put server.xml (and >possibly other files from TOMCAT_DIR\conf) on the shared disk. > >Is there any way to do this ? Possible to do in catalina.properties like: > > >Conf.dir = > > >Appreciate your help here. > >Thanks, >Amit > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Tomcat 8.0 : Custom server.xml path
Hello all, We have a custom cluster deployment scenario which requires to put config files on a shared disk. With reference to above requirement, we need to put server.xml (and possibly other files from TOMCAT_DIR\conf) on the shared disk. Is there any way to do this ? Possible to do in catalina.properties like: Conf.dir = Appreciate your help here. Thanks, Amit - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Remote Address/Host Filter per connector ..
Thanks for the reply André. Sorry I missed to mention the version but I am using Tomcat 8.0.30. Does the address component of the standard connector attribute take multiple entries ? E.g.address = ³127.0.0.1, localhost ³ ? I think my requirement is a different here. Tomcat listening on two ports , but I want to configure connecting to my web app using one of it via only the localhost and thus I wanted to set appropriate remote address filters. Thanks, Amit On 07/07/16 4:05 pm, "André Warnier (tomcat)" <a...@ice-sa.com> wrote: >On 07.07.2016 11:57, Amit Pande wrote: >> Hello all, >> >> >> In my server.xml, within in single Service element, >> >> I have two HTTP connectors defined listening on two different ports >>(12345 >> & 54321 for example). >> >> It is possible to apply the remote address/host filter so that request >>to >> one of the ports (12345) are allowed only via localhost ? And requests >>to >> other port (54321) are allowed from everywhere. >> > >You do not indicate your Tomcat version, but what about : >http://tomcat.apache.org/tomcat-8.0-doc/config/http.html#Common_Attributes >-> Standard Implementation -> address >? > >If you set one Connector to listen only on 127.0.0.1 (localhost), then >only requests >originating from the same localhost will be able to reach it, since that >address means >nothing for other hosts. >On the other hand, set the other Connector to listen to the public IP of >the host, which >should be accessible from anywhere. (Or just don't set it, and it will be >accessible also >from localhost). > >It is not the same as "allowing" accesses from various client IP's. But >it achieves the >same effect, in your case as you describe it above. > > >> >> Or do I need to configure multiple service elements for this type of >> requirement ? >> > >Note that access to the Connector, or the port, does not correlate to >access to the Hosts, >or the applications. >If /that/ is really your requirement, then you need something else. > > >- >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
Remote Address/Host Filter per connector ..
Hello all, In my server.xml, within in single Service element, I have two HTTP connectors defined listening on two different ports (12345 & 54321 for example). It is possible to apply the remote address/host filter so that request to one of the ports (12345) are allowed only via localhost ? And requests to other port (54321) are allowed from everywhere. Or do I need to configure multiple service elements for this type of requirement ? Thanks, Amit - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 8 : Shared loader
Thank you Mark for your valuable inputs. They are indeed a great help. Thanks, Amit On 15/06/16 7:00 pm, "Mark Thomas" <ma...@apache.org> wrote: >On 15/06/2016 12:03, Amit Pande wrote: >> >> >> On 15/06/16 4:06 pm, "Mark Thomas" <ma...@apache.org> wrote: >> >>> On 15/06/2016 11:00, Amit Pande wrote: >>>> We develop multiple web application which happen to share the same >>>> stack (Spring, Hibernate,etc). >>>> >>>> Thinking of sharing these third party libraries instead of duplicating >>>> in each web app war. >>> >>> Why? >> To avoid jar duplication and improve memory footprint > >Is memory footprint really that much of an issue? > >>>> IIUC, putting those in Tomcat (8)'s lib folder might cause issues >>>>since >>>> the classes in there are loaded by a common loader. >>> >>> What issues? >> Since loaded by a common class loader , the jars put in here will be >> available to tomcat internal classes,even if not required , also need be >> to thread safe. > >What is the harm in these classes being visible to Tomcat? > >I fail to see what thread-safety has to do with this. > >You do need to think about memory leaks though. > >>>> And sharing such libraries using the shared loader seems a better >>>> approach. >>> >>> Why? >> As loaded by shared loader which seems to be meant for sharing >> libraries across web apps ŠI guess here also the thread safely concern >> exists , need to validate though. > >As above, thread-safety is not a relevant concern. > >>>> Is my understanding correct ? >>> >>> No idea. You have not explained your understanding yet. >> Hope it is explained now. > >It has. And your understanding, particularly around thread safety is not >correct. > >>>> Does it have any further issues ? >>> >>> Further issues compared to what? >> It was a general awareness question to get to know if people ran into >> some issues after putting jars in tomcat¹s shared loader's path. > >It increases the risk of issues due to: >- memory leaks since few libraries are written with a multi-class loader >environment in mind >- upgrades are harder since you have to take Tomcat down to upgrade any >shared library >- dependency management is harder since all webapps have to use the same >set of dependencies > >>>> That said, I don't see much documentation around using shared loader. >>>> Any documentation/help in this regard is highly appreciated. >>> >>> There isn't much call for the shared loader. You need to go back to the >>> 5.5.x documentation for a diagram that includes the shared loader. >>> >>> http://tomcat.apache.org/tomcat-5.5-doc/class-loader-howto.html >> >> Thanks for this. In absence of clear documentation in recent release, I >> was doubtful if it was deprecated. > >Not deprecated. Just rarely useful so disabled by default. > >Generally, it causes more problems than it solves so unless you are >really under memory pressure it isn't worth the trouble. > >Mark > > >- >To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >For additional commands, e-mail: users-h...@tomcat.apache.org >
Re: Tomcat 8 : Shared loader
Thanks a lot, Lulseged for your inputs.
With this approach, did you see any apparent issues / precautions that we
should be aware of ?
Thanks,
Amit
On 15/06/16 3:54 pm, "Lulseged Zerfu" <zlulse...@hotmail.com> wrote:
>It should be shared.loader:
>shared.loader="${catalina.base}/shared"
>
>> From: zlulse...@hotmail.com
>> To: users@tomcat.apache.org
>> Subject: RE: Tomcat 8 : Shared loader
>> Date: Wed, 15 Jun 2016 10:21:39 +
>>
>> Hi
>> I have also same problem and have solved it by using shared folder.
>> Look at the catalina.properties file under $CATALINA_HOME/conf
>> You can look in to the common.loader an server.loader how to define
>>loaders.
>> You should add loaders in the same way in the shared.loader.
>> I have created $CATALINA_HOME/shared and added my libraries here.
>> server.loader="${catalina.base}/shared"
>> Hope it helps.
>> Lulseged Zerfu
>>
>> > From: amit.pa...@veritas.com
>> > To: users@tomcat.apache.org
>> > Subject: Tomcat 8 : Shared loader
>> > Date: Wed, 15 Jun 2016 10:00:51 +
>> >
>> > We develop multiple web application which happen to share the same
>>stack (Spring, Hibernate,etc).
>> >
>> > Thinking of sharing these third party libraries instead of
>>duplicating in each web app war.
>> >
>> > IIUC, putting those in Tomcat (8)'s lib folder might cause issues
>>since the classes in there are loaded by a common loader.
>> >
>> > And sharing such libraries using the shared loader seems a better
>>approach. Is my understanding correct ? Does it have any further issues
>>?
>> >
>> > That said, I don't see much documentation around using shared loader.
>>Any documentation/help in this regard is highly appreciated.
>> >
>> > Thanks,
>> > Amit
>> >
>>
>
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 8 : Shared loader
On 15/06/16 4:06 pm, "Mark Thomas" <ma...@apache.org> wrote: >On 15/06/2016 11:00, Amit Pande wrote: >> We develop multiple web application which happen to share the same >>stack (Spring, Hibernate,etc). >> >> Thinking of sharing these third party libraries instead of duplicating >>in each web app war. > >Why? >> To avoid jar duplication and improve memory footprint > >> IIUC, putting those in Tomcat (8)'s lib folder might cause issues since >>the classes in there are loaded by a common loader. > >What issues? >> Since loaded by a common class loader , the jars put in here will be >>available to tomcat internal classes,even if not required , also need be >>to thread safe. > >> And sharing such libraries using the shared loader seems a better >>approach. > >Why? >> As loaded by shared loader which seems to be meant for sharing >>libraries across web apps ŠI guess here also the thread safely concern >>exists , need to validate though. > >> Is my understanding correct ? > >No idea. You have not explained your understanding yet. >> Hope it is explained now. > >> Does it have any further issues ? > >Further issues compared to what? >> It was a general awareness question to get to know if people ran into >>some issues after putting jars in tomcat¹s shared loader's path. > >> That said, I don't see much documentation around using shared loader. >>Any documentation/help in this regard is highly appreciated. > >There isn't much call for the shared loader. You need to go back to the >5.5.x documentation for a diagram that includes the shared loader. > >http://tomcat.apache.org/tomcat-5.5-doc/class-loader-howto.html >> Thanks for this. In absence of clear documentation in recent release, I >>was doubtful if it was deprecated. > >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
Tomcat 8 : Shared loader
We develop multiple web application which happen to share the same stack (Spring, Hibernate,etc). Thinking of sharing these third party libraries instead of duplicating in each web app war. IIUC, putting those in Tomcat (8)'s lib folder might cause issues since the classes in there are loaded by a common loader. And sharing such libraries using the shared loader seems a better approach. Is my understanding correct ? Does it have any further issues ? That said, I don't see much documentation around using shared loader. Any documentation/help in this regard is highly appreciated. Thanks, Amit
Re: Tomcat simple tcp cluster doesn't work on switching browser
Hi, I tried to see if the connection between two tomcats is working correctly & took a netstat with the receiver port(4010) of tomcat 2 & process id(13437) of tomcat 1 which gives the following. netstat -anp | grep 4010 | grep 192.168.x.x:4010 | grep 13437/java tcp0580 :::192.168.x.x:41140 :::192.168.x.x:4010 ESTABLISHED 13437/java tcp0578 :::192.168.x.x:41136 :::192.168.x.x:4010 ESTABLISHED 13437/java netstat -anp | grep 4010 | grep 192.168.x.x:4010 | grep 13437/java tcp0580 :::192.168.x.x:41146 :::192.168.x.x:4010 ESTABLISHED 13437/java tcp0826 :::192.168.x.x:41151 :::192.168.x.x:4010 ESTABLISHED 13437/java netstat -anp | grep 4010 | grep 192.168.x.x:4010 | grep 13437/java tcp0757 :::192.168.x.x:41223 :::192.168.x.x:4010 ESTABLISHED 13437/java netstat -anp | grep 4010 | grep 192.168.x.x:4010 | grep 13437/java tcp0580 :::192.168.x.x:41292 :::192.168.x.x:4010 ESTABLISHED 13437/java tcp0757 :::192.168.x.x:41286 :::192.168.x.x:4010 ESTABLISHED 13437/java tcp0578 :::192.168.x.x:41282 :::192.168.x.x:4010 ESTABLISHED 13437/java tcp0 1 :::192.168.x.x:41293 :::192.168.x.x:4010 SYN_SENT13437/java netstat -anp | grep 4010 | grep 192.168.x.x:4010 | grep 13437/java I have two observations : a) The no of connections keeps changing form 0 to 4 . b) When this issue occurs , the Receive queue starts filling up Is observation 'a' normal behaviour? And are there ways to identify why the receive queue filling up ? On 17/11/15 3:06 pm, "Amit Rawat" <amit.ra...@guavus.com> wrote: >Hi Chris, > >It might seem that both are going to SERVER-1 because I have set the >jvmRoute for both instances of tomcat is set to SERVER-1. I had started >with setting different jvmRoute for both and I faced the same issue . Then >I tried setting them the same since I thought jvmRoute should be unique to >the server therefore I used server name . Although now I think they should >be unique to the tomcat instance. > >I am not using a load balancer. The two tomcats expose different services >& I need to share sessions between those services for a logged in user. >The scenario is that I login through tomcat 1, query it a few times, then >query tomcat 2 using the same session-id . > >My apologies if it seemed rude , but I pasted the link to my questions on >SO as I didn¹t want the mail to be too long & unreadable . Also, the post >on SO , has links to other SO suggestions that I have already tried. >Again, my apologies, it was not my intention to be either lazy or rude. > > >Thanks for the reply, >Amit > >On 17/11/15 3:28 am, "Christopher Schultz" <ch...@christopherschultz.net> >wrote: > >>Amit, >> >>On 11/16/15 7:21 AM, Amit Rawat wrote: >>> Thanks for the reply. I understand that on changing browsers, a new >>> session would need to be established & that is indeed what I do . On >>> changing browsers , I login again , creating a new session . >>> As can be seen in the logs I pasted on stack overflow : New Session ::: >>> 6003A09956987A2035EB9BB1C5D7C157.SERVER-1 . But as you can see from the >>> logs , the sessions created or destroyed are not shared with the other >>> tomcat by the tomcat to which I send my requests . >> >>It's not clear which Tomcat is receiving which requests... they all look >>like they are going to SERVER-1. Are you sure your lb is working as >>expected? >> >>While some of us lurk on SO, posting to this list and asking people to >>go to SO to answer your question is a little lazy (or perhaps rude). IF >>you want real advice, come here and give us all the information we need >>to help you. Then stick around and become part of the community. If you >>just want random advice from people on the internet, stick with SO. >> >>-chris >> >>> On 16/11/15 5:30 pm, "André Warnier (tomcat)" <a...@ice-sa.com> wrote: >>> >>>> On 16.11.2015 11:36, Amit Rawat wrote: >>>>> Hi, >>>>> >>>>> >>>>> >>>>> I'm observing some strange behaviour between two instances of >>>>> apache-tomcat-7.0.41 running on the same server. Sessions are shared >>>>> between the servers on multiple logins/logouts on the same browser , >>>>>but >>>>> when i switch browsers , the session sharing stops . >>>>> >>>>> I have posted a question on stack overflow where you can find more >>>>> details on what I have tried & my observations : >>>>&g
