directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel L├ęcharny <elecha...@gmail.com>
Subject StartTLS implementation issue...
Date Fri, 30 Mar 2018 09:36:23 GMT
Hi guys,

this is something I was thinking about last night during my nightly
insomnia : I think we have a big issue with the StartTLS implementation,
in both the server and the client.

Beside the fact that switching to MINA 2.0.17 exposed the issue (I still
don't understand why it wasn't visible with MINA 2.0.16, still
investigationg), there are some things to address.

First of all, startTLS is an extended operation sent over an existing
connection. Once received the server should establish a secure
communication with the client. That involve the SSL filter in MINA,
which has to be added on both the client and the server. This is
described in 4.14 of RFC 4511 [1].

In our current implementation, the client will send a StartTLS extended
operation, the server will process it, inject a SslFilter in the MINA
chain, initialize the handshake (which is not good), but in no case it
will block any message to be read or written during the handshake. This
is a first problem.

On the client side, we have teh exact same problem : while waiting for
the extended response, we don't block the connection, so some message
may be written to the server.

The logic should instead be :

Client: startTLS is invoked
Client: block any new message, stack them in a queue until the handshake
is completed (that should be done on the session, because some othe
rthreads may send messages too)
Client: send the startTLS request, wait for the response
...
               Server: process the startTLS extended operation
               Server: block outgoing responses
               Server: add the sslFilter in the MINA chain
               Server: send back the extended response (as the SslFilter
is not active yet, no encryption will be done
               Server: wait for the CLIENT HELLO message
               ...
Client: process the extended response
Client: initiate handshake
...
<handshake between  the client and the server>
...
               Server: Done with handshake, we can flush the pending
responses
Client: done with handshake, we can flush the pending messages


Note that there are also some broken logic on MINA, and at the moment,
we can't switch to 2.0.17, we have to stay with 2.0.6. I expect to have
MINA fixed in 2.0.18, but in the mean time, we have things to cleanup in
the client and in the server.

Also note that we don't have decent tests that expose the problem. It's
also not something that is a frequent issue, peope aren't using startTLS
a lot... (and it's sad :/)

More to come.
[1] https://tools.ietf.org/html/rfc4511#page-40

-- 
Emmanuel Lecharny

Symas.com
directory.apache.org


Mime
View raw message