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 <jon.valli...@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 <elecha...@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 <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> 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.lecha...@busit.com <mailto:emmanuel.lecha...@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 https://www.busit.com/
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
>> For additional commands, e-mail: dev-h...@mina.apache.org
>>
>>
