mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lécharny <elecha...@gmail.com>
Subject Re: Secured/Unsecured events ?
Date Tue, 14 May 2013 16:31:37 GMT
Le 5/14/13 11:35 AM, Jeff MAURY a écrit :
> On Tue, May 14, 2013 at 9:47 AM, Emmanuel Lécharny <elecharny@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.

Emmanuel Lécharny


Emmanuel Lécharny

View raw message