SSLEngine closing prematurely on SSLHandshakeException?

I have worked with the SSLEngine using non-blocked IO and it mostly works.

I do have a problem when a client connects and I get

WorkerThread-1, fatal error: 40: no cipher suites in common

javax.net.ssl.SSLHandshakeException: no cipher suites in common

WorkerThread-1, SEND TLSv1 ALERT: fatal, description = handshake_failure

WorkerThread-1, WRITE: TLSv1 Alert, length = 2

in a delegate task. The handshake status is NEED_WRAP after this but when

I callwrapHandshake I get

WorkerThread-1, fatal: engine already closed. Rethrowing javax.net.ssl.SSLHandshakeException: no cipher suites in common

which means I'm not able to send the error reply to the connected client.

Is this a bug in SSLEngine or simply a misunderstanding on my part on what's going on.

I'm thankful for any insight on this.

regards

/Magnus Hulth閚

[918 byte] By [emha] at [2007-10-2 14:16:49]
# 1

It is hard to know because we don't have the code to wrapHandshake(). However, NEED_WRAP makes sense because the engine wants to spit out a handshake_failure error alert to send to the peer. So the subsequent SSLEngine.wrap() call should consume no application data and put the error alert onto the destination ByteBuffer, which you then send to on to the peer.

ghstarka at 2007-7-13 12:33:12 > top of Java-index,Security,Java Secure Socket Extension (JSSE)...
# 2

Thanks,

Yes that would make sense, and that is how I would expect it to work.

The problem is that when call wrap (not wrapHandshake as I mistakenly wrote in my previous post) I get the exception

WorkerThread-1, fatal: engine already closed. Rethrowing javax.net.ssl.SSLHandshakeException: no cipher suites in common

Just to see if there was some timing issue involved I tried to call wrap immediately after the delegated task finished and still got the same exception.

What it looks like to me is that the engine needs to wrap the error message but is already closed by the handshake error and therefore not able to actually perform the wrap.

emha at 2007-7-13 12:33:12 > top of Java-index,Security,Java Secure Socket Extension (JSSE)...
# 3
Well, that does seem wrong. I wonder if it is a design error to throw an exception in the first place? I guess the only workaround is to examine the exception and generate your own error alert
ghstarka at 2007-7-13 12:33:12 > top of Java-index,Security,Java Secure Socket Extension (JSSE)...