On Tue, May 14, 2013 at 9:47 AM, Emmanuel Lécharny <[email protected]>wrote:
> Le 5/13/13 10:30 PM, Jeff MAURY a écrit : > > Hi, > > > > As I'm reading the TLS specs, I noticed that the processing of the close > > alarm, if not critical, may leave the underlaying transport connection > > (socket) open, probably to deal with STARTTLS behavior. > Yes. > > > So one option would be to had two new events: Secured (end of handshake) > > and Unsecured (Non critical Close alarm received). > We have flags in the session which can be set to tell if the session is > secured or not. Do we really need two events to be propagated to the > IoHandler ? > > Another pro is that in case of re-handshake, the application can now be > > notified. > That's a good use case. > > > By the way, do you know how the critical flag is given back by the > > SLLEngine ? > My understanding is that the close alert results in the SSLEngine to > change the SSLEngineResult status to CLOSED. > That was my understanding also but we've lost the critical flag. Should we delegate the responsability to the application if we have these new events ? My idea was that when we got the CLOSED from the SSLEngine we generate an Unsecured event and if the critical flag is set, we close the socket Jeff > > -- > 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
