Re: Tomcat log warnings for connection parameter limits?

[Baron Fujimoto]

I was thinking it would be something that would be left on in a live
system. We can set these parameters, so it would be useful to know if we
were hitting the set limits.

I'm not sure I fully grasp how this additional logging presents a
significant incremental DOS risk. I mean, if an attacker is flooding you
with enough traffic or connections where this becomes an issue, aren't you
already logging various aspects of the attempts anyway (e.g., access logs,
etc)? At that point aren't your logs already being filled anyway?

On Thu, Apr 11, 2024 at 1:44 AM Christopher Schultz <
ch...@christopherschultz.net> wrote:

> Baron,
>
> On 4/9/24 16:33, Baron Fujimoto wrote:
> > I'm investigating occasional 503 errors for our CAS service running in a
> > Tomcat 10.1.x container. The 503s appear to correlate with some traffic
> > spikes at the same time.
> >
> > The connector is configured as follows:
> >
> >   > port="8443"
> > maxThreads="2500"
> > maxConnections="5"
> > maxPostSize="10"
> > maxParameterCount="1000"
> > scheme="https" secure="true"
> > SSLEnabled="true"
> > >
> >
> > Can Tomcat log info such as when the maxThreads or maxConnections limits
> > are reached? I'm basically trying to see if there is a good way to
> > more definitively determine what may have caused the 503s and what may be
> > feasible to mitigate them.
>
> Are you thinking of a debugging feature or something to be left-on for a
> live production system?
>
> Such logging might be considered a DOS vector for a live system: you can
> fill the logs by asking lots of trivial requests.
>
> -chris
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

-- 
Baron Fujimoto  ::: UH Information Technology Services
minutas cantorum, minutas balorum, minutas carboratum descendus pantorum

Re: Retrieve server.built, server.number

[Mark Thomas]

On 11/04/2024 15:49, Bill Stewart wrote:

On Wed, Apr 10, 2024 at 2:14 PM Mark Thomas wrote:


... and it might represent an information leakage vulnerability in your

application. Be Careful.


Shall we start the flame war now on whether exposing the current version
   you are running represents a valid vulnerability or if hiding it is
just security by obscurity? Or do you want to save it for Bratislava?

:)

More seriously, your time is likely to be better spent (in my view)
keeping your Tomcat installations up to date with the latest releases
than it is ensuring that you hide the version number.



The amusing thing (or irritating thing, depending on your point of view) is
when a large organization uses a vulnerability scanner and a Tomcat
instance gets flagged as a security risk because it reveals its version
number in the 404 error page. (Yes, this is a real scenario.)


At least it is an easy fix: showServerInfo="false"

assuming that is going to be easier than convincing folks that exposing 
the version number isn't an issue.


Mark

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

Package URLs for Apache Tomcat distributions

[von Loewenstein, Jan]

Hi folks,

I am part of the Paketo community, and we are providing Cloud Native Buildpacks 
to create container images with – amongst other technologies – Apache Tomcat 
and Apache TomEE as application runtimes.

One of the features of Cloud Native Buildpacks is that images come with 
Software-Bill-of-Material. When installing Apache Tomcat, we issue the 
following CPE and pURL to the SBOM:

  1.  cpe:2.3:a:apache:tomcat:10.1.20:*:*:*:*:*:*:*
  2.  pkg:generic/apache-tomcat@10.1.20

The former should be the right one for users to find relevant CVEs in e.g. the 
nvd.nist.gov. The latter however is made up and will likely not lead to any 
findings on e.g. https://osv.dev

Now I am wondering if you report Tomcat vulnerabilities under any pURL and 
which one that would be.
There is a 
proposal
 to introduce `pkg:apache` as a namespace, which would open up 
`pkg:apache/tomcat@10.1.20` as a canonical pURL.

Thanks for the time to read this.

Best regards
Jan von Löwenstein

Re: [OT] Tomcat 9.0.83 - SSL handshake stops working for Google API calls after a while

[Christopher Schultz]

Marcos,

On 4/11/24 09:52, Marcos Peña wrote:

Thanks for your replies.

My bad assuming the connector configuration applied to all connections but
it makes total sense that applies to incoming connections. That helps a lot.

I have been trying to solve this problem for several days and I was a bit
desperate. I could not find anything in the application code that would
change it at runtime...up to a few minutes ago. I think there is a
SSLSocketFactory that is changing the ciphers at runtime.


That's exactly the kind of thing I would expect to discover given your 
description of the symptoms.


-chris


On Thu, Apr 11, 2024 at 2:25 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:


Marcos,

Marking as "off topic" because this is not Tomcat-related. Please see
below...

On 4/11/24 08:28, Marcos Peña wrote:

Hi,

I am looking for help with a strange issue we are experiencing when
trying to use Google APIs from a web application that is deployed on
Tomcat 9.0.83.

After a few hours of the server being up and running, all calls to the
Google APIs fail because of SSL handshake errors. Attaching the SSL logs
for your reference.

I see some differences in the ClientHello message. When the handshake
fails, all TLSv1.3 ciphers are ignored, there is no "session id" and
TLSv1.2 is sent as the only supported version.

The Tomcat connector configuration is as follows:

ciphers="TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_DHE_RSA_WITH_AES_128_GCM_SHA256,TLS_DHE_RSA_WITH_AES_256_GCM_SHA384,TLS_AES_128_GCM_SHA256,TLS_AES_256_GCM_SHA384,TLS_CHACHA20_POLY1305_SHA256,TLS_AES_128_CCM_SHA256,TLS_AES_128_CCM_8_SHA256"/>

This configuration is only relevant for INCOMING connections. It has no
bearing on your outgoing HTTP / TLS connections.


I updated Tomcat to use the most recent native library - 2.0.7 - but
that did not help. Below an extract from the server log.


Your use (or not) of tcnative is only relevant for incoming connections.
Without significant work, your outgoing connections will not be using
tcnative for any TLS communications.


2024-04-11 02:12:47,507 INFO
   [org.apache.catalina.core.AprLifecycleListener:134] (main) Loaded
Apache Tomcat Native library [2.0.7] using APR version [1.7.4].
2024-04-11 02:12:47,507 INFO
   [org.apache.catalina.core.AprLifecycleListener:134] (main) APR
capabilities: IPv6 [true], sendfile [true], accept filters [false],
random [true], UDS [true].
2024-04-11 02:12:47,507 INFO
   [org.apache.catalina.core.AprLifecycleListener:134] (main) APR/OpenSSL
configuration: useAprConnector [false], useOpenSSL [true]
2024-04-11 02:12:47,514 INFO
   [org.apache.catalina.core.AprLifecycleListener:370] (main) OpenSSL
successfully initialized [OpenSSL 3.0.13 30 Jan 2024]

I am not very familiar with the SSL handshake process and do not really
understand what can make it stop working.


My guess is that your /outbound/ HTTP connection manager is having its
configuration changed at runtime. You will have to look at how your
application establishes these outbound connections to determine why the
rules are changing.

-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: [EXT]Re: Tomcat 10 session replication fails

[Rick Noel]

Thanks Chuck,

We are getting closer
Changing ports from the 5000 range to the 4000 range stopped two errors 
But now I get this..

INFO: Manager [##0001]: skipping state transfer. No members active in cluster 
group

How to I make the member machine in the cluster active?


Rick Noel
Systems Programmer | Westwood One
rn...@westwoodone.com

-Original Message-
From: Chuck Caldarale  
Sent: Thursday, April 11, 2024 9:14 AM
To: Tomcat Users List 
Subject: [EXT]Re: Tomcat 10 session replication fails

[You don't often get email from n82...@gmail.com. Learn why this is important 
at https://aka.ms/LearnAboutSenderIdentification ]

> On Apr 11, 2024, at 07:56, Rick Noel  wrote:
>
> We have our app running on Tomcat10 and doing clustering,but are getting the 
> following errors seen int the Catalina log...
>
> Apr 11, 2024 8:14:43 AM org.apache.catalina.ha.session.DeltaManager 
> waitForSendAllSessions
> SEVERE: Manager [##0001]: No session state sent at [4/11/24, 8:13 AM] 
> received, timing out after [60,068] ms.
> Apr 11, 2024 8:14:43 AM org.apache.catalina.ha.session.DeltaManager 
> getAllClusterSessions
> WARNING: Manager [##0001]: Drop message [SESSION-GET-ALL] inside 
> GET_ALL_SESSIONS sync phase start date [4/11/24, 8:13 AM] message date 
> [4/11/24, 8:13 AM]
> 11-Apr-2024 08:14:43.456
>
> The error, to me, indicates that the session data is not being sent out.
>
> We are running this app in our dev environment, and in this dev environment 
> the app runs on only one machine.
> In our live environment the app runs on two machines and traffic goes through 
> a load balancer.
> This may be a dumb question but are we getting these errors because we are 
> running the app on only one machine, and clustering cannot be done on one 
> machine?


Likely. From the Tomcat clustering doc:

If your Tomcat instances are running on the same machine, make sure the 
Receiver.port attribute is unique for each instance, in most cases Tomcat is 
smart enough to resolve this on it's own by autodetecting available ports in 
the range 4000-4100

You appear to have configured 5001 as the receiver port on both.


>   
>  className="org.apache.catalina.tribes.membership.McastService"
>   
> address="228.0.0.4"
>   
> port="45565"
>   
> frequency="500"
>   
> dropTime="3000"/>
>   
>  className="org.apache.catalina.tribes.transport.nio.NioReceiver"
>   
>   address="auto"
>   
>   port="5001"
>   
>   selectorTimeout="100"
>   
>   maxThreads="6"/>


  - Chuck

CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you know the sender and you are sure the 
content is safe. Please report the message using the Report Message feature in 
your email client if you believe the email is suspicious.


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

Re: [OT] Tomcat 9.0.83 - SSL handshake stops working for Google API calls after a while

[Marcos Peña]

Thanks for your replies.

My bad assuming the connector configuration applied to all connections but
it makes total sense that applies to incoming connections. That helps a lot.

I have been trying to solve this problem for several days and I was a bit
desperate. I could not find anything in the application code that would
change it at runtime...up to a few minutes ago. I think there is a
SSLSocketFactory that is changing the ciphers at runtime.

Regards,
Marcos

On Thu, Apr 11, 2024 at 2:25 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:

> Marcos,
>
> Marking as "off topic" because this is not Tomcat-related. Please see
> below...
>
> On 4/11/24 08:28, Marcos Peña wrote:
> > Hi,
> >
> > I am looking for help with a strange issue we are experiencing when
> > trying to use Google APIs from a web application that is deployed on
> > Tomcat 9.0.83.
> >
> > After a few hours of the server being up and running, all calls to the
> > Google APIs fail because of SSL handshake errors. Attaching the SSL logs
> > for your reference.
> >
> > I see some differences in the ClientHello message. When the handshake
> > fails, all TLSv1.3 ciphers are ignored, there is no "session id" and
> > TLSv1.2 is sent as the only supported version.
> >
> > The Tomcat connector configuration is as follows:
> >  > protocol="com.precisionsoftware.tomcat.Http11Nio2Protocol"
> > proxyPort="443" SSLEnabled="true"
> >  connectionTimeout="6"
> >  maxThreads="300"
> >  minSpareThreads="50"
> >  acceptCount="250"
> >  maxKeepAliveRequests="1"
> > maxPostSize="-1"
> >  relaxedQueryChars='[]|{}^'
> >  enableLookups="true"
> > disableUploadTimeout="true"
> >  URIEncoding="UTF-8"
> >  compression="force"
> > scheme="https"
> > secure="true"
> >  clientAuth="false"
> > sslProtocol="TLS"
> > sslEnabledProtocols="TLSv1.2+TLSv1.3"
> >  keyAlias="1"
> >  keystoreFile="../wildcard_odqad.pfx"
> >  keystorePass="thepassword"
> >
> >
> ciphers="TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_DHE_RSA_WITH_AES_128_GCM_SHA256,TLS_DHE_RSA_WITH_AES_256_GCM_SHA384,TLS_AES_128_GCM_SHA256,TLS_AES_256_GCM_SHA384,TLS_CHACHA20_POLY1305_SHA256,TLS_AES_128_CCM_SHA256,TLS_AES_128_CCM_8_SHA256"/>
>
> This configuration is only relevant for INCOMING connections. It has no
> bearing on your outgoing HTTP / TLS connections.
>
> > I updated Tomcat to use the most recent native library - 2.0.7 - but
> > that did not help. Below an extract from the server log.
>
> Your use (or not) of tcnative is only relevant for incoming connections.
> Without significant work, your outgoing connections will not be using
> tcnative for any TLS communications.
>
> > 2024-04-11 02:12:47,507 INFO
> >   [org.apache.catalina.core.AprLifecycleListener:134] (main) Loaded
> > Apache Tomcat Native library [2.0.7] using APR version [1.7.4].
> > 2024-04-11 02:12:47,507 INFO
> >   [org.apache.catalina.core.AprLifecycleListener:134] (main) APR
> > capabilities: IPv6 [true], sendfile [true], accept filters [false],
> > random [true], UDS [true].
> > 2024-04-11 02:12:47,507 INFO
> >   [org.apache.catalina.core.AprLifecycleListener:134] (main) APR/OpenSSL
> > configuration: useAprConnector [false], useOpenSSL [true]
> > 2024-04-11 02:12:47,514 INFO
> >   [org.apache.catalina.core.AprLifecycleListener:370] (main) OpenSSL
> > successfully initialized [OpenSSL 3.0.13 30 Jan 2024]
> >
> > I am not very familiar with the SSL handshake process and do not really
> > understand what can make it stop working.
>
> My guess is that your /outbound/ HTTP connection manager is having its
> configuration changed at runtime. You will have to look at how your
> application establishes these outbound connections to determine why the
> rules are changing.
>
> -chris
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: [OT] Tomcat 9.0.83 - SSL handshake stops working for Google API calls after a while

[Chuck Caldarale]

> On Apr 11, 2024, at 07:28, Marcos Peña  wrote:
> 
> I am looking for help with a strange issue we are experiencing when trying to 
> use Google APIs from a web application that is deployed on Tomcat 9.0.83.


As Chris noted, this has nothing to do with Tomcat. The stack trace shows that 
the failure is coming from your application code:

com.precisionsoftware.trax.service.translation.Transliterator


> After a few hours of the server being up and running, all calls to the Google 
> APIs fail because of SSL handshake errors.


My quite limited experience with Google APIs (using rclone) shows that the 
client access token has to be renewed fairly frequently (rclone does this 
automatically). I don’t know if the token is used as part of the TLS handshake, 
nor if your code is refreshing the token when needed.


> The Tomcat connector configuration is as follows:
>  protocol="com.precisionsoftware.tomcat.Http11Nio2Protocol" proxyPort="443" 
> SSLEnabled="true"


Unrelated to your problem, but that protocol class setting seems very odd; have 
you copied the Tomcat class into your own package?

  - Chuck


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

Re: Retrieve server.built, server.number

[Bill Stewart]

On Wed, Apr 10, 2024 at 2:14 PM Mark Thomas wrote:

> ... and it might represent an information leakage vulnerability in your
> > application. Be Careful.
>
> Shall we start the flame war now on whether exposing the current version
>   you are running represents a valid vulnerability or if hiding it is
> just security by obscurity? Or do you want to save it for Bratislava?
>
> :)
>
> More seriously, your time is likely to be better spent (in my view)
> keeping your Tomcat installations up to date with the latest releases
> than it is ensuring that you hide the version number.
>

The amusing thing (or irritating thing, depending on your point of view) is
when a large organization uses a vulnerability scanner and a Tomcat
instance gets flagged as a security risk because it reveals its version
number in the 404 error page. (Yes, this is a real scenario.)

Re: [OT] Tomcat 9.0.83 - SSL handshake stops working for Google API calls after a while

[Christopher Schultz]

Marcos,

Marking as "off topic" because this is not Tomcat-related. Please see 
below...


On 4/11/24 08:28, Marcos Peña wrote:

Hi,

I am looking for help with a strange issue we are experiencing when 
trying to use Google APIs from a web application that is deployed on 
Tomcat 9.0.83.


After a few hours of the server being up and running, all calls to the 
Google APIs fail because of SSL handshake errors. Attaching the SSL logs 
for your reference.


I see some differences in the ClientHello message. When the handshake 
fails, all TLSv1.3 ciphers are ignored, there is no "session id" and 
TLSv1.2 is sent as the only supported version.


The Tomcat connector configuration is as follows:
protocol="com.precisionsoftware.tomcat.Http11Nio2Protocol" 
proxyPort="443" SSLEnabled="true"

         connectionTimeout="6"
         maxThreads="300"
         minSpareThreads="50"
         acceptCount="250"
         maxKeepAliveRequests="1"
maxPostSize="-1"
         relaxedQueryChars='[]|{}^'
         enableLookups="true"
disableUploadTimeout="true"
         URIEncoding="UTF-8"
         compression="force"
scheme="https"
secure="true"
         clientAuth="false"
sslProtocol="TLS"
sslEnabledProtocols="TLSv1.2+TLSv1.3"
         keyAlias="1"
         keystoreFile="../wildcard_odqad.pfx"
         keystorePass="thepassword"
 
ciphers="TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_DHE_RSA_WITH_AES_128_GCM_SHA256,TLS_DHE_RSA_WITH_AES_256_GCM_SHA384,TLS_AES_128_GCM_SHA256,TLS_AES_256_GCM_SHA384,TLS_CHACHA20_POLY1305_SHA256,TLS_AES_128_CCM_SHA256,TLS_AES_128_CCM_8_SHA256"/>


This configuration is only relevant for INCOMING connections. It has no 
bearing on your outgoing HTTP / TLS connections.


I updated Tomcat to use the most recent native library - 2.0.7 - but 
that did not help. Below an extract from the server log.


Your use (or not) of tcnative is only relevant for incoming connections. 
Without significant work, your outgoing connections will not be using 
tcnative for any TLS communications.


2024-04-11 02:12:47,507 INFO 
  [org.apache.catalina.core.AprLifecycleListener:134] (main) Loaded 
Apache Tomcat Native library [2.0.7] using APR version [1.7.4].
2024-04-11 02:12:47,507 INFO 
  [org.apache.catalina.core.AprLifecycleListener:134] (main) APR 
capabilities: IPv6 [true], sendfile [true], accept filters [false], 
random [true], UDS [true].
2024-04-11 02:12:47,507 INFO 
  [org.apache.catalina.core.AprLifecycleListener:134] (main) APR/OpenSSL 
configuration: useAprConnector [false], useOpenSSL [true]
2024-04-11 02:12:47,514 INFO 
  [org.apache.catalina.core.AprLifecycleListener:370] (main) OpenSSL 
successfully initialized [OpenSSL 3.0.13 30 Jan 2024]


I am not very familiar with the SSL handshake process and do not really 
understand what can make it stop working.


My guess is that your /outbound/ HTTP connection manager is having its 
configuration changed at runtime. You will have to look at how your 
application establishes these outbound connections to determine why the 
rules are changing.


-chris

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

Re: Tomcat 9.0.83 - SSL handshake stops working for Google API calls after a while

[Simon Matter]

Hi,

> Hi,
>
> I am looking for help with a strange issue we are experiencing when trying
> to use Google APIs from a web application that is deployed on Tomcat
> 9.0.83.
>
> After a few hours of the server being up and running, all calls to the
> Google APIs fail because of SSL handshake errors. Attaching the SSL logs
> for your reference.

Without knowing exactly how it would look like, are you 100% sure you're
not running out of entropy for some reason?

At least it doesn't hurt to have available entropy in monitoring some how.

Regards,
Simon

>
> I see some differences in the ClientHello message. When the handshake
> fails, all TLSv1.3 ciphers are ignored, there is no "session id" and
> TLSv1.2 is sent as the only supported version.
>
> The Tomcat connector configuration is as follows:
>  protocol="com.precisionsoftware.tomcat.Http11Nio2Protocol" proxyPort="443"
> SSLEnabled="true"
> connectionTimeout="6"
> maxThreads="300"
> minSpareThreads="50"
> acceptCount="250"
> maxKeepAliveRequests="1"
> maxPostSize="-1"
> relaxedQueryChars='[]|{}^"<>'
> enableLookups="true"
> disableUploadTimeout="true"
> URIEncoding="UTF-8"
> compression="force"
> scheme="https"
> secure="true"
> clientAuth="false"
> sslProtocol="TLS"
> sslEnabledProtocols="TLSv1.2+TLSv1.3"
> keyAlias="1"
> keystoreFile="../wildcard_odqad.pfx"
> keystorePass="thepassword"
>
> ciphers="TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_DHE_RSA_WITH_AES_128_GCM_SHA256,TLS_DHE_RSA_WITH_AES_256_GCM_SHA384,TLS_AES_128_GCM_SHA256,TLS_AES_256_GCM_SHA384,TLS_CHACHA20_POLY1305_SHA256,TLS_AES_128_CCM_SHA256,TLS_AES_128_CCM_8_SHA256"/>
>
> I updated Tomcat to use the most recent native library - 2.0.7 - but that
> did not help. Below an extract from the server log.
>
> 2024-04-11 02:12:47,507 INFO
>  [org.apache.catalina.core.AprLifecycleListener:134] (main) Loaded Apache
> Tomcat Native library [2.0.7] using APR version [1.7.4].
> 2024-04-11 02:12:47,507 INFO
>  [org.apache.catalina.core.AprLifecycleListener:134] (main) APR
> capabilities: IPv6 [true], sendfile [true], accept filters [false], random
> [true], UDS [true].
> 2024-04-11 02:12:47,507 INFO
>  [org.apache.catalina.core.AprLifecycleListener:134] (main) APR/OpenSSL
> configuration: useAprConnector [false], useOpenSSL [true]
> 2024-04-11 02:12:47,514 INFO
>  [org.apache.catalina.core.AprLifecycleListener:370] (main) OpenSSL
> successfully initialized [OpenSSL 3.0.13 30 Jan 2024]
>
> I am not very familiar with the SSL handshake process and do not really
> understand what can make it stop working.
>
> Thanks,
> Marcos
>
> -
> 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: Tomcat 10 session replication fails

[Chuck Caldarale]

> On Apr 11, 2024, at 07:56, Rick Noel  wrote:
> 
> We have our app running on Tomcat10 and doing clustering,but are getting the 
> following errors seen int the Catalina log...
> 
> Apr 11, 2024 8:14:43 AM org.apache.catalina.ha.session.DeltaManager 
> waitForSendAllSessions
> SEVERE: Manager [##0001]: No session state sent at [4/11/24, 8:13 AM] 
> received, timing out after [60,068] ms.
> Apr 11, 2024 8:14:43 AM org.apache.catalina.ha.session.DeltaManager 
> getAllClusterSessions
> WARNING: Manager [##0001]: Drop message [SESSION-GET-ALL] inside 
> GET_ALL_SESSIONS sync phase start date [4/11/24, 8:13 AM] message date 
> [4/11/24, 8:13 AM]
> 11-Apr-2024 08:14:43.456
> 
> The error, to me, indicates that the session data is not being sent out.
> 
> We are running this app in our dev environment, and in this dev environment 
> the app runs on only one machine.
> In our live environment the app runs on two machines and traffic goes through 
> a load balancer.
> This may be a dumb question but are we getting these errors because we are 
> running the app on only one machine, and clustering cannot be done on one 
> machine?


Likely. From the Tomcat clustering doc:

If your Tomcat instances are running on the same machine, make sure the 
Receiver.port attribute is unique for each instance, in most cases Tomcat is 
smart enough to resolve this on it's own by autodetecting available ports in 
the range 4000-4100

You appear to have configured 5001 as the receiver port on both.


>   
>  className="org.apache.catalina.tribes.membership.McastService"
>   
> address="228.0.0.4"
>   
> port="45565"
>   
> frequency="500"
>   
> dropTime="3000"/>
>   
>  className="org.apache.catalina.tribes.transport.nio.NioReceiver"
>   
>   address="auto"
>   
>   port="5001"
>   
>   selectorTimeout="100"
>   
>   maxThreads="6”/>


  - Chuck

Tomcat 10 session replication fails

[Rick Noel]

Hi,

We have our app running on Tomcat10 and doing clustering,but are getting the 
following errors seen int the Catalina log...

Apr 11, 2024 8:14:43 AM org.apache.catalina.ha.session.DeltaManager 
waitForSendAllSessions
SEVERE: Manager [##0001]: No session state sent at [4/11/24, 8:13 AM] received, 
timing out after [60,068] ms.
Apr 11, 2024 8:14:43 AM org.apache.catalina.ha.session.DeltaManager 
getAllClusterSessions
WARNING: Manager [##0001]: Drop message [SESSION-GET-ALL] inside 
GET_ALL_SESSIONS sync phase start date [4/11/24, 8:13 AM] message date 
[4/11/24, 8:13 AM]
11-Apr-2024 08:14:43.456

The error, to me, indicates that the session data is not being sent out.

We are running this app in our dev environment, and in this dev environment the 
app runs on only one machine.
In our live environment the app runs on two machines and traffic goes through a 
load balancer.
This may be a dumb question but are we getting these errors because we are 
running the app on only one machine, and clustering cannot be done on one 
machine?
We need to better understand these errors before we can move to tomcat 10 
clustering into our live   2 machine environment

This is how we have clustering defined in the server.xml...





  

  

  



  


 


 

   

   


   

 

   

   

   

   

 


 



 





 



  





Rick Noel
Systems Programmer | Westwood One
rn...@westwoodone.com

Tomcat 9.0.83 - SSL handshake stops working for Google API calls after a while

[Marcos Peña]

Hi,

I am looking for help with a strange issue we are experiencing when trying
to use Google APIs from a web application that is deployed on Tomcat 9.0.83.

After a few hours of the server being up and running, all calls to the
Google APIs fail because of SSL handshake errors. Attaching the SSL logs
for your reference.

I see some differences in the ClientHello message. When the handshake
fails, all TLSv1.3 ciphers are ignored, there is no "session id" and
TLSv1.2 is sent as the only supported version.

The Tomcat connector configuration is as follows:


I updated Tomcat to use the most recent native library - 2.0.7 - but that
did not help. Below an extract from the server log.

2024-04-11 02:12:47,507 INFO
 [org.apache.catalina.core.AprLifecycleListener:134] (main) Loaded Apache
Tomcat Native library [2.0.7] using APR version [1.7.4].
2024-04-11 02:12:47,507 INFO
 [org.apache.catalina.core.AprLifecycleListener:134] (main) APR
capabilities: IPv6 [true], sendfile [true], accept filters [false], random
[true], UDS [true].
2024-04-11 02:12:47,507 INFO
 [org.apache.catalina.core.AprLifecycleListener:134] (main) APR/OpenSSL
configuration: useAprConnector [false], useOpenSSL [true]
2024-04-11 02:12:47,514 INFO
 [org.apache.catalina.core.AprLifecycleListener:370] (main) OpenSSL
successfully initialized [OpenSSL 3.0.13 30 Jan 2024]

I am not very familiar with the SSL handshake process and do not really
understand what can make it stop working.

Thanks,
Marcos
javax.net.ssl|DEBUG|B4|https-openssl-nio2-8443-exec-7|2024-04-10 04:21:17.402 
PDT|Utilities.java:74|the previous server name in SNI (type=host_name (0), 
value=oauth2.googleapis.com) was replaced with (type=host_name (0), 
value=oauth2.googleapis.com)
javax.net.ssl|DEBUG|B4|https-openssl-nio2-8443-exec-7|2024-04-10 04:21:17.403 
PDT|HandshakeContext.java:298|Ignore unsupported cipher suite: 
TLS_AES_256_GCM_SHA384 for TLSv1.2
javax.net.ssl|DEBUG|B4|https-openssl-nio2-8443-exec-7|2024-04-10 04:21:17.403 
PDT|HandshakeContext.java:298|Ignore unsupported cipher suite: 
TLS_AES_128_GCM_SHA256 for TLSv1.2
javax.net.ssl|DEBUG|B4|https-openssl-nio2-8443-exec-7|2024-04-10 04:21:17.403 
PDT|HandshakeContext.java:298|Ignore unsupported cipher suite: 
TLS_CHACHA20_POLY1305_SHA256 for TLSv1.2
javax.net.ssl|INFO|B4|https-openssl-nio2-8443-exec-7|2024-04-10 04:21:17.404 
PDT|AlpnExtension.java:182|No available application protocols
javax.net.ssl|DEBUG|B4|https-openssl-nio2-8443-exec-7|2024-04-10 04:21:17.404 
PDT|SSLExtensions.java:272|Ignore, context unavailable extension: 
application_layer_protocol_negotiation
javax.net.ssl|DEBUG|B4|https-openssl-nio2-8443-exec-7|2024-04-10 04:21:17.404 
PDT|SessionTicketExtension.java:408|Stateless resumption supported
javax.net.ssl|ALL|B4|https-openssl-nio2-8443-exec-7|2024-04-10 04:21:17.404 
PDT|SignatureScheme.java:393|Ignore unsupported signature scheme: ecdsa_sha224
javax.net.ssl|ALL|B4|https-openssl-nio2-8443-exec-7|2024-04-10 04:21:17.404 
PDT|SignatureScheme.java:393|Ignore unsupported signature scheme: rsa_sha224
javax.net.ssl|ALL|B4|https-openssl-nio2-8443-exec-7|2024-04-10 04:21:17.404 
PDT|SignatureScheme.java:393|Ignore unsupported signature scheme: dsa_sha224
javax.net.ssl|ALL|B4|https-openssl-nio2-8443-exec-7|2024-04-10 04:21:17.404 
PDT|SignatureScheme.java:412|Ignore disabled signature scheme: rsa_md5
javax.net.ssl|DEBUG|B4|https-openssl-nio2-8443-exec-7|2024-04-10 04:21:17.404 
PDT|SSLExtensions.java:272|Ignore, context unavailable extension: cookie
javax.net.ssl|DEBUG|B4|https-openssl-nio2-8443-exec-7|2024-04-10 04:21:17.407 
PDT|SSLExtensions.java:272|Ignore, context unavailable extension: 
renegotiation_info
javax.net.ssl|DEBUG|B4|https-openssl-nio2-8443-exec-7|2024-04-10 04:21:17.407 
PDT|PreSharedKeyExtension.java:661|No session to resume.
javax.net.ssl|DEBUG|B4|https-openssl-nio2-8443-exec-7|2024-04-10 04:21:17.407 
PDT|SSLExtensions.java:272|Ignore, context unavailable extension: pre_shared_key
javax.net.ssl|DEBUG|B4|https-openssl-nio2-8443-exec-7|2024-04-10 04:21:17.408 
PDT|ClientHello.java:641|Produced ClientHello handshake message (
"ClientHello": {
  "client version"  : "TLSv1.2",
  "random"  : 
"7F2C5D82C8561768B47E7B5CA5C17AD3F7AAC6964904C9AEA4F0CD04344A8917",
  "session id"  : 
"3845452D90A3B35D03AD6F87A554F2749C5CFADE9E2D094B0BB25403D054D2AA",
  "cipher suites"   : "[TLS_AES_256_GCM_SHA384(0x1302), 
TLS_AES_128_GCM_SHA256(0x1301), TLS_CHACHA20_POLY1305_SHA256(0x1303), 
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384(0xC02C), 
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256(0xC02B), 
TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256(0xCCA9), 
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384(0xC030), 
TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256(0xCCA8), 
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256(0xC02F), 
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384(0x009F), 
TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256(0xCCAA), 
TLS_DHE_DSS_WITH_AES_256_GCM_SHA384(0x00A3), 
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256(0x009E), 

Re: Retrieve server.built, server.number

[Christopher Schultz]

Mark,

On 4/10/24 16:12, Mark Thomas wrote:



On 10/04/2024 21:15, Christopher Schultz wrote:

All,

On 4/10/24 4:00 AM, Mark Thomas wrote:

On 09/04/2024 17:17, prat 007 wrote:

Hi All,

I would like to know is there a way to find tomcat's server.built and
server.number remotely using tool loke curl or from browser?


In a default installation, no.

You'd have to write a servlet that reported that information and then 
request that page.


... and it might represent an information leakage vulnerability in 
your application. Be Careful.


Shall we start the flame war now on whether exposing the current version 
  you are running represents a valid vulnerability or if hiding it is 
just security by obscurity? Or do you want to save it for Bratislava?


:)


Hey, I've been running Apache-Coyote/1.1 since 1998 and I'm still standing.

More seriously, your time is likely to be better spent (in my view) 
keeping your Tomcat installations up to date with the latest releases 
than it is ensuring that you hide the version number.


+1

Upgrading Tomcat should be something that any application management 
team is comfortable doing. Upgrading with every monthly Tomcat release 
should not be a burden if you choose to do it.


-chris

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

Re: Tomcat log warnings for connection parameter limits?

[Christopher Schultz]

Baron,

On 4/9/24 16:33, Baron Fujimoto wrote:

I'm investigating occasional 503 errors for our CAS service running in a
Tomcat 10.1.x container. The 503s appear to correlate with some traffic
spikes at the same time.

The connector is configured as follows:

 

Can Tomcat log info such as when the maxThreads or maxConnections limits
are reached? I'm basically trying to see if there is a good way to
more definitively determine what may have caused the 503s and what may be
feasible to mitigate them.


Are you thinking of a debugging feature or something to be left-on for a 
live production system?


Such logging might be considered a DOS vector for a live system: you can 
fill the logs by asking lots of trivial requests.


-chris

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