null pointer in java NIO SSO processor

Question

trying to run gitblit, on tomcat 9, using JDK 11 occassionaly results in this stack trace:

gitblit    | 07-May-2020 04:30:39.247 SEVERE [https-jsse-nio-8443-exec-10] org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun Error running socket processor
gitblit    |    java.lang.NullPointerException
gitblit    |            at java.base/sun.security.ssl.HKDF.extract(HKDF.java:93)
gitblit    |            at java.base/sun.security.ssl.HKDF.extract(HKDF.java:119)
gitblit    |            at java.base/sun.security.ssl.ServerHello.setUpPskKD(ServerHello.java:1167)
gitblit    |            at java.base/sun.security.ssl.ServerHello$T13ServerHelloProducer.produce(ServerHello.java:545)
gitblit    |            at java.base/sun.security.ssl.SSLHandshake.produce(SSLHandshake.java:436)
gitblit    |            at java.base/sun.security.ssl.ClientHello$T13ClientHelloConsumer.goServerHello(ClientHello.java:1234)
gitblit    |            at java.base/sun.security.ssl.ClientHello$T13ClientHelloConsumer.consume(ClientHello.java:1170)
gitblit    |            at java.base/sun.security.ssl.ClientHello$ClientHelloConsumer.onClientHello(ClientHello.java:852)
gitblit    |            at java.base/sun.security.ssl.ClientHello$ClientHelloConsumer.consume(ClientHello.java:813)
gitblit    |            at java.base/sun.security.ssl.SSLHandshake.consume(SSLHandshake.java:392)
gitblit    |            at java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:444)
gitblit    |            at java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(SSLEngineImpl.java:1061)
gitblit    |            at java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(SSLEngineImpl.java:1048)
gitblit    |            at java.base/java.security.AccessController.doPrivileged(Native Method)
gitblit    |            at java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask.run(SSLEngineImpl.java:995)
gitblit    |            at org.apache.tomcat.util.net.SecureNioChannel.tasks(SecureNioChannel.java:443)
gitblit    |            at org.apache.tomcat.util.net.SecureNioChannel.handshakeUnwrap(SecureNioChannel.java:507)
gitblit    |            at org.apache.tomcat.util.net.SecureNioChannel.handshake(SecureNioChannel.java:238)
gitblit    |            at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1616)
gitblit    |            at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
gitblit    |            at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
gitblit    |            at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
gitblit    |            at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
gitblit    |            at java.base/java.lang.Thread.run(Thread.java:834)

When the clients are trying to pull files from the gitblit GUI.

Possibly of interest, until I updated to the 11.0.7 version of the JDF, I was seeing this error: Open JDK 11 HTTP/2 Handshake ServerHello java.util.NoSuchElementException

Where the fixed the mis-use of the Optional here: https://bugs.openjdk.java.net/browse/JDK-8218889 but perhaps, didn't actually address the root problem?

Or any other thoughts as to what is triggering this error? I'm using a self-signed cert here, FYI. The client is Firefox, and the java release is

openjdk version "11.0.7" 2020-04-14 OpenJDK Runtime Environment AdoptOpenJDK (build 11.0.7+10) OpenJDK 64-Bit Server VM AdoptOpenJDK (build 11.0.7+10, mixed mode)

Running inside an alpine linux docker system.

Chasing down an issue where gitblit has occassional 1 minute timeouts, and finding this in the log. Not sure if related, or not....

Looks like it has also been found in tomcat https://bz.apache.org/bugzilla/show_bug.cgi?id=64105, and reported here

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

Since I can't provide info on the openjdk bug tracker, I can tell you that the client that typically causes it for me is Firefox 75 on linux.

Answer 1

As pointed out by the bugtracker references that you provide, this is a bug related to session resumption.

While this answer does not address the bug itself, there is a possibility to ask the SSLEngine to disallow resumption for a particular connection. This comes at a performance penalty for future connections because the client is required to redo the handshake for new connections instead of leveraging the session resumption mechanism.

At any time after the handshake is established, you can call invalidate() on the SSLSession. As pointed in the doc:

Future connections will not be able to resume or join this session. However, any existing connection using this session can continue to use the session until the connection is closed.

Meaning that it has no effect on the current connection, but will prevent session resumption and thus avoid the JDK bug.

My snippet for the handshake loop:

case NOT_HANDSHAKING:
case FINISHED:
{
    if( !sslEngine.getSession().isValid() || sslEngine.getSession().getId().length == 0 )
        throw new SSLHandshakeException("Handshake failed");

    // prevent bug with rejoin session
    sslEngine.getSession().invalidate();

    return;
}