Hi Guus,
On 31/03/2022 19:43, Guus der Kinderen wrote:
Thanks for the fast response Emmanuel,
Although I was able to build 2.2.0-SNAPSHOT, it doesn't seem to
be API
compatible with 2.1.3.
Things that I ran into:
* SslFilter.DISABLE_ENCRYPTION_ONCE no longer exists (which we
use to
implement StartTLS).
Yes, it was a source of problem. The way we deal with the
requirement to
send the StartTLS response in clear text *before* setting the
SslFilter
now is to use a dedicated filter. here is what we do in Apache
Diectory
Server:
public class StartTlsFilter extends IoFilterAdapter
{
/**
* {@inheritDoc}
*/
@Override
public void filterWrite( NextFilter nextFilter, IoSession
session,
WriteRequest writeRequest ) throws Exception
{
if ( writeRequest.getOriginalMessage() instanceof
StartTlsResponse )
{
// We need to bypass the SslFilter
IoFilterChain chain = session.getFilterChain();
for ( IoFilterChain.Entry entry : chain.getAll() )
{
IoFilter filter = entry.getFilter();
if ( filter instanceof SslFilter )
{
entry.getNextFilter().filterWrite( session,
writeRequest );
}
}
}
else
{
nextFilter.filterWrite( session, writeRequest );
}
}
}
This is pretty straight forward: when we go through this filter
with a
StartTLS response message, we bypass the SslFilter, otherwise we
call it.
* SslFilter.SSL_SESSION no longer exists. Is
SslFilter.SSL_SECURED a
drop-in replacement?
Yes. For instance, in FtpServer:
if (getFilterChain().contains(SslFilter.class)) {
SSLSession sslSession =
(SSLSession)getAttribute(SslFilter.SSL_SECURED);
* SslFilter.setUseClientMode(boolean) no longer exists.
It's computed automatically:
sslEngine.setUseClientMode(!session.isServer());
You may want to add the isServer() method in your IoSession
implementation, but by default it's defined in the
AbstractIoSession to be :
@Override
public boolean isServer() {
return (getService() instanceof IoAcceptor);
}
WIth all that commented out, I'm still getting errors, but I'm
not sure
if that's the same error, or if I'm now seeing a new error because I
broke StartTLS (which our test depends on)
Most certainly it's broken because of teh lack of clear text response
before the filter is set. See the added filter upper.
On Thu, Mar 31, 2022 at 3:37 PM Emmanuel Lécharny
<elecha...@gmail.com <mailto:elecha...@gmail.com>
<mailto:elecha...@gmail.com <mailto:elecha...@gmail.com>>> wrote:
Hi Guus,
I have successfully ran Apache Directory LDAP API and Server
with MINA
2.2.0-SNAPSHOT, which has a fully rewritten SSL handling code.
It seems there are some kind of race condition in MINA
2.0.X/2.1.X
and I
expect MINA 2.2.X solve this issue.
Could you give it a try ? You'll have to build the 2.2.X branch:
$ git clone -b 2.2.X
https://gitbox.apache.org/repos/asf/mina.git
<https://gitbox.apache.org/repos/asf/mina.git>
<https://gitbox.apache.org/repos/asf/mina.git
<https://gitbox.apache.org/repos/asf/mina.git>> mina-2.2.X
$ cd mina-2.2.X
$ mvn clean install
Just let me know if it's any better...
On 31/03/2022 14:53, Guus der Kinderen wrote:
> Hi Emanuel,
>
> I remember that you wrote that you were engaged in an epic
battle
with
> an elusive TLS 1.3 bug in MINA. I'm now running into an issue
that is
> specific to TLS 1.3, which occurs in MINA 2.1.3 as well as
2.1.6
(I did
> not try other versions), and does /not/ occur with a
connection
manager
> that is not powered by MINA.
>
> The work-around that a third party developer found is
surprising.
They
> add a 1ms delay before starting to send data over a socket
that
has just
> finished the TLS handshake. With that delay, the problem is
consistently
> gone. Without that delay, it consistently is reproducible.
>
> Their evaluation of the problem is documented here:
> https://github.com/xmppjs/xmpp.js/issues/889
<https://github.com/xmppjs/xmpp.js/issues/889>
<https://github.com/xmppjs/xmpp.js/issues/889
<https://github.com/xmppjs/xmpp.js/issues/889>>
> <https://github.com/xmppjs/xmpp.js/issues/889
<https://github.com/xmppjs/xmpp.js/issues/889>
<https://github.com/xmppjs/xmpp.js/issues/889
<https://github.com/xmppjs/xmpp.js/issues/889>>>
>
> My questions:
>
> * Does this relate to the issue that you were trying to
solve?
> * Why do we _consistently_ suffer from this, assuming that
others are
> able to use MINA with TLS 1.3 at least some of the time?
> * How do we prevent this issue without depending on the
client
> applying the 1ms sleep workaroud?
>
> Kind regards,
>
> Guus
--
*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.lecha...@busit.com <mailto:emmanuel.lecha...@busit.com>
<mailto:emmanuel.lecha...@busit.com
<mailto:emmanuel.lecha...@busit.com>>
https://www.busit.com/ <https://www.busit.com/>
<https://www.busit.com/ <https://www.busit.com/>>
--
*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.lecha...@busit.com <mailto:emmanuel.lecha...@busit.com>
https://www.busit.com/ <https://www.busit.com/>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
<mailto:dev-unsubscr...@mina.apache.org>
For additional commands, e-mail: dev-h...@mina.apache.org
<mailto:dev-h...@mina.apache.org>
