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