On Sat, Dec 13, 2014 at 9:23 AM, Emmanuel Lecharny <[email protected]> wrote:
> Le vendredi 12 décembre 2014, Jeff MAURY <[email protected]> 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
