[undertow-dev] Discarded Exception in SSL handshake

[Christian Riege]

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 at 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