[ https://issues.apache.org/jira/browse/DIRMINA-1083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16419532#comment-16419532 ]
Emmanuel Lecharny edited comment on DIRMINA-1083 at 3/29/18 6:26 PM: --------------------------------------------------------------------- This is defitively a problem on {{ApacheDS}}. Actually, more than one problem ;-) * The {{Handshake}} is initialized on both side, which makes no sense * We don't block the transmission of messages once the handshake has started, which is problematic and will cause the connection to be shutdown However there are some inconsistencies in the {{MINA}} code. The {{beginHandshake}} method does not have to be called, as it's called internally by the {{wrap}} or {{unwrap}} method, however, as we don't handle properly the {{NO_HANDSHAKING}} status - it's handled the same way as the {{FINISHED}} status : {code:java} ... /* no qualifier */void handshake(NextFilter nextFilter) throws SSLException { for (;;) { switch (handshakeStatus) { case FINISHED: case NOT_HANDSHAKING: if (LOGGER.isDebugEnabled()) { LOGGER.debug("{} processing the FINISHED state", sslFilter.getSessionInfo(session)); } session.setAttribute(SslFilter.SSL_SESSION, sslEngine.getSession()); handshakeComplete = true; // Send the SECURE message only if it's the first SSL handshake if (firstSSLNegociation && session.containsAttribute(SslFilter.USE_NOTIFICATION)) { // SESSION_SECURED is fired only when it's the first handshake firstSSLNegociation = false; scheduleMessageReceived(nextFilter, SslFilter.SESSION_SECURED); } if (LOGGER.isDebugEnabled()) { if (!isOutboundDone()) { LOGGER.debug("{} is now secured", sslFilter.getSessionInfo(session)); } else { LOGGER.debug("{} is not secured yet", sslFilter.getSessionInfo(session)); } } return; ... {code} we have, as a consequence, to call the {{beginHanshake}} method no matter what. This can be changed. More to come... was (Author: elecharny): This is defitively a problem on {{ApacheDS}}. Actually, more than one problem ;-) * The {{Handshake}} is initialized on both side, which makes no sense * We don't block the transmission of messages once the handshake has started, which is problematic and will cause the connection to be shutdown However there are some inconsistencies in the {{MINA}} code The {{beginHandshake}} method does not have to be called, as it's called internally by the {{wrap}} or {{unwrap}} method, however, as we don't handle properly the {{NO_HANDSHAKING}} status - it's handled the same way as the {{FINISHED}} status : {code:java} ... /* no qualifier */void handshake(NextFilter nextFilter) throws SSLException { for (;;) { switch (handshakeStatus) { case FINISHED: case NOT_HANDSHAKING: if (LOGGER.isDebugEnabled()) { LOGGER.debug("{} processing the FINISHED state", sslFilter.getSessionInfo(session)); } session.setAttribute(SslFilter.SSL_SESSION, sslEngine.getSession()); handshakeComplete = true; // Send the SECURE message only if it's the first SSL handshake if (firstSSLNegociation && session.containsAttribute(SslFilter.USE_NOTIFICATION)) { // SESSION_SECURED is fired only when it's the first handshake firstSSLNegociation = false; scheduleMessageReceived(nextFilter, SslFilter.SESSION_SECURED); } if (LOGGER.isDebugEnabled()) { if (!isOutboundDone()) { LOGGER.debug("{} is now secured", sslFilter.getSessionInfo(session)); } else { LOGGER.debug("{} is not secured yet", sslFilter.getSessionInfo(session)); } } return; ... {code} The consequence is that we need to call the {{beginHanshake}} method no matter what. This can be changed. More to come... > 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)