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.
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
