[
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)
