On Thu, Nov 24, 2011 at 4:31 PM, Emmanuel Lécharny <[email protected]> wrote: > On 11/24/11 4:16 PM, Julien Vermillard wrote: >> >> 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) ? > > It could be optionnal. > > The pb on the client side is that we have no idea if we will receive some > data from the server other than the one used by the HS. We may have long > pending read that can interfer with the HS : there is little we can do in > this case, but to fail during the HS (ie, everything we read is supposed to > be used by the SslEngine to terminate the HS). > > On the remote side, if we receive a TLS request, we could either empty the > write queue, and then start the HS, or generate an error if the queue is not > empty, or wait until the queue is empty to start the HS.
I was thinking about the write queue on the server, for the client it should be fine.
