mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lécharny <elecha...@gmail.com>
Subject Re: More SSL thoughts
Date Sat, 11 Oct 2014 06:24:00 GMT
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

 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 {

- 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 ?

View raw message