You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Rainer Jung <ra...@kippdata.de> on 2022/03/01 16:08:14 UTC

Results testing with OpenSSL 3.0

Triggered by Chris's cipher disable question I ran some tests with 
OpenSSL 3.0. Currently only for TC 8.5, more follows.

1) Errors for unit tests which call 
TesterSupport.configureClientCertContext() with Java 7

The following tests fail when running with Java 7:

org.apache.catalina.valves.rewrite.TestResolverSSL
org.apache.tomcat.util.net.TestClientCert
org.apache.tomcat.util.net.TestCustomSslTrustManager

I think the following happens:

- they call TesterSupport.configureClientCertContext()

- there we call for non-Java 8:
 
tomcat.getConnector().findSslHostConfigs()[0].setProtocols(Constants.SSL_PROTO_TLSv1);

- OpenSSL 3.0 supports in theory TLSv1, but by default
   it does not support SHA (SHA1). The Java 7 client is configured
   by TesterSupport to use TLSv1.2, but only has ciphers using SHA1.
   Thus the handshake fails.

I can reproduce with the openssl binary "s_server". As soon as I add 
"@SECLEVEL=0" to the end of the server-side cipher list (which reenables 
SHA), the handshakes work again. So I think this is "fails as expected" 
and is not worth fixing in the unit tests. Combining Java 7 and OpenSSL 
3.0 is probably an exotic test situation.

2) Sporadic errors with Java 11 in TestSSLHostConfigCompat

Especially tests testHostRSAandECwithRSAClient and 
testHostRSAwithRSAandECClient.

They fail when the client choses a DH-Key which is shorter in length 
than most of the time. I think it is the same type of failure I have 
seen last autumn when I did httpd release testing with OpenSSL 3.0 in 
the sever and 0.9.8 in the client. 3.0 has a padding check that fails, 
when the length is short.

3.0 head code has a fix for it, but an additionally needed patch for 
adding back the check for TLS 1.3 (where it is required) was backported 
to a wrong branch. I informed the OpenSSL project and I am confident 
that this failure will be gone in 3.0.2.

I did not observe this failure with Java 8 or 17, but since it is 
sporadic, it could still happen there.

I will run the test with TC 9, 10 and 10.1 and will see, whether the 
results are the same or vary.

Best regards,

Rainer

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