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
[email protected] https://www.busit.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
