11:33 a.m.
Hi,
we recently noticed the hard way that when the SSL Handshake in
io.undertow.protocols.ssl.SslConduit encounters an Exception, that Exception is silently
discarded (SslConduit lines 1083ff in Undertow 2.0.21-SNAPSHOT).
try {
doHandshake();
} catch (IOException | RuntimeException | Error e) {
IoUtils.safeClose(connection);
}
This makes it extremely tedious and difficult to analyse any issues in this phase as the
Exception that does eventually happen and bubble to the caller looks like this:
8< snip >8
java.nio.channels.ClosedChannelException
at io.undertow.protocols.ssl.SslConduit.write(SslConduit.java:369)
at org.xnio.conduits.ConduitStreamSinkChannel.write(ConduitStreamSinkChannel.java:150)
at
org.xnio.http.HttpUpgrade$HttpUpgradeState$StringWriteListener.handleEvent(HttpUpgrade.java:385)
at
org.xnio.http.HttpUpgrade$HttpUpgradeState$StringWriteListener.handleEvent(HttpUpgrade.java:372)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
at
org.xnio.conduits.WriteReadyHandler$ChannelListenerHandler.writeReady(WriteReadyHandler.java:65)
at
io.undertow.protocols.ssl.SslConduit$SslWriteReadyHandler.writeReady(SslConduit.java:1276)
at io.undertow.protocols.ssl.SslConduit$3.run(SslConduit.java:275)
at org.xnio.nio.WorkerThread.safeRun(WorkerThread.java:592)
at org.xnio.nio.WorkerThread.run(WorkerThread.java:472)
8< /snip >8
There’s no indication in the stack that this is _really_ due to an earlier
SSLHandshakeException which looks like this:
8< snip >8
Caused by: javax.net.ssl.SSLHandshakeException: General SSLEngine problem
at sun.security.ssl.Handshaker.checkThrown(Handshaker.java:1521)
at sun.security.ssl.SSLEngineImpl.checkTaskThrown(SSLEngineImpl.java:528)
at sun.security.ssl.SSLEngineImpl.readNetRecord(SSLEngineImpl.java:802)
at sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:766)
at javax.net.ssl.SSLEngine.unwrap(SSLEngine.java:624)
at io.undertow.protocols.ssl.SslConduit.doUnwrap(SslConduit.java:757)
at io.undertow.protocols.ssl.SslConduit.doHandshake(SslConduit.java:648)
at io.undertow.protocols.ssl.SslConduit.access$900(SslConduit.java:63)
at io.undertow.protocols.ssl.SslConduit$5$1.run(SslConduit.java:1084)
... 2 more
(Stack eventually shows this is due to an expired certificate:
Caused by: java.security.cert.CertificateExpiredException: NotAfter: Mon Apr 13 01:59:59
CEST 2015)
8< /snip >8
We have tried the naïve solution of taking the encountered Exception, wrap it into a
RuntimeException (because that’s the only way to escalate it from the Runnable#run()
method) and this yields limited success:
The Good News is that the RuntimeException is reported on System.err:
ERROR: XNIO000011: Task io.undertow.protocols.ssl.SslConduit$5$1@286a7112 failed with an
exception
java.lang.RuntimeException: javax.net.ssl.SSLHandshakeException: General SSLEngine
problem
at io.undertow.protocols.ssl.SslConduit$5$1.run(SslConduit.java:1088)
at org.xnio.nio.WorkerThread.safeRun(WorkerThread.java:592)
at org.xnio.nio.WorkerThread.run(WorkerThread.java:472)
Caused by: javax.net.ssl.SSLHandshakeException: General SSLEngine problem
The Bad News is that the original Exception (see above) is what is propagated to the
calling code; i.e. as a user of the library I still get a rather obscure error rather than
the SSLHandshakeException which provides me with the root cause.
We have looked through the code in SslConduit but to be frank we don’t really grok what’s
happening in there.
I would like to kindly ask if anyone here can provide some guidance or can pick up this
issue. I’m more than happy to file this as a proper issue in the Issue Tracker and do a
Pull-Request on GitHub; however the current „patch“ of simply throwing a new
RuntimeException(e) is too trivial as well as inadequate.
Kind regards,
Christian
--
Riege Software International GmbH
Mollsfeld 10, 40670 Meerbusch, Germany, T: +49 2159 9148 0, F: +49 2159 914811,
www.riege.com
Managing Directors: Christian Riege, Gabriele Riege, Dr. Tobias Riege
Commercial Register: Amtsgericht Neuss HRB-NR 4207, VAT Reg No.: DE120585842
YOU CARE FOR FREIGHT, WE CARE FOR YOU