On 11/24/11 4:35 PM, Julien Vermillard wrote:
On Thu, Nov 24, 2011 at 4:31 PM, Emmanuel Lécharny<elecha...@apache.org> wrote:
On 11/24/11 4:16 PM, Julien Vermillard wrote:
On Thu, Nov 24, 2011 at 4:11 PM, Emmanuel Lecharny<elecha...@gmail.com>
wrote:
On 11/24/11 10:40 AM, Julien Vermillard wrote:
On Thu, Nov 24, 2011 at 5:08 AM, Emmanuel Lecharny<elecha...@gmail.com>
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.
IMO, we should make it optional. For instance, in LDAP, it's up to the
StartTLS sender to be sure that there is no pending operation. That
means we don't have to take care of such a scenario on the Connector, as
it's already handled by the LDAP implementation.
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
