mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff MAURY <jeffma...@jeffmaury.com>
Subject Re: More SSL thoughts
Date Sat, 11 Oct 2014 06:38:16 GMT
On Sat, Oct 11, 2014 at 8:24 AM, Emmanuel Lécharny <elecharny@gmail.com>
wrote:

> Le 08/10/14 11:45, Jeff MAURY a écrit :
> > On Wed, Oct 8, 2014 at 10:33 AM, Emmanuel Lécharny <elecharny@gmail.com>
> > wrote:
> >
> >> Le 07/10/14 23:37, Jeff MAURY a écrit :
> >>> Hello,
> >>>
> >>> as I'm working on the SSL part this time and more specifically on the
> >>> handshake/rehandshake processing, I have a couple of questions and some
> >>> infos to share:
> >>>
> >>>    - I've added 3 more methods in IoHandler to reflect handshake
> related
> >>>    event: handshakeStarted, handshakeCompleted and secureClosed. I've
> >> added
> >>>    them as well to IoFilter but I don't quite understand the philosophy
> >> as
> >>>    some method have a chain controller to call the next filter and some
> >> not
> >> The idea behind the chain of filters is that any event is propagated up
> >> to the final filter (ie, the Iohandler) by each filter. If one filter
> >> decide not to propagate the event, then obviously the IoHandler will not
> >> receive it. This is thus to the Filter implementer to be sure it does
> >> propagate the event to teh next filter. If it does not, this is either a
> >> mistake, or a decision that has to be heavily and carefully thought.
> >>
> >> The pb is to delegate this responsability to the filter. It would be
> >> easier if the controller was to propagate the event further without
> >> expecting teh filter to do so. That woudl require some careful rework of
> >> the controller, as in some case (like errors, exceptions, etc) we don't
> >> want to propagate the event.
> >>
> >> In some other cases, we simply want the filter to handle the event
> >> propagation (typically this is the case for the MessageReceived when we
> >> are using a decoder filter : there is no mean to propagate the event
> >> automatically if a full message has not been decocded).
> >>
> >> This is definitively something we want to think about.
> >>
> > What I didn't understand is that not all of IOFilter method signatures
> have
> > a ChainController so I did not understand how they can decide to swallow
> > the event or not.
>
> Not sure what you mean by "not all of IOFilter method signatures have a
> ChainController" in Mina 2.0 context.
>
> The IoFilter class has 3 sets of methods :
> - methods that propagate an event :
>   o exceptionCaugth
>   o filterClose
>   o filterWrite
>   o inputClose
>   o messageReceived
>   o messageSent
>   o sessionClosed
>   o sessionCreated
>   o sessionIdle
>   o sessionOpened
>
I don't agree for MINA 3. See
https://github.com/apache/mina/blob/trunk/core/src/main/java/org/apache/mina/api/IoFilter.java


>
>  Those methods have a NextFilter parameter, which is the filter that
> will receive the event, should the current filter decide to propagate
> it. This can be seen in, for instance, the BlackListFilter :
>
>     public void messageSent(NextFilter nextFilter, IoSession session,
> WriteRequest writeRequest) throws Exception {
>         if (!isBlocked(session)) {
>             // forward if not blocked
>             nextFilter.messageSent(session, writeRequest);
>         } else {
>             blockSession(session);
>         }
>     }
>
>
> - methods that manage the chain manipulation :
>   o onPreAdd
>   o onPostAdd
>   o onPreRemove
>   o onPostRemove
>
>  Those methods just react on the addition or removal of the current
> filter from the session chain.
>
> - general methods :
>   o init
>   o destroy
>
>  Those methods are called when the filter is created or destroyed.
>
> Note that all the filter extends the IoFilterAdapter which already have
> a default implementation for all those methods (hence it should be an
> abstract method, IMO).
>
> Is that what you wanted to get some clarification on ?
>
> >
> >>>    - In order to support rehandshaking et being efficient, we must keep
> >> the
> >>>    same SSLEngine.
> >> Ok, makes sense.
> >>> So my idea to start a new handshake was to reuse what we
> >>>    have today through the initSecure method: if the SSLContext is null,
> >> I don't see how we can have a null SSLContext, as we create it before
> >> creating the SSLFilter, and there is a check for nullity in this
> >> constructor :
> >>
> >>     public SslFilter(SSLContext sslContext, boolean autoStart) {
> >>         if (sslContext == null) {
> >>             throw new IllegalArgumentException("sslContext");
> >>         }
> >>
> >> Assuming we always have a not null SSLContext, how does it translates in
> >> your proposed algorithm ?

>>
> > I was mentioning the SSLContext that is the argument of the initSecure
> > method. Please note that in 3.0, there is no more SSLFilter as SSL
> handling
> > has been moved to core.
> > So my idea is that if no SSLContext is given to initSecure and SSLHandler
> > is attached to the session, we keep the same underlying SSLEngine and we
> > start a new handshake
>
> I see. You propose to handle the handshake re-negociation through a call
> to a newly added method called initSecure( SslContext ) in MINA 2, is
> that correct ?
>
No, I was talking about MINA3 and about the semantic of this existing
method.

Jeff




-- 
Jeff MAURY


"Legacy code" often differs from its suggested alternative by actually
working and scaling.
 - Bjarne Stroustrup

http://www.jeffmaury.com
http://riadiscuss.jeffmaury.com
http://www.twitter.com/jeffmaury

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message