Re: MINA and TLS 1.3 (1ms sleep hack?)
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("") )
(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
mailto: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
mailto: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
Re: MINA and TLS 1.3 (1ms sleep hack?)
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("") )
(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
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
> 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
>>
>
