[
https://issues.apache.org/jira/browse/DIRMINA-1083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16419834#comment-16419834
]
Emmanuel Lecharny commented on DIRMINA-1083:
--------------------------------------------
There is another problem in the {{SslFilter}} : if we add the filter 'on the
fly' (typically what will happen with the {{StartTLS}} operation), we generally
tell the client , which has initiated the {{startTLS}} operation, that the
server agreed on setting the secured session, and the server will just wait for
the client to initiate the handshake. In the mean time, the {{SslFilter}} has
been added into the chain.
The thing is that we send a message to the client, and we set the
{{DISABLE_ENCRYPTION_ONCE}} session flag to disable the encryption of this very
message. So far, so good, except that when unstacking the calls, we also write
a second (empty) message, which is just a marker (this is when the
{{IoProcessor}} sees this empty message that it knows it can generate the
{{messageSent}} event).
The problem is that once we have bypassed the 'real' message because of the
{{DISABLE_ENCRYPTION_ONCE}} flag, we remove this flag from the session, and the
empty message will trigger the encryption. That's ok because the {{SslEngine}}
is currently already initialized and the handshake has already been done, but
this is really a side effect: *IF*, as expected, we defer the handshake waiting
for the client to start it, then we have a problem.
This is more than ugly. This is utterly broken.
I do think the server should *never* initiate the handshake, and should instead
wait for the {{HelloClient}} message (note that what I mean is that we should
leave the {{SSLEngine}} in a {{NO_HANDSHAKING}} state, and don't call the
{{begingHandshake())} method on the server.). We should also enqueue the
message to be written until the handshake is completed, once the {{SslFilter}}
has been added to the chain.
> Regression on SSL connection
> ----------------------------
>
> Key: DIRMINA-1083
> URL: https://issues.apache.org/jira/browse/DIRMINA-1083
> Project: MINA
> Issue Type: Bug
> Affects Versions: 2.0.17
> Reporter: Emmanuel Lecharny
> Priority: Major
> Fix For: 2.0.18
>
>
> We are using MINA in Apache Directory. After having moved to MINA 2.0.17, we
> now have failures like :
> {noformat}
> Running org.apache.directory.shared.client.api.LdapSSLConnectionTest
> java.io.IOException: Broken pipe
> at sun.nio.ch.FileDispatcherImpl.write0(Native Method)
> at sun.nio.ch.SocketDispatcher.write(SocketDispatcher.java:47)
> at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:93)
> at sun.nio.ch.IOUtil.write(IOUtil.java:65)
> at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:471)
> at
> org.apache.mina.transport.socket.nio.NioProcessor.write(NioProcessor.java:384)
> at
> org.apache.mina.transport.socket.nio.NioProcessor.write(NioProcessor.java:47)
> at
> org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.writeBuffer(AbstractPollingIoProcessor.java:1107)
> at
> org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.flushNow(AbstractPollingIoProcessor.java:994)
> at
> org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.flush(AbstractPollingIoProcessor.java:921)
> at
> org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.run(AbstractPollingIoProcessor.java:688)
> at
> org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:64)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
