You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@directory.apache.org by Emmanuel Lécharny <el...@gmail.com> on 2018/03/30 09:36:23 UTC

StartTLS implementation issue...

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

Re: StartTLS implementation issue...

Posted by Emmanuel Lecharny <el...@apache.org>.

Ok I think I went to the bottom of this issue.

There is no problem on the server side, I was wrong when I wrote it was not blocking outgoing messages : we have a queue for that.

On the API side, however, we have a big issue : we don't wait for the handshake to complete, so we can send message while the handshake is still going on, which leads to random failures (ie if you are lucky, your message goes through the SslFilter just after the handshake completed, and all is good, bt otherwise the message get in the middle of the handshake messages, and it fails).

Atm, I added a workaround : I have an infinite loop that wait for the handshake to compete, with a 10ms wait to avoid eating all the CPU.

I'm looking toward a better solution, where the connection is informed when the handshake has completed (like using a future, for instance).

I'll try to get that done this week-end.

On 2018/03/30 09:36:23, Emmanuel LÃ©charny <el...@gmail.com> wrote: 
> 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
> 
>