You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mina.apache.org by Jonathan Valliere <jo...@emoten.com> on 2022/04/01 11:29:57 UTC
Re: MINA and TLS 1.3 (1ms sleep hack?)
Another way to do that is to have the SslFilter -> Your Clear Text Control
Plane Filter
The Control Plane Filter can conditionally wrap a WriteRequest in a
DisableEncryptWriteRequest. This guarantees that ONLY that message
bypasses the SslFilter
CONFIDENTIALITY NOTICE: The contents of this email message and any
attachments are intended solely for the addressee(s) and may contain
confidential and/or privileged information and may be legally protected
from disclosure.
On Mar 31, 2022 at 4:34:18 PM, Emmanuel Lécharny <el...@gmail.com>
wrote:
> 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 <elecharny@gmail.com
>
> <ma...@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> 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>>
>
> >
>
> > 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.lecharny@busit.com <ma...@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.lecharny@busit.com https://www.busit.com/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@mina.apache.org
> For additional commands, e-mail: dev-help@mina.apache.org
>
>
Re: MINA and TLS 1.3 (1ms sleep hack?)
Posted by Emmanuel Lécharny <el...@gmail.com>.
Hi Guus,
On 05/05/2022 17:35, Guus der Kinderen wrote:
> Hi everyone,
>
> Apologies for taking a long time to get this tested, but things got
> complicated.
>
> Long story short: the issue with TLS v1.3 that I described (needing a
> 1ms wait around the TLS handshake) does no longer seem to exist with
> commit 7d8930d7f47dc94c4f155b77e074d4384b34c5e4 / tag 2.2.0 of Apache MINA.
>
> ... unless I have repeatedly messed up testing, which happens with many
> moving parts. I'd love a second pair of eyes confirming this.
I have fixed a nasty issue that was causing some issue
(https://gitbox.apache.org/repos/asf?p=mina.git;a=commit;h=f64544006e9714541e1b472cef5be58148a3fd01)
>
> As a couple of asides:
> I'm not particularly fond of the StartTlsFilter approach, because its
> implementation is tied to whatever protocol that you're using.
Hmmm, not sure to understand what you mean. The SslFilter will always be
first in the chain, so the protocol you are using is pretty irrelevant.
As we're
> using XMPP, not LDAP, the StartTlsResponse class comparison didn't fly.
Ok, you mean StartTLS specific for your protocol. True that it is an
issue because the first response you will send *must* be in clear text,
in order to inform the client that the startTLS message has been
received. That collides with the fact that the SSL filter has already
been added to the chain, so you must bypass this filter when sending
this response.
Jonathan has added a specific class for that purpose, which can be used
to send the clear text message without being handled by the SslFilter.
For LDAP and FTP, I have added a specific filter that bypass the SSL
filter when the StartTLS response is sent, but it's kind of a protocol
trick, I agree.
In MINA 2.0/2.1, it was handled differently, with an Attribute flag that
said 'please SSLFilter, do *not* handled the *next* message and only the
*next* message'. This is also a kind of hack.
Jonathan solution is probably better, but it has to be used at the
Adapter level.
The thing here is that we might have decided to do that:
- send back the clear text message
- install the SSLFilter
but that does not fly because we may receive the ClientHello message
*before* the SslFilter is installed.
> Instead, I resorted to this:
>
> if (writeRequest.getOriginalMessage()instanceof IoBuffer &&
> ((IoBuffer) writeRequest.getOriginalMessage()).hasArray() &&
> new String(((IoBuffer) writeRequest.getOriginalMessage()).array()).trim().equals("<proceed xmlns=\"urn:ietf:params:xml:ns:xmpp-tls\"/>") )
>
> (Which probably can be made smarter). Another downside of this is that
> it will add a considerable amount of processing to each request if you
> neglect to remove the filter after usage.
>
> I'm not sure if Jonathan's suggestion is better, in that respect. I'm
> not familiar enough with MINA to understand what is suggested.
>
> Unrelated, since e2e0f2561fe51374091f6a943b462198c62d2b14 the build
> requires Maven version 3.8 or later. Why is this? The build seems to run
> fine with 3.6.3 - which is the version that is made available through
> Ubuntu's 20.04 package manager.
>
> If there is a reason to require a specific version, then maybe it could
> be considered to add a Maven Wrapper (mvnw) to the project. If there's
> no such requirement, then maybe drop the requirement, as to not throw up
> unexpected and unneeded hurdles?
That is my fault. I may move back to an older version of maven for the
official release, if needed. I'm currently tracking another issue that
made me freeze the 2.2.0 release.
`
>
> Kind regards,
>
> Guus
>
>
> On Fri, Apr 1, 2022 at 1:29 PM Jonathan Valliere
> <jon.valliere@emoten.com <ma...@emoten.com>> wrote:
>
> Another way to do that is to have the SslFilter -> Your Clear Text
> Control Plane Filter
>
> The Control Plane Filter can conditionally wrap a WriteRequest in a
> DisableEncryptWriteRequest. This guarantees that ONLY that message
> bypasses the SslFilter
>
> CONFIDENTIALITY NOTICE: The contents of this email message and any
> attachments are intended solely for the addressee(s) and may contain
> confidential and/or privileged information and may be legally
> protected from disclosure.
>
>
> On Mar 31, 2022 at 4:34:18 PM, Emmanuel Lécharny
> <elecharny@gmail.com <ma...@gmail.com>> wrote:
>> 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
>>> <elecharny@gmail.com <ma...@gmail.com>
>>> <mailto:elecharny@gmail.com <ma...@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.lecharny@busit.com <ma...@busit.com>
>>> <mailto:emmanuel.lecharny@busit.com
>>> <ma...@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.lecharny@busit.com <ma...@busit.com>
>> https://www.busit.com/ <https://www.busit.com/>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@mina.apache.org
>> <ma...@mina.apache.org>
>> For additional commands, e-mail: dev-help@mina.apache.org
>> <ma...@mina.apache.org>
>>
--
*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@mina.apache.org
For additional commands, e-mail: dev-help@mina.apache.org
Re: MINA and TLS 1.3 (1ms sleep hack?)
Posted by Guus der Kinderen <gu...@gmail.com>.
Hi everyone,
Apologies for taking a long time to get this tested, but things got
complicated.
Long story short: the issue with TLS v1.3 that I described (needing a 1ms
wait around the TLS handshake) does no longer seem to exist with
commit 7d8930d7f47dc94c4f155b77e074d4384b34c5e4 / tag 2.2.0 of Apache MINA.
... unless I have repeatedly messed up testing, which happens with many
moving parts. I'd love a second pair of eyes confirming this.
As a couple of asides:
I'm not particularly fond of the StartTlsFilter approach, because its
implementation is tied to whatever protocol that you're using. As we're
using XMPP, not LDAP, the StartTlsResponse class comparison didn't fly.
Instead, I resorted to this:
if (writeRequest.getOriginalMessage() instanceof IoBuffer &&
((IoBuffer) writeRequest.getOriginalMessage()).hasArray() &&
new String(((IoBuffer)
writeRequest.getOriginalMessage()).array()).trim().equals("<proceed
xmlns=\"urn:ietf:params:xml:ns:xmpp-tls\"/>") )
(Which probably can be made smarter). Another downside of this is that it
will add a considerable amount of processing to each request if you neglect
to remove the filter after usage.
I'm not sure if Jonathan's suggestion is better, in that respect. I'm not
familiar enough with MINA to understand what is suggested.
Unrelated, since e2e0f2561fe51374091f6a943b462198c62d2b14 the build
requires Maven version 3.8 or later. Why is this? The build seems to run
fine with 3.6.3 - which is the version that is made available through
Ubuntu's 20.04 package manager.
If there is a reason to require a specific version, then maybe it could be
considered to add a Maven Wrapper (mvnw) to the project. If there's no such
requirement, then maybe drop the requirement, as to not throw up unexpected
and unneeded hurdles?
Kind regards,
Guus
On Fri, Apr 1, 2022 at 1:29 PM Jonathan Valliere <jo...@emoten.com>
wrote:
> Another way to do that is to have the SslFilter -> Your Clear Text Control
> Plane Filter
>
> The Control Plane Filter can conditionally wrap a WriteRequest in a
> DisableEncryptWriteRequest. This guarantees that ONLY that message
> bypasses the SslFilter
>
> CONFIDENTIALITY NOTICE: The contents of this email message and any
> attachments are intended solely for the addressee(s) and may contain
> confidential and/or privileged information and may be legally protected
> from disclosure.
>
>
> On Mar 31, 2022 at 4:34:18 PM, Emmanuel Lécharny <el...@gmail.com>
> wrote:
>
>> 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 <elecharny@gmail.com
>>
>> <ma...@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> 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>>
>>
>> >
>>
>> > 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.lecharny@busit.com <ma...@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.lecharny@busit.com https://www.busit.com/
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@mina.apache.org
>> For additional commands, e-mail: dev-help@mina.apache.org
>>
>>