Re: More SSL thoughts
Le 08/10/14 11:45, Jeff MAURY a écrit :
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.
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 {
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 ?
Re: More SSL thoughts
On Sat, Oct 11, 2014 at 8:24 AM, Emmanuel Lécharny elecha...@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 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.
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
Re: More SSL thoughts
Le 11/10/14 08:38, Jeff MAURY a écrit : On Sat, Oct 11, 2014 at 8:24 AM, Emmanuel Lécharny elecha...@gmail.com wrote: 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. F me... I thought you were mentionning MINA 2.0 all along this thread :/
Re: More SSL thoughts
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.
- 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 ?
Re: More SSL thoughts
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
