Thanks Chris.

The TLS 1.3 problem happens for all TC versions. It looks to me as a test limitation. We check, whether TLS 1.3 support is present in the JVM via "SSLContext.getInstance(Constants.SSL_PROTO_TLSv1_3)". If so, we do the TLS1.3 test, configure TC to use TLS 1.3 but use a default HttpURLConnection in TomcatBaseTest.java without any specific TLS setup. But in 1.8.0_272 although TLS 1.3 is available, it is disabled by default for clients. So the test fails.

We could probably in TestClientCertTls13 replace the default SSLSocketFactory in HttpsURLConnection by one that wraps the original default one but also sets TLS 1.3 as enabled on any socket it creates. That way we would "fix" behavior in TomcatBaseTest without the need of adding more parameters to the calls there.

Concerning the problem observed on RHEL 8 only with Red Hat provided OpenJDK: after upgrading to their latest Java 11 patch level, the problems for Java 11 are gone. After upgrading to their latest Java 1.8.0_272, I can still see the problems there. No problem for the same test when using Adopt or Zulu 1.8.0_272 and also not for original OpenJDK 1.8.0_272. I can see a difference in supported ciphers and I expect the reason to be there:

< RedHat 1.8.0_272
> RedHat 11 and all non Red Hat Java 1.8.0_272

< SSL_RSA_WITH_NULL_SHA
< TLS_ECDHE_ECDSA_WITH_NULL_SHA
< TLS_ECDHE_RSA_WITH_NULL_SHA
< TLS_RSA_WITH_NULL_SHA256

> TLS_DHE_DSS_WITH_AES_128_CBC_SHA
> TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
> TLS_DHE_DSS_WITH_AES_128_GCM_SHA256
> TLS_DHE_DSS_WITH_AES_256_CBC_SHA
> TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
> TLS_DHE_DSS_WITH_AES_256_GCM_SHA384
> TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA
> TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256
> TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256
> TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA
> TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384
> TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384
> TLS_ECDH_RSA_WITH_AES_128_CBC_SHA
> TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256
> TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256
> TLS_ECDH_RSA_WITH_AES_256_CBC_SHA
> TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384
> TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384

This seems to be a limitation specific to the RedHat JDK 1.8.0_272.

Regards,

Rainer

Am 28.10.2020 um 20:34 schrieb Christopher Schultz:
Rainer,

I recently had some weirdness with TLS connections as well. Please see my post titled "SSLException after Java upgrade".

"Recently", Java moved certain EC curves to the attic and won't handshake properly anymore.

Another investigation of my own product running into a network exception that hadn't been generated before. It looks like a change to the JRE.

https://bugs.openjdk.java.net/browse/JDK-8215102

This was initially reported as an error with MySQL connections but it appears that the driver's involvement was unnecessary. Please see Severin Gehwolf's comments from 2019-01-25.

I'm not sure if either of these issues are related to yours, but I wanted to make suer you were aware of them.

Hope that helps,
-chris

On 10/28/20 08:09, Rainer Jung wrote:
Hi all,

I tested TC 7.0.106 plus a few patches from git with a variety of JVMs on a few Linux distributions. I observed:

- org.apache.tomcat.util.net.TestClientCertTls13 now fails for Java 1.8.0_272 be it OpenJDK, Adopt or Zulu on all Linux distros I tested. TLSv1.3 was backported to Java 8 in the recently released Patchlevel 272 and is enabled on the server side by default, but not on the client side. The test succeeds as soon as I add "-Djdk.tls.client.protocols=TLSv1.3". I guess correct TLS1.3 detection during test gets moire and more complicated ...

- Only on RHEL 8 (e.g. not RHEL 6 or 7) and only with Red Hat provided Java 1.8.0 and 11 (but not for other distributions of Java 1.8.0 or 11), lots of TLS tests fail. For example TestSsl test testSimpleSsl show the following when started with -Djavax.net.debug=all und Red Hat Java 11:

     [junit] Oct 28, 2020 12:55:26 PM org.apache.coyote.AbstractProtocol start      [junit] INFO: Starting ProtocolHandler ["http-bio-127.0.0.1-auto-1-43799"]      [junit] javax.net.ssl|DEBUG|03|Finalizer|2020-10-28 12:55:26.265 CET|SSLSocketImpl.java:473|duplex close of SSLSocket      [junit] javax.net.ssl|WARNING|03|Finalizer|2020-10-28 12:55:26.273 CET|SSLSocketImpl.java:494|SSLSocket duplex close failed (
     [junit] "throwable" : {
     [junit]   java.net.SocketException: Socket is not connected
     [junit]     at java.base/java.net.Socket.shutdownOutput(Socket.java:1553)      [junit]     at java.base/sun.security.ssl.BaseSSLSocketImpl.shutdownOutput(BaseSSLSocketImpl.java:232)      [junit]     at java.base/sun.security.ssl.SSLSocketImpl.duplexCloseOutput(SSLSocketImpl.java:561)      [junit]     at java.base/sun.security.ssl.SSLSocketImpl.close(SSLSocketImpl.java:479)      [junit]     at java.base/sun.security.ssl.BaseSSLSocketImpl.finalize(BaseSSLSocketImpl.java:275)      [junit]     at java.base/java.lang.System$2.invokeFinalize(System.java:2117)      [junit]     at java.base/java.lang.ref.Finalizer.runFinalizer(Finalizer.java:87)      [junit]     at java.base/java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:171)}
     [junit]
     [junit] )
     [junit] javax.net.ssl|ERROR|01|main|2020-10-28 12:55:26.304 CET|TransportContext.java:313|Fatal (HANDSHAKE_FAILURE): Couldn't kickstart handshaking (
     [junit] "throwable" : {
     [junit]   javax.net.ssl.SSLHandshakeException: No appropriate protocol (protocol is disabled or cipher suites are inappropriate)      [junit]     at java.base/sun.security.ssl.HandshakeContext.<init>(HandshakeContext.java:163)      [junit]     at java.base/sun.security.ssl.ClientHandshakeContext.<init>(ClientHandshakeContext.java:95)      [junit]     at java.base/sun.security.ssl.TransportContext.kickstart(TransportContext.java:217)      [junit]     at java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:395)      [junit]     at java.base/sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:567)      [junit]     at java.base/sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:185)      [junit]     at java.base/sun.net.www.protocol.https.HttpsURLConnectionImpl.connect(HttpsURLConnectionImpl.java:163)      [junit]     at org.apache.catalina.startup.TomcatBaseTest.methodUrl(TomcatBaseTest.java:665)      [junit]     at org.apache.catalina.startup.TomcatBaseTest.methodUrl(TomcatBaseTest.java:639)      [junit]     at org.apache.catalina.startup.TomcatBaseTest.getUrl(TomcatBaseTest.java:633)      [junit]     at org.apache.catalina.startup.TomcatBaseTest.getUrl(TomcatBaseTest.java:627)      [junit]     at org.apache.catalina.startup.TomcatBaseTest.getUrl(TomcatBaseTest.java:612)      [junit]     at org.apache.catalina.startup.TomcatBaseTest.getUrl(TomcatBaseTest.java:606)      [junit]     at org.apache.tomcat.util.net.TestSsl.testSimpleSsl(TestSsl.java:60)

Dont know whether the error in the finalizer really is the root cause and it might well be a JDK error, but I at least wanted to provide the info here.

Best regards,

Rainer

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

Reply via email to