Re: LDAP API & new MINA version

[Emmanuel Lécharny <el...@gmail.com>]

Hi,

status: still working on it. I had spent hours (in the tens) trying to 
go through a problem in MINA 2.2 relative to the TLS renegociation, 
which was failing.
The decision has been made to not support TLS renegociation in MINA 2.2, 
which is a sane decision due to the demonstrated MITM attacks it allows 
[1]. Also note that TLS 1.3 has excluded this feature.

I'll move forward from this point.

[1] 
https://gitweb.torproject.org/torspec.git/plain/proposals/169-eliminating-renegotiation.txt

On 20/01/2022 18:31, Emmanuel Lécharny wrote:
> Ok, some feedback regarding the StartTLS handling...
> 
> In order to have this operation working, we had to 'bend' MINA a bit. We 
> added an session attribute to handle the response. Let me explain.
> 
> When a startTLS request is processed by the server, we do two things:
> - we setup the SSL filter in the MINA chain
> - when done, we send back the startTLS response to the client
> 
> The client, receiving the startTLS response, initiate the TLS handshake 
> to finish the TLS establishement.
> 
> And now, we have a problem, because as the SSL filter has been setup 
> *before* sending the startTLS response to the client, we can't anymore 
> send this response because the SslFilter will try to encrypt it.
> 
> Otoh, if we start by sending the response before establishing the 
> SslFilter, there is a high risk that the client start the HS before the 
> SslFilter is installed.
> 
> This is a typical chicken&egg issue.
> 
> The way we 'solved' (aka 'hacked') it, was to set a flag telling the 
> SslFilter "do not encrypt the next message, but only the next one".
> 
> This worked, but is not safe, in a concurrent system.
> 
> Jonathan, who rewrote the SslFilter entirely, removed this flag and 
> replaced it by something way smarter. But he is suggesting not using 
> what he implemented. He said, rightfully, that we should instead writhe 
> a StartTLS filter that would deal with all this crap. The idea would be 
> to install the StartTLS filter, which would only process startTLS 
> request and Response, and which would by pass the SslFilter when the 
> response has to be sent. This is possible because it has access to the 
> chain, and can call the 'writeMessage' of any filter (ie bypassing the 
> SslFilter).
> 
> I'm working around the idea.
> 
> 
> On 17/01/2022 17:13, Emmanuel Lécharny wrote:
>> Pb solved.
>>
>> I now have issue with the startTLS extended request handling on the 
>> server.
>>
>>
>> Will look at it tonite.
>>
>> On 17/01/2022 14:50, Emmanuel Lécharny wrote:
>>> Ok, beside a few tweaks, MINA 2.2 works just fine with the LDAP API.
>>>
>>> However, there aws a removal of the SslSession from the IoSession, 
>>> and it's used by the server in the ExternalSaslServer:
>>>
>>>      public byte[] evaluateResponse( byte[] initialResponse ) throws 
>>> SaslException
>>>      {
>>>          try
>>>          {
>>>              SSLSession sslSession = ( SSLSession ) 
>>> getLdapSession().getIoSession().getAttribute( SslFilter.SSL_SESSION );
>>>              Certificate[] peerCertificates = 
>>> sslSession.getPeerCertificates();
>>>
>>>              if ( null == peerCertificates || 1 > 
>>> peerCertificates.length )
>>>              {
>>>                  throw new SaslException( "No peer certificate 
>>> provided - cancel bind." );
>>>              }
>>>
>>>              getLdapSession().setCoreSession( authenticate( 
>>> peerCertificates[0] ) );
>>>              state = NegotiationState.COMPLETED;
>>>          }
>>>
>>> We can most certainly get it back in MINA.
>>>
>>>
>>>
>>> On 17/01/2022 09:37, Emmanuel Lécharny wrote:
>>>> Hi !
>>>>
>>>> this morning, I will test the LDAP API (and the server) with a new 
>>>> version of MINA (2.2) which has a totally rewritten SSL handler.
>>>>
>>>> Hopefully, it will solve the TLS 1.3 issue and be slightly faster.
>>>>
>>>> I'll keep you informed !
>>>>
>>>
>>
> 

-- 
*Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE
T. +33 (0)4 89 97 36 50
P. +33 (0)6 08 33 32 61
emmanuel.lecharny@busit.com https://www.busit.com/

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@directory.apache.org
For additional commands, e-mail: dev-help@directory.apache.org