[
https://issues.apache.org/jira/browse/DIRMINA-385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12512307
]
Trustin Lee commented on DIRMINA-385:
-------------------------------------
Then what do you think about adding an option that disables autostart of SSL
handshake? Would it resolve your issue?
> 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
> Assignee: Trustin Lee
> Attachments: SSLFilter-1.1.0.patch, SSLFilter-HEAD.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.
