directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <>
Subject Re: StartTLS implementation issue...
Date Sat, 31 Mar 2018 05:49:13 GMT
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 <> 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]
> -- 
> Emmanuel Lecharny

View raw message