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 2022/01/17 08:37:37 UTC
LDAP API & new MINA version
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@directory.apache.org
For additional commands, e-mail: dev-help@directory.apache.org
Re: LDAP API & new MINA version
Posted by 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
Re: LDAP API & new MINA version
Posted by Emmanuel Lécharny <el...@gmail.com>.
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
Re: LDAP API & new MINA version
Posted by Emmanuel Lécharny <el...@gmail.com>.
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
Re: LDAP API & new MINA version
Posted by Emmanuel Lécharny <el...@gmail.com>.
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@directory.apache.org
For additional commands, e-mail: dev-help@directory.apache.org