Le 5/14/13 11:35 AM, Jeff MAURY a écrit : > On Tue, May 14, 2013 at 9:47 AM, Emmanuel Lécharny <elecha...@gmail.com>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
The application might be interested in being informed about the switch to secure/unsecure mode. So my +1 for the two events. -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com > -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com
