On Thu, Nov 24, 2011 at 4:11 PM, Emmanuel Lecharny <[email protected]> wrote: > On 11/24/11 10:40 AM, Julien Vermillard wrote: >> >> On Thu, Nov 24, 2011 at 5:08 AM, Emmanuel Lecharny<[email protected]> >> wrote: >>> >>> Hi guys, >>> >>> yesterday, I fought with the way MINA 2 is dealing with SSL. Down the >>> line, >>> we use a filter for that, which handles the handhsake using the SslEngine >>> class. >>> >>> The problem is that at the same time, the session is considered as >>> opened, >>> even if we haven't done any handshake, as we can't add the SslFilter to >>> the >>> session if it's not created yet. That leads to a situation where we could >>> perfectly have an opened session but with a failed HandShake. >>> >>> For instance, as the handshake can be done when the first data is sent by >>> the client, we will generate an exceptionCaught event, process it, but >>> leave >>> to the handler to close the session. >>> >>> From the user PoV, it makes no sense to continue to use a session which >>> has >>> failed during the SSL handshake. IMO, the server should not even open the >>> session (the session should remain in the 'created' state, until the >>> handshake has been completed. Now, if we do that, the Connector won't be >>> able to send anything as the session is not connected. That leave us with >>> a >>> dilemna : we need the connection to be opened, but the connection should >>> not >>> be considered as valid until the handshake is done... How can we deal >>> with >>> this problem ? >>> >>> We decided that Ssl should be handled by the processor, not as a filter >>> in >>> the chain. That means : >>> - we can keep the session in the 'created' mode until the handshake has >>> been >>> done on the server side >>> - we can force the handshake to be done while creating the connection on >>> the >>> client side when using the Connector >>> - in all other case (ie if the client uses a plain Socket), we have no >>> problem as the session is not seen by the user. >>> >>> wdyt ? >>> >>> >> This use case cover only the I want my whole session SSLed, but not >> the use case when you start talking in plain unsecure TCP and a >> command trigger the TLS handshake. >> I wonder if there is use case where you try to TLS handshake and if it >> fail you continue talking using plain unsecure TCP. > > So, after some more investigation, here is what I'm coming to : > - we can't initiate the HS before the session has been created > - when we require a secure connection (either by connecting to a SSL server, > or by sending the server the information we want to switch to TLS), then > until the HS is completed (either successfully, or failing), no other data > can be sent to the server (or to the client) > - that means we must add a flag in the session that tells we are doing a HS > - if we try to send some data on a session which is in the middle of a HS, > we will get an error > - if we try to secure a connection while we have some pending operation, we > will get an error > > Is that ok ? >
Maybe we could simply wait for queue to be empty and send an error for any write during the handshake (a bit like we do for close) ?
