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
>
>
