You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mina.apache.org by Jeff MAURY <je...@jeffmaury.com> on 2014/12/12 22:34:47 UTC
[MINA3] SSL
Hello,
I just committed a bunch of files with the work on the SSL I've been doing
recently.
There are still issues I want to discuss with you:
- as the SSLEngine is record oriented, a message submitted for write may
be splitted in several records, leading to several sentMessage events. Do
you think we can keep the current behaviour or should be hide intermediate
events and wait for the last record to be sent to generate the single event
- When a close SSL even is received, an event is generated but the
underlying transport is not closed: my intent is to provided automatic
closing in a separate filter
- In order to deal with all the TLS/SSL/POODLE isssues, I think this
could be a good idea that the current SSL details ( protocol, algorithm) be
provided in the handshake completed event so that we can provided better
protection through the filter.
Regards
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
Re: [MINA3] SSL
Posted by Jeff MAURY <je...@jeffmaury.com>.
On Sat, Dec 13, 2014 at 9:23 AM, Emmanuel Lecharny <el...@apache.org>
wrote:
> Le vendredi 12 décembre 2014, Jeff MAURY <je...@jeffmaury.com> a
> écrit :
>
> > Hello,
> >
> > I just committed a bunch of files with the work on the SSL I've been
> doing
> > recently.
> > There are still issues I want to discuss with you:
> >
> > - as the SSLEngine is record oriented, a message submitted for write
> may
> > be splitted in several records, leading to several sentMessage events.
> > Do
> > you think we can keep the current behaviour or should be hide
> > intermediate
> > events and wait for the last record to be sent to generate the single
> > event
>
>
> One single event. That means we should be able to detect when we are done
> with the original message sending.
>
OK, I'll implement it.
>
>
> > - When a close SSL even is received, an event is generated but the
> > underlying transport is not closed: my intent is to provided automatic
> > closing in a separate filter
>
>
> What about SSL renegotiation ? Also when implemention StartTls, we should
> be able to go back to a non-SSL session without closing the underlying
> transport AFAIR
>
SSL renegotiation is supported (see unit test), all least rehandshake has
been validated.
That's why I decided to not to hardcode it in core and let's it optional in
a filter (with a flag).
So StartTLS should be supported, although there is no API verb to leave a
secure session yet.
>
>
>
> > - In order to deal with all the TLS/SSL/POODLE isssues, I think this
> > could be a good idea that the current SSL details ( protocol,
> > algorithm) be
> > provided in the handshake completed event so that we can provided
> better
> > protection through the filter.
>
>
> The best solution is to let the user define which algo he/she wants to use.
> This what we do with Mina 2.
>
Yes, but I think we could also provide a secure implementation of the
filter that implements by default whatever the user has choosen. Also
another pro is that you can fine control the selected algorithm based on an
external criteria (user, location,...)
>
>
> Thanks Jeff
>
>
> >
> > Regards
> > 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
> >
>
>
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
>
--
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
Re: [MINA3] SSL
Posted by Emmanuel Lecharny <el...@apache.org>.
Le vendredi 12 décembre 2014, Jeff MAURY <je...@jeffmaury.com> a écrit :
> Hello,
>
> I just committed a bunch of files with the work on the SSL I've been doing
> recently.
> There are still issues I want to discuss with you:
>
> - as the SSLEngine is record oriented, a message submitted for write may
> be splitted in several records, leading to several sentMessage events.
> Do
> you think we can keep the current behaviour or should be hide
> intermediate
> events and wait for the last record to be sent to generate the single
> event
One single event. That means we should be able to detect when we are done
with the original message sending.
> - When a close SSL even is received, an event is generated but the
> underlying transport is not closed: my intent is to provided automatic
> closing in a separate filter
What about SSL renegotiation ? Also when implemention StartTls, we should
be able to go back to a non-SSL session without closing the underlying
transport AFAIR
> - In order to deal with all the TLS/SSL/POODLE isssues, I think this
> could be a good idea that the current SSL details ( protocol,
> algorithm) be
> provided in the handshake completed event so that we can provided better
> protection through the filter.
The best solution is to let the user define which algo he/she wants to use.
This what we do with Mina 2.
Thanks Jeff
>
> Regards
> 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
>
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com