from:"Marcos Peña"

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

2024-04-11 Thread 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
>
>

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

2024-04-11 Thread 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: [OT] Tomcat 9.0.83 - SSL handshake stops working for Google API calls after a while

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

2 matches

Site Navigation

Mail list logo

Footer information