On Wed, Oct 8, 2014 at 10:33 AM, Emmanuel Lécharny <elecha...@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.
>
> > - 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
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
