0

Using Java version

openjdk 11.0.7 2020-04-14
OpenJDK Runtime Environment (build 11.0.7+10-post-Ubuntu-2ubuntu218.04)
OpenJDK 64-Bit Server VM (build 11.0.7+10-post-Ubuntu-2ubuntu218.04, mixed mode, sharing)

The error I see in catalina.out is

SEVERE [https-jsse-nio2-8443-exec-24] org.apache.tomcat.util.net.Nio2Endpoint$SocketProcessor.doRun Error running socket processor
        java.lang.NullPointerException
                at java.base/sun.security.ssl.HKDF.extract(HKDF.java:93)
                at java.base/sun.security.ssl.HKDF.extract(HKDF.java:119)
                at java.base/sun.security.ssl.ServerHello.setUpPskKD(ServerHello.java:1167)
                at java.base/sun.security.ssl.ServerHello$T13ServerHelloProducer.produce(ServerHello.java:545)
                at java.base/sun.security.ssl.SSLHandshake.produce(SSLHandshake.java:436)
                at java.base/sun.security.ssl.ClientHello$T13ClientHelloConsumer.goServerHello(ClientHello.java:1234)
                at java.base/sun.security.ssl.ClientHello$T13ClientHelloConsumer.consume(ClientHello.java:1170)
                at java.base/sun.security.ssl.ClientHello$ClientHelloConsumer.onClientHello(ClientHello.java:852)
                at java.base/sun.security.ssl.ClientHello$ClientHelloConsumer.consume(ClientHello.java:813)
                at java.base/sun.security.ssl.SSLHandshake.consume(SSLHandshake.java:392)
                at java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:444)
                at java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(SSLEngineImpl.java:1061)
                at java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(SSLEngineImpl.java:1048)
                at java.base/java.security.AccessController.doPrivileged(Native Method)
                at java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask.run(SSLEngineImpl.java:995)
                at org.apache.tomcat.util.net.SecureNio2Channel.tasks(SecureNio2Channel.java:511)
                at org.apache.tomcat.util.net.SecureNio2Channel.handshakeUnwrap(SecureNio2Channel.java:557)
                at org.apache.tomcat.util.net.SecureNio2Channel.handshakeInternal(SecureNio2Channel.java:319)
                at org.apache.tomcat.util.net.SecureNio2Channel.handshake(SecureNio2Channel.java:217)
                at org.apache.tomcat.util.net.Nio2Endpoint$SocketProcessor.doRun(Nio2Endpoint.java:1664)
                at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
                at org.apache.tomcat.util.net.AbstractEndpoint.processSocket(AbstractEndpoint.java:1104)
                at org.apache.tomcat.util.net.SecureNio2Channel$HandshakeReadCompletionHandler.completed(SecureNio2Channel.java:99)
                at org.apache.tomcat.util.net.SecureNio2Channel$HandshakeReadCompletionHandler.completed(SecureNio2Channel.java:92)
                at java.base/sun.nio.ch.Invoker.invokeUnchecked(Invoker.java:127)
                at java.base/sun.nio.ch.Invoker$2.run(Invoker.java:219)
                at java.base/sun.nio.ch.AsynchronousChannelGroupImpl$1.run(AsynchronousChannelGroupImpl.java:112)
                at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
                at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
                at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
                at java.base/java.lang.Thread.run(Thread.java:834)

I read it is related to a JDK bug. What I didn't understand is whether it's something I can workaround or should I just wait for a fix?

Looking here: https://wiki.openjdk.java.net/display/JDKUpdates/JDK11u it seems that I have the latest release (ga version).

Please advice, thanks

Update In server.xml I see this commented connector (meaning I'm not using it), with explanations that it's using openssl

<Connector port="8443" protocol="org.apache.coyote.http11.Http11AprProtocol" maxThreads="150" SSLEnabled="true" >
   <UpgradeProtocol className="org.apache.coyote.http2.Http2Protocol" />
   <SSLHostConfig>
      <Certificate certificateKeyFile="conf/localhost-rsa-key.pem"
                   certificateFile="conf/localhost-rsa-cert.pem"
                   certificateChainFile="conf/localhost-rsa-chain.pem"
                   type="RSA" />
   </SSLHostConfig>                                                                                                                                                                                                                         </Connector>              

But I admit that I'm afraid to use it instead of the current one. The current one is working in general except for the 2 occasions of the above exception. I don't know what happened suddenly as this was working for months now.

Also I read here: http://tomcat.apache.org/tomcat-9.0-doc/config/http.html#SSL_Support the following:

As of Tomcat 8.5, the majority of the SSL configuration attributes in the Connector are deprecated. If specified, they will be used to configure a SSLHostConfig and Certificate for the defaultSSLHostConfigName. Note that if an explicit SSLHostConfig element also exists for the defaultSSLHostConfigName then that will be treated as a configuration error. It is expected that Tomcat 10 will drop support for the SSL configuration attributes in the Connector.

And I'm using tomcat 9+ so... I'm a bit confused. Is it a bug that will be fixed eventually so I won't need to change my settings or is it something that I should handle myself?

Amos
  • 415
  • 1
  • 4
  • 10
  • I saw this question which actually links here: https://bugs.openjdk.java.net/browse/JDK-8241248. The workaround: Disable TLSv1.3 and running with TLSv1.2 only. Or use OpenSSL for the encryption. From what I know TLS1.3 is a must today. Also, I don't remember setting the ssl lib I'm using so how/where can I check it? – Amos Jul 16 '20 at 20:17
  • Amos: (1) TLS 1.3 is now _preferred_, but it's been generally available barely a year and I don't know anyone or anything that _requires_ it. Most standards now require minimum 1.1 (because BEAST, even mitigated by 1/n) and many require minimum 1.2 (because Lucky13, although very difficult). Based on history, 1.3 may be required in about 3 years. (2) both your stacktrace and your threadname confirm you are using JSSE and Nio2; for OpenSSL aka TCnative aka APR (if installed on your system) see e.g. http://tomcat.apache.org/tomcat-9.0-doc/config/http.html#SSL_Support – dave_thompson_085 Jul 16 '20 at 21:05
  • Thanks @dave_thompson_085 please read the updated post above. I'm a noob in SSL technicalities. – Amos Jul 16 '20 at 21:32
  • It is clearly a bug in Java; I don't speak for Java devs, but in the past they have always fixed such bugs. However, I have no idea when this will be done. In the meantime, if you don't change anything, all 'resumed' connections from 1.3-capable clients will fail. I have no idea if this is acceptable to your users. If not, either limiting to 1.2 with JSSE, _or_ switching to OpenSSL, will work-around the problem until it is fully fixed. ... – dave_thompson_085 Jul 17 '20 at 19:31
  • ... The sentence you've focussed on is irrelevant; it it true Tomcat 8.5 and 9 prefer most of the config attributes in new SSLHostConfg and Certificate objects instead of the Connector, but this doesn't change functionality. The sample/default config follows this preference, including the snippet you posted, but it will work if you don't. The snippet you posted also uses OpenSSL-style config with PEM files; as the docs say a few paras above, in 8.5 and 9 you can use _either_ OpenSSL-type (PEM) or JSSE-type (keystore) config for either stack, although the example only shows one. – dave_thompson_085 Jul 17 '20 at 19:38
  • I do use the keystore type in the connector that is active. Can you please post an answer with an explanation or a link to such explanation on how to limit to 1.2 so I can accept it? Thank you very much for your help! – Amos Jul 17 '20 at 20:32

0 Answers0