[
https://issues.apache.org/jira/browse/DIRMINA-385?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Audley updated DIRMINA-385:
---------------------------------
Attachment: SSLFilter-1.1.0.patch
This is a patch against the 1.1.0 release. I'm currently using this in my code
and it works fine in the case where the SSLFilter is added to the chain before
the session is connected.
> SSLFilter starts writing to session before filter chain is complete
> -------------------------------------------------------------------
>
> Key: DIRMINA-385
> URL: https://issues.apache.org/jira/browse/DIRMINA-385
> Project: MINA
> Issue Type: Bug
> Components: Filter
> Affects Versions: 1.0.3, 1.1.0
> Reporter: Chris Audley
> Fix For: 1.0.4, 1.1.1, 2.0.0-M1
>
> Attachments: SSLFilter-1.1.0.patch
>
>
> The SSLFilter starts to write packets to the session as soon as it is added
> to the filter chain (in onPostAdd). However, this can result in errors if a
> filter exists or is added before SSLFilter in the processing order. Writing
> to the session in onPostAdd should be considered breaking the contract
> between filters and the session.
> If a filter is added in the processing order before the SSLFilter, but after
> the SSLFilter has been added, SSLFilter will have already sent some messages
> that the newly added filter will never have the opportunity to process. Any
> subsequent SSLFilter messages *will* be processed by the newly added filter,
> potentially creating inconsistencies.
> Even if the filter before the SSLFilter in processing order is added before
> the SSLFilter is added, having SSLFilter send messages in onPostAdd ignores
> the possibility that the other filter needs to send and/or receive messages
> before the connection is considered open by later filters in the chain.
> The specific circumstances of my problem is a web proxy traversal filter that
> needs to be placed in front of the SSLFilter in order to function correctly.
> This filter is responsible for sending the CONNECT message to the proxy to
> open an outside connection before the SSL session is negotiated. With the
> current behavior of SSLFilter, this is simply not possible.
> I have created a patch for SSLFilter that moves the code for initiated the
> handshake to sessionOpened. This works correctly in my situation, but breaks
> the case where an SSLFilter is added to the chain after the connection is
> opened. I try to address this by adding a conditional handshake initiation
> to onPostAdd only if the session is already connected. Unfortunately, the
> IoSession.isConnected() method only indicates if the session hasn't been
> closed. What SSLFilter.onPostAdd() needs is a way to determine if the
> sessionOpened event for the session has been fired. My patches disable the
> code in onPostAdd() until isConnected or another method is able to provide
> the necessary information.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
