Hi,
We’re observing a random issue with some of our customers, after doing an upgrade of the Jetty from 9.4.11 to 9.4.44. We’re starting Jetty programmatically in a Zulu JRE 8 runtime.
We’re initializing the SSLContextFactory as follows
SslContextFactory contextFactory = new SslContextFactory.Server();
contextFactory.setKeyStorePath(config.getKeyStorePath());
contextFactory.setKeyStorePassword(config.getDecryptedPassword());
contextFactory.setTrustStorePath(config.getKeyStorePath());
contextFactory.setTrustStorePassword(config.getDecryptedPassword());
contextFactory.setExcludeCipherSuites(excCipherSuites);
contextFactory.addExcludeProtocols(excludedProtocols.toArray(new String[0]));
What we’re observing is that the SSL handshake is failing when the server is accessed over FQDN. However the handshake goes through when accessed over IP Address.
Enabled, Java SSL Logging and herewith attaching the trace of the same.
What we see in the logs is
javax.net.ssl|SEVERE|08 1C|qtp1363141203-2076|2023-02-07 12:35:40.763 EST|TransportContext.java:340|Fatal (HANDSHAKE_FAILURE): no cipher suites in common (
"throwable" : {
javax.net.ssl.SSLHandshakeException: no cipher suites in common
at sun.security.ssl.Alert.createSSLException(Alert.java:131)
at sun.security.ssl.Alert.createSSLException(Alert.java:117)
at sun.security.ssl.TransportContext.fatal(TransportContext.java:335)
at sun.security.ssl.TransportContext.fatal(TransportContext.java:291)
at sun.security.ssl.TransportContext.fatal(TransportContext.java:282)
at sun.security.ssl.ServerHello$T12ServerHelloProducer.chooseCipherSuite(ServerHello.java:461)
at sun.security.ssl.ServerHello$T12ServerHelloProducer.produce(ServerHello.java:296)
at sun.security.ssl.SSLHandshake.produce(SSLHandshake.java:421)
at sun.security.ssl.ClientHello$T12ClientHelloConsumer.consume(ClientHello.java:1020)
at sun.security.ssl.ClientHello$ClientHelloConsumer.onClientHello(ClientHello.java:727)
at sun.security.ssl.ClientHello$ClientHelloConsumer.consume(ClientHello.java:693)
at sun.security.ssl.SSLHandshake.consume(SSLHandshake.java:377)
at sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:444)
at sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(SSLEngineImpl.java:981)
at sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(SSLEngineImpl.java:968)
at java.security.AccessController.doPrivileged(Native Method)
at sun.security.ssl.SSLEngineImpl$DelegatedTask.run(SSLEngineImpl.java:915)
at org.eclipse.jetty.io.ssl.SslConnection$DecryptedEndPoint.fill(SslConnection.java:654)
at org.eclipse.jetty.server.HttpConnection.fillRequestBuffer(HttpConnection.java:350)
at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:260)
at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:311)
at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:105)
at org.eclipse.jetty.io.ssl.SslConnection$DecryptedEndPoint.onFillable(SslConnection.java:555)
at org.eclipse.jetty.io.ssl.SslConnection.onFillable(SslConnection.java:410)
at org.eclipse.jetty.io.ssl.SslConnection$2.succeeded(SslConnection.java:164)
at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:105)
at org.eclipse.jetty.io.ChannelEndPoint$1.run(ChannelEndPoint.java:104)
at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:338)
at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:315)
at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:173)
at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:131)
at org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:409)
at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:883)
at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:1034)
at java.lang.Thread.run(Thread.java:750)}
The problem seems similar to the issue seen in the case of
https://github.com/eclipse/jetty.project/issues/7691 - However this was seen on Java 11.
Also seems similar to the issue seen in
https://github.com/eclipse/jetty.project/issues/6099, but in this it is marked as Fixed in 9.4.41 and we’re on 9.4.44. We tried to follow the workaround of setting sni required as true. But
in our internal testing, after setting that, handshake was failing both over IP and FQDN.
We’re working to see if we can dump on server start and collect more logs, but meanwhile if we can get any help here, it would be much appreciated.
What we’re clear is that the Server Hello is not able to prove possession and therefore the handshake is failing. How it is related to Jetty version is what we’re trying to figure out.
Thanks,
Srijith.