- We have a server application using Mina2. This endpoint is configured with Mina SSLFilter (clientAuth=MUST, no startTLS support)
If a client application (not able to do any kind of SSL) try to connect, we have identified the following.
1. TCP connection --> could be successfully established (might be Ok)
2. Client transmit some non-ssl encrypted payload --> client run into a timeout, TCP connection remain open
3. Client tries a second attempt to send non-ssl encrypted payload --> the message successfully pass through to the application!
Especially step 3 should never happen. Instead I would expect that somewhere in step 2 the connection to the client will be closed, because no handshake could be done.
We have already debugged a bit in the Mina SSL Filter and identified the following:
- During step 2, we see a SSLHandshakeException that will be thrown in the org.apache.mina.filter.ssl.SslFilter.messageReceived(NextFilter, IoSession, Object) method. But the SSL Filter seems to not handle such kind of Exception (org.apache.mina.filter.ssl.SslFilter.exceptionCaught(NextFilter, IoSession, Throwable) only handle WriteToClosedSessionException)?
- From the javadoc https://mina.apache.org/mina-project/apidocs/org/apache/mina/core/service/IoHandler.html#exceptionCaught(org.apache.mina.core.session.IoSession,%20java.lang.Throwable) it seems to be that Mina itself handle IoExceptions and close the connection. SSLHandshakeException is a IoException, but as described above, the connection is NOT closed. Additional Remark: The javadoc is for the IoHandler, not for IoFilter - so I am not sure if this rule also applies to the IoFilter?
We have not yet an proposal how to fix Mina and/or the Mina SSLFilter. We will try to workaround with a custom filter which close the session if SSLHandshakeException failed.
We have testet the problem with Mina 2.0.13 and 2.0.14.