Re: MINA 2.1 vs MINA 2.2 API differences

[Jonathan Valliere]

 Have you tried printing the entirety of the contents from the Socket
inbound and compare against what is passed into the SSLEngine to make sure
our buffer combination/management isn’t corrupting the stream?

On Jan 28, 2022 at 7:45:29 PM, Emmanuel Lécharny 
wrote:

> Ok, moving forward:
>
> The test does:
>
> - create the server and set the SSLFilter with TLS 1.2
> - create the secured connection (TLSv1.2)
> - write a first message ('test-1')
> - that initiate the HS, then the message is written to the server
> - once the HS is completed, the response is sent (response 1)
> - the SSLSocket session is invalidated on the client side
> - we do a startHandshake on the client
> - the server receives the HS message and send back the HS response
> *** The client never processes the incoming HS message***
> - the client sends the second message
> - the server receives the message and write back the response
> - the server closes the connection
>
>
> I have no idea why the client does not prcoess the second HS message
> received from the server...
>
> On 29/01/2022 00:29, Emmanuel Lécharny wrote:
>
> It should.
>
>
> What is really puzzling is when we set the server to use TLS 1.2 *and*
>
> the client to TLS 1.2, and that fails whatever Java version we use...
>
>
> On 29/01/2022 00:14, Jonathan Valliere wrote:
>
> > Shouldn’t it be downgrading during the handshake?
>
> >
>
> > On Fri, Jan 28, 2022 at 6:12 PM Emmanuel Lécharny 
> > > wrote:
>
> >
>
> > Hi Jonathan,
>
> >
>
> > after a big fight, I finally found that the SslFilterTest was
>
> > failing in
>
> > Mina 2.2 with Java 8 and 11 when the client was not set to use TLS
>
> > V1.3
>
> > (it was set to use "TLS"). Note that the client is a plain SSL
>
> > Socket,
>
> > created by a SSLSocketFactory.
>
> >
>
> > So the combinations that work :
>
> > Java  8 + Client TLSv1.3 + Server TLSv1.2 -> OK
>
> > Java 11 + Client TLSv1.3 + Server TLSv1.2 -> OK
>
> > Java  8 + Client TLSv1.3 + Server TLSv1.3 -> OK
>
> > Java 11 + Client TLSv1.3 + Server TLSv1.3 -> OK
>
> >
>
> > And for those that don't work:
>
> > Java  8 + Client TLSv1.2 + Server TLSv1.2 -> KO
>
> > Java 11 + Client TLSv1.2 + Server TLSv1.2 -> KO
>
> > Java  8 + Client TLSv1.2 + Server TLSv1.3 -> KO
>
> > Java 11 + Client TLSv1.2 + Server TLSv1.3 -> KO
>
> >
>
> > That is a bit problematic as we may have client that aren't using
>
> > TLS 1.3...
>
> >
>
> > On 21/01/2022 16:23, Emmanuel Lécharny wrote:
>
> >  >
>
> >  >
>
> >  > On 21/01/2022 13:23, Jonathan Valliere wrote:
>
> >  >> You can also use the DisableEncryptionWriteRequesf to wrap your
>
> >  >> WriteRequest you want to bypass the SSL filter.
>
> >  >
>
> >  > Yes, but all in all, I think this WriteRequest class should go.
>
> > The
>
> >  > original Attribute was specifically created to bypass the
>
> > SslFilter for
>
> >  > the StartTLS operation, and in retrospect, thatw as a mistake.
>
> >  >
>
> >  > I like the Filter idea.
>
> >  >
>
> >
>
> > -- *Emmanuel Lécharny - CTO* 205 Promenade
>
> >
>
> > <
> https://www.google.com/maps/search/Emmanuel+L%C3%A9charny+-+CTO*+205+Promenade+?entry=gmail&source=g>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
>
> > 
>
> >
>
>
>
> --
> *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/
>

Re: MINA 2.1 vs MINA 2.2 API differences

[Emmanuel Lécharny]

Ok, moving forward:

The test does:

- create the server and set the SSLFilter with TLS 1.2
- create the secured connection (TLSv1.2)
- write a first message ('test-1')
- that initiate the HS, then the message is written to the server
- once the HS is completed, the response is sent (response 1)
- the SSLSocket session is invalidated on the client side
- we do a startHandshake on the client
- the server receives the HS message and send back the HS response
*** The client never processes the incoming HS message***
- the client sends the second message
- the server receives the message and write back the response
- the server closes the connection


I have no idea why the client does not prcoess the second HS message 
received from the server...


On 29/01/2022 00:29, Emmanuel Lécharny wrote:

It should.

What is really puzzling is when we set the server to use TLS 1.2 *and* 
the client to TLS 1.2, and that fails whatever Java version we use...


On 29/01/2022 00:14, Jonathan Valliere wrote:

Shouldn’t it be downgrading during the handshake?

On Fri, Jan 28, 2022 at 6:12 PM Emmanuel Lécharny > wrote:


    Hi Jonathan,

    after a big fight, I finally found that the SslFilterTest was
    failing in
    Mina 2.2 with Java 8 and 11 when the client was not set to use TLS 
V1.3
    (it was set to use "TLS"). Note that the client is a plain SSL 
Socket,

    created by a SSLSocketFactory.

    So the combinations that work :
    Java  8 + Client TLSv1.3 + Server TLSv1.2 -> OK
    Java 11 + Client TLSv1.3 + Server TLSv1.2 -> OK
    Java  8 + Client TLSv1.3 + Server TLSv1.3 -> OK
    Java 11 + Client TLSv1.3 + Server TLSv1.3 -> OK

    And for those that don't work:
    Java  8 + Client TLSv1.2 + Server TLSv1.2 -> KO
    Java 11 + Client TLSv1.2 + Server TLSv1.2 -> KO
    Java  8 + Client TLSv1.2 + Server TLSv1.3 -> KO
    Java 11 + Client TLSv1.2 + Server TLSv1.3 -> KO

    That is a bit problematic as we may have client that aren't using
    TLS 1.3...

    On 21/01/2022 16:23, Emmanuel Lécharny wrote:
 >
 >
 > On 21/01/2022 13:23, Jonathan Valliere wrote:
 >> You can also use the DisableEncryptionWriteRequesf to wrap your
 >> WriteRequest you want to bypass the SSL filter.
 >
 > Yes, but all in all, I think this WriteRequest class should go. 
The

 > original Attribute was specifically created to bypass the
    SslFilter for
 > the StartTLS operation, and in retrospect, thatw as a mistake.
 >
 > I like the Filter idea.
 >

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





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

Re: MINA 2.1 vs MINA 2.2 API differences

[Jonathan Valliere]

🤯

On Fri, Jan 28, 2022 at 6:30 PM Emmanuel Lécharny 
wrote:

> It should.
>
> What is really puzzling is when we set the server to use TLS 1.2 *and*
> the client to TLS 1.2, and that fails whatever Java version we use...
>
> On 29/01/2022 00:14, Jonathan Valliere wrote:
> > Shouldn’t it be downgrading during the handshake?
> >
> > On Fri, Jan 28, 2022 at 6:12 PM Emmanuel Lécharny  > > wrote:
> >
> > Hi Jonathan,
> >
> > after a big fight, I finally found that the SslFilterTest was
> > failing in
> > Mina 2.2 with Java 8 and 11 when the client was not set to use TLS
> V1.3
> > (it was set to use "TLS"). Note that the client is a plain SSL
> Socket,
> > created by a SSLSocketFactory.
> >
> > So the combinations that work :
> > Java  8 + Client TLSv1.3 + Server TLSv1.2 -> OK
> > Java 11 + Client TLSv1.3 + Server TLSv1.2 -> OK
> > Java  8 + Client TLSv1.3 + Server TLSv1.3 -> OK
> > Java 11 + Client TLSv1.3 + Server TLSv1.3 -> OK
> >
> > And for those that don't work:
> > Java  8 + Client TLSv1.2 + Server TLSv1.2 -> KO
> > Java 11 + Client TLSv1.2 + Server TLSv1.2 -> KO
> > Java  8 + Client TLSv1.2 + Server TLSv1.3 -> KO
> > Java 11 + Client TLSv1.2 + Server TLSv1.3 -> KO
> >
> > That is a bit problematic as we may have client that aren't using
> > TLS 1.3...
> >
> > On 21/01/2022 16:23, Emmanuel Lécharny wrote:
> >  >
> >  >
> >  > On 21/01/2022 13:23, Jonathan Valliere wrote:
> >  >> You can also use the DisableEncryptionWriteRequesf to wrap your
> >  >> WriteRequest you want to bypass the SSL filter.
> >  >
> >  > Yes, but all in all, I think this WriteRequest class should go.
> The
> >  > original Attribute was specifically created to bypass the
> > SslFilter for
> >  > the StartTLS operation, and in retrospect, thatw as a mistake.
> >  >
> >  > I like the Filter idea.
> >  >
> >
> > --
> > *Emmanuel Lécharny - CTO* 205 Promenade
> > <
> https://www.google.com/maps/search/Emmanuel+L%C3%A9charny+-+CTO*+205+Promenade+?entry=gmail&source=g
> >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
> > 
> >
>
> --
> *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/
>

Re: MINA 2.1 vs MINA 2.2 API differences

[Emmanuel Lécharny]

It should.

What is really puzzling is when we set the server to use TLS 1.2 *and* 
the client to TLS 1.2, and that fails whatever Java version we use...


On 29/01/2022 00:14, Jonathan Valliere wrote:

Shouldn’t it be downgrading during the handshake?

On Fri, Jan 28, 2022 at 6:12 PM Emmanuel Lécharny > wrote:


Hi Jonathan,

after a big fight, I finally found that the SslFilterTest was
failing in
Mina 2.2 with Java 8 and 11 when the client was not set to use TLS V1.3
(it was set to use "TLS"). Note that the client is a plain SSL Socket,
created by a SSLSocketFactory.

So the combinations that work :
Java  8 + Client TLSv1.3 + Server TLSv1.2 -> OK
Java 11 + Client TLSv1.3 + Server TLSv1.2 -> OK
Java  8 + Client TLSv1.3 + Server TLSv1.3 -> OK
Java 11 + Client TLSv1.3 + Server TLSv1.3 -> OK

And for those that don't work:
Java  8 + Client TLSv1.2 + Server TLSv1.2 -> KO
Java 11 + Client TLSv1.2 + Server TLSv1.2 -> KO
Java  8 + Client TLSv1.2 + Server TLSv1.3 -> KO
Java 11 + Client TLSv1.2 + Server TLSv1.3 -> KO

That is a bit problematic as we may have client that aren't using
TLS 1.3...

On 21/01/2022 16:23, Emmanuel Lécharny wrote:
 >
 >
 > On 21/01/2022 13:23, Jonathan Valliere wrote:
 >> You can also use the DisableEncryptionWriteRequesf to wrap your
 >> WriteRequest you want to bypass the SSL filter.
 >
 > Yes, but all in all, I think this WriteRequest class should go. The
 > original Attribute was specifically created to bypass the
SslFilter for
 > the StartTLS operation, and in retrospect, thatw as a mistake.
 >
 > I like the Filter idea.
 >

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




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

Re: MINA 2.1 vs MINA 2.2 API differences

[Jonathan Valliere]

Shouldn’t it be downgrading during the handshake?

On Fri, Jan 28, 2022 at 6:12 PM Emmanuel Lécharny 
wrote:

> Hi Jonathan,
>
> after a big fight, I finally found that the SslFilterTest was failing in
> Mina 2.2 with Java 8 and 11 when the client was not set to use TLS V1.3
> (it was set to use "TLS"). Note that the client is a plain SSL Socket,
> created by a SSLSocketFactory.
>
> So the combinations that work :
> Java  8 + Client TLSv1.3 + Server TLSv1.2 -> OK
> Java 11 + Client TLSv1.3 + Server TLSv1.2 -> OK
> Java  8 + Client TLSv1.3 + Server TLSv1.3 -> OK
> Java 11 + Client TLSv1.3 + Server TLSv1.3 -> OK
>
> And for those that don't work:
> Java  8 + Client TLSv1.2 + Server TLSv1.2 -> KO
> Java 11 + Client TLSv1.2 + Server TLSv1.2 -> KO
> Java  8 + Client TLSv1.2 + Server TLSv1.3 -> KO
> Java 11 + Client TLSv1.2 + Server TLSv1.3 -> KO
>
> That is a bit problematic as we may have client that aren't using TLS
> 1.3...
>
> On 21/01/2022 16:23, Emmanuel Lécharny wrote:
> >
> >
> > On 21/01/2022 13:23, Jonathan Valliere wrote:
> >> You can also use the DisableEncryptionWriteRequesf to wrap your
> >> WriteRequest you want to bypass the SSL filter.
> >
> > Yes, but all in all, I think this WriteRequest class should go. The
> > original Attribute was specifically created to bypass the SslFilter for
> > the StartTLS operation, and in retrospect, thatw as a mistake.
> >
> > I like the Filter idea.
> >
>
> --
> *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
>
>

Re: MINA 2.1 vs MINA 2.2 API differences

[Emmanuel Lécharny]

Hi Jonathan,

after a big fight, I finally found that the SslFilterTest was failing in 
Mina 2.2 with Java 8 and 11 when the client was not set to use TLS V1.3 
(it was set to use "TLS"). Note that the client is a plain SSL Socket, 
created by a SSLSocketFactory.


So the combinations that work :
Java  8 + Client TLSv1.3 + Server TLSv1.2 -> OK
Java 11 + Client TLSv1.3 + Server TLSv1.2 -> OK
Java  8 + Client TLSv1.3 + Server TLSv1.3 -> OK
Java 11 + Client TLSv1.3 + Server TLSv1.3 -> OK

And for those that don't work:
Java  8 + Client TLSv1.2 + Server TLSv1.2 -> KO
Java 11 + Client TLSv1.2 + Server TLSv1.2 -> KO
Java  8 + Client TLSv1.2 + Server TLSv1.3 -> KO
Java 11 + Client TLSv1.2 + Server TLSv1.3 -> KO

That is a bit problematic as we may have client that aren't using TLS 1.3...

On 21/01/2022 16:23, Emmanuel Lécharny wrote:



On 21/01/2022 13:23, Jonathan Valliere wrote:

You can also use the DisableEncryptionWriteRequesf to wrap your
WriteRequest you want to bypass the SSL filter.


Yes, but all in all, I think this WriteRequest class should go. The 
original Attribute was specifically created to bypass the SslFilter for 
the StartTLS operation, and in retrospect, thatw as a mistake.


I like the Filter idea.



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

Re: MINA 2.1 vs MINA 2.2 API differences

[Emmanuel Lécharny]

On 21/01/2022 13:23, Jonathan Valliere wrote:

You can also use the DisableEncryptionWriteRequesf to wrap your
WriteRequest you want to bypass the SSL filter.


Yes, but all in all, I think this WriteRequest class should go. The 
original Attribute was specifically created to bypass the SslFilter for 
the StartTLS operation, and in retrospect, thatw as a mistake.


I like the Filter idea.

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

Re: MINA 2.1 vs MINA 2.2 API differences

[Jonathan Valliere]

You can also use the DisableEncryptionWriteRequesf to wrap your
WriteRequest you want to bypass the SSL filter.

On Fri, Jan 21, 2022 at 3:58 AM Emmanuel Lécharny 
wrote:

> I have it working. The filter approach is actually the silmpler way to
> deal with the requirement, I don't even have to leverage the crypt
> bypass flag. I just check if the message to be written is the
> StartTlsResponse one, and if so, I 'jump' over the SslFilter:
>
>  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);
>  }
>  }
>
> Note: I set up the SslFilter first in the chain, immediately followed by
> the StartTLS filter:
>
>  chain.addFirst( "startTls", startTlsFilter );
>  chain.addFirst( "sslFilter", sslFilter );
>
> Simple, easy.
>
>
> Thanks Jonathan !
>
> On 20/01/2022 18:22, Emmanuel Lécharny wrote:
> >
> >
> > On 20/01/2022 13:25, Jonathan Valliere wrote:
> >> The old method was unsafe from a concurrency standpoint.  This
> >> switching logic should be in a filter.
> >
> > Agreed. StartTLS is by itself very intrusive and I think it deserves to
> > be made a MINA filter, instead of expecting MINA to be twisted in a way
> > that is not natural.
> >
> > Actually, with such a filter, we wouldn't even require the flag you have
> > added as a substitute for the session attribute.
> >
> > Thanks Jonathan !
> >
>
> --
> *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/
>

Re: MINA 2.1 vs MINA 2.2 API differences

[Emmanuel Lécharny]

I have it working. The filter approach is actually the silmpler way to 
deal with the requirement, I don't even have to leverage the crypt 
bypass flag. I just check if the message to be written is the 
StartTlsResponse one, and if so, I 'jump' over the SslFilter:


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);
}
}

Note: I set up the SslFilter first in the chain, immediately followed by 
the StartTLS filter:


chain.addFirst( "startTls", startTlsFilter );
chain.addFirst( "sslFilter", sslFilter );

Simple, easy.


Thanks Jonathan !

On 20/01/2022 18:22, Emmanuel Lécharny wrote:



On 20/01/2022 13:25, Jonathan Valliere wrote:
The old method was unsafe from a concurrency standpoint.  This 
switching logic should be in a filter.


Agreed. StartTLS is by itself very intrusive and I think it deserves to 
be made a MINA filter, instead of expecting MINA to be twisted in a way 
that is not natural.


Actually, with such a filter, we wouldn't even require the flag you have 
added as a substitute for the session attribute.


Thanks Jonathan !



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

Re: MINA 2.1 vs MINA 2.2 API differences

[Emmanuel Lécharny]

On 20/01/2022 13:25, Jonathan Valliere wrote:
The old method was unsafe from a concurrency standpoint.  This switching 
logic should be in a filter.


Agreed. StartTLS is by itself very intrusive and I think it deserves to 
be made a MINA filter, instead of expecting MINA to be twisted in a way 
that is not natural.


Actually, with such a filter, we wouldn't even require the flag you have 
added as a substitute for the session attribute.


Thanks Jonathan !

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

Re: MINA 2.1 vs MINA 2.2 API differences

[Jonathan Valliere]

The old method was unsafe from a concurrency standpoint.  This switching
logic should be in a filter.

On Thu, Jan 20, 2022 at 1:40 AM Emmanuel Lécharny 
wrote:

>
>
> On 18/01/2022 14:06, Jonathan Valliere wrote:
> > Yes, I added that specifically for anyone who needed that attribute I
> > removed. Unlike that attribute of disable once, this is completely safe
> > to use.
>
> But sadly, it can't be used from the outside.
>
> The typical use from an application PoV is :
>
>  session.getIoSession().write( message );
>
> and it ends with:
>
>  public WriteFuture write(Object message, SocketAddress remoteAddress)
> {
>  ...
>  // Now, we can write the message. First, create a future
>  WriteFuture writeFuture = new DefaultWriteFuture(this);
>  WriteRequest writeRequest = new DefaultWriteRequest(message,
> writeFuture, remoteAddress);
>
>
> That means we should bypass this part, which would require some
> modification in this method.
>
>
>
> >
> > On Tue, Jan 18, 2022 at 3:12 AM Emmanuel Lécharny  > > wrote:
> >
> >
> >
> > On 18/01/2022 05:04, Jonathan Valliere wrote:
> >  > Doesn't the DisableEncryptionWriteRequest get you where you need
> > to go?
> >  > Just wrap the startTLS message and pass upstream into the
> SSLFilter.
> >
> >
> > You mean DisableEncryptWriteRequest, I guess. Yes, that should do the
> > trick !
> >
> > Will test it and tell you...
> >
> > Thanks !
> >
> > --
> > Emmanuel Lécharny
> >
>
> --
> *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
>
>

Re: MINA 2.1 vs MINA 2.2 API differences

[Emmanuel Lécharny]

On 18/01/2022 14:06, Jonathan Valliere wrote:
Yes, I added that specifically for anyone who needed that attribute I 
removed. Unlike that attribute of disable once, this is completely safe 
to use.


But sadly, it can't be used from the outside.

The typical use from an application PoV is :

session.getIoSession().write( message );

and it ends with:

public WriteFuture write(Object message, SocketAddress remoteAddress) {
...
// Now, we can write the message. First, create a future
WriteFuture writeFuture = new DefaultWriteFuture(this);
WriteRequest writeRequest = new DefaultWriteRequest(message, 
writeFuture, remoteAddress);



That means we should bypass this part, which would require some 
modification in this method.






On Tue, Jan 18, 2022 at 3:12 AM Emmanuel Lécharny > wrote:




On 18/01/2022 05:04, Jonathan Valliere wrote:
 > Doesn't the DisableEncryptionWriteRequest get you where you need
to go?
 > Just wrap the startTLS message and pass upstream into the SSLFilter.


You mean DisableEncryptWriteRequest, I guess. Yes, that should do the
trick !

Will test it and tell you...

Thanks !

-- 
Emmanuel Lécharny




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

Re: MINA 2.1 vs MINA 2.2 API differences

[Jonathan Valliere]

Yes, I added that specifically for anyone who needed that attribute I
removed. Unlike that attribute of disable once, this is completely safe to
use.

On Tue, Jan 18, 2022 at 3:12 AM Emmanuel Lécharny 
wrote:

>
>
> On 18/01/2022 05:04, Jonathan Valliere wrote:
> > Doesn't the DisableEncryptionWriteRequest get you where you need to go?
> > Just wrap the startTLS message and pass upstream into the SSLFilter.
>
>
> You mean DisableEncryptWriteRequest, I guess. Yes, that should do the
> trick !
>
> Will test it and tell you...
>
> Thanks !
>
> --
> Emmanuel Lécharny
>

Re: MINA 2.1 vs MINA 2.2 API differences

[Emmanuel Lécharny]

On 18/01/2022 05:04, Jonathan Valliere wrote:
Doesn't the DisableEncryptionWriteRequest get you where you need to go?  
Just wrap the startTLS message and pass upstream into the SSLFilter.



You mean DisableEncryptWriteRequest, I guess. Yes, that should do the 
trick !


Will test it and tell you...

Thanks !

--
Emmanuel Lécharny

-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org

Re: MINA 2.1 vs MINA 2.2 API differences

[Jonathan Valliere]

Doesn't the DisableEncryptionWriteRequest get you where you need to go?
Just wrap the startTLS message and pass upstream into the SSLFilter.

On Mon, Jan 17, 2022 at 10:11 PM Emmanuel Lécharny 
wrote:

>
>
> On 17/01/2022 17:13, Jonathan Valliere wrote:
> > Shouldn’t Directory be able to configure and add the SSLFiler on demand?
>
> Yes, this is done when it receives a startTLS request.
>
> There is a trick though: When the server receives the request, it should
> establish the SSL layer, then send back the StartTLS response *in clear*
>   for the client to start the HS when it receives the response. This is
> the reason we added the DISBALED_ENCRYPPTIPN_ONCE attributeKey in MINA:
>
>  /**
>   * A session attribute key that makes next one write request bypass
>   * this filter (not encrypting the data).  This is a marker attribute,
>   * which means that you can put whatever as its value. ({@link
> Boolean#TRUE}
>   * is preferred.)  The attribute is automatically removed from the
> session
>   * attribute map as soon as {@link IoSession#write(Object)} is
> invoked,
>   * and therefore should be put again if you want to make more messages
>   * bypass this filter.  This is especially useful when you implement
>   * StartTLS.
>   */
>  public static final AttributeKey DISABLE_ENCRYPTION_ONCE = new
> AttributeKey(SslFilter.class, "disableOnce");
>
> Without this flag, we would have potentially faced a race condition
> where we could send the startTLS response * before having established
> fully the SslFilter, and the client would then start the HS before the
> server is ready to process it.
>
> To summarize:
>
> C ---> startTLS request ---> S
>   
>   
> C <--- startTLS response <-- S
> .
> .
> .
> C ---> TLS ClientHELLO   --> S
>   
>  ...
>
>
> As you can see, the way LDAP protocol works make it necessary for MINA
> to be tweaked this way.
>
>
> >
> > It will setup and attempt to start the moment it’s added on the server
> > filterchain.
> >
> > On Mon, Jan 17, 2022 at 11:10 AM Emmanuel Lécharny  > > wrote:
> >
> >
> >
> > On 17/01/2022 16:48, Jonathan Valliere wrote:
> >  > I think that piece of code is trying to move the concern of
> > configuring
> >  > the SSL into a place which doesn’t have enough information about
> the
> >  > state.  The Ciphers can be set when the Filter is created.  If a
> > special
> >  > workflow is needed, you can always extend SSLFilter now which has
> >  > convenient override handlers.
> >
> > Well, I don't think it's necessary in this case.
> >
> > What we need in LDAP Server is the possibility, on demand, to
> establish
> > a crypted session. That means the previous communication was in
> clear,
> > and we ask the server to be ready to handle a HS.
> >
> > That is as simple.
> >
> > Note that in Apache Directory server we have the possibility to
> define
> > the ciphers per configuration, and this is taken into account in the
> > first part of the 'if'.
> >
> > I question the second part as it seems to violate the (LDAP
> > StartTLS) RFC.
> >
> > So bottom line, it's not a MINA issue, but rather a Directory one.
> >
> > --
> > Emmanuel Lécharny
> >
> > --
> > 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.
>
> --
> *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/
>

Re: MINA 2.1 vs MINA 2.2 API differences

[Emmanuel Lécharny]

On 17/01/2022 17:13, Jonathan Valliere wrote:

Shouldn’t Directory be able to configure and add the SSLFiler on demand?


Yes, this is done when it receives a startTLS request.

There is a trick though: When the server receives the request, it should 
establish the SSL layer, then send back the StartTLS response *in clear* 
 for the client to start the HS when it receives the response. This is 
the reason we added the DISBALED_ENCRYPPTIPN_ONCE attributeKey in MINA:


/**
 * A session attribute key that makes next one write request bypass
 * this filter (not encrypting the data).  This is a marker attribute,
 * which means that you can put whatever as its value. ({@link 
Boolean#TRUE}
 * is preferred.)  The attribute is automatically removed from the 
session

 * attribute map as soon as {@link IoSession#write(Object)} is invoked,
 * and therefore should be put again if you want to make more messages
 * bypass this filter.  This is especially useful when you implement
 * StartTLS.
 */
public static final AttributeKey DISABLE_ENCRYPTION_ONCE = new 
AttributeKey(SslFilter.class, "disableOnce");


Without this flag, we would have potentially faced a race condition 
where we could send the startTLS response * before having established 
fully the SslFilter, and the client would then start the HS before the 
server is ready to process it.


To summarize:

C ---> startTLS request ---> S
 
 
C <--- startTLS response <-- S
.
.
.
C ---> TLS ClientHELLO   --> S
 
...


As you can see, the way LDAP protocol works make it necessary for MINA 
to be tweaked this way.





It will setup and attempt to start the moment it’s added on the server 
filterchain.


On Mon, Jan 17, 2022 at 11:10 AM Emmanuel Lécharny > wrote:




On 17/01/2022 16:48, Jonathan Valliere wrote:
 > I think that piece of code is trying to move the concern of
configuring
 > the SSL into a place which doesn’t have enough information about the
 > state.  The Ciphers can be set when the Filter is created.  If a
special
 > workflow is needed, you can always extend SSLFilter now which has
 > convenient override handlers.

Well, I don't think it's necessary in this case.

What we need in LDAP Server is the possibility, on demand, to establish
a crypted session. That means the previous communication was in clear,
and we ask the server to be ready to handle a HS.

That is as simple.

Note that in Apache Directory server we have the possibility to define
the ciphers per configuration, and this is taken into account in the
first part of the 'if'.

I question the second part as it seems to violate the (LDAP
StartTLS) RFC.

So bottom line, it's not a MINA issue, but rather a Directory one.

-- 
Emmanuel Lécharny


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


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

Re: MINA 2.1 vs MINA 2.2 API differences

[Jonathan Valliere]

Shouldn’t Directory be able to configure and add the SSLFiler on demand?

It will setup and attempt to start the moment it’s added on the server
filterchain.

On Mon, Jan 17, 2022 at 11:10 AM Emmanuel Lécharny 
wrote:

>
>
> On 17/01/2022 16:48, Jonathan Valliere wrote:
> > I think that piece of code is trying to move the concern of configuring
> > the SSL into a place which doesn’t have enough information about the
> > state.  The Ciphers can be set when the Filter is created.  If a special
> > workflow is needed, you can always extend SSLFilter now which has
> > convenient override handlers.
>
> Well, I don't think it's necessary in this case.
>
> What we need in LDAP Server is the possibility, on demand, to establish
> a crypted session. That means the previous communication was in clear,
> and we ask the server to be ready to handle a HS.
>
> That is as simple.
>
> Note that in Apache Directory server we have the possibility to define
> the ciphers per configuration, and this is taken into account in the
> first part of the 'if'.
>
> I question the second part as it seems to violate the (LDAP StartTLS) RFC.
>
> So bottom line, it's not a MINA issue, but rather a Directory one.
>
> --
> Emmanuel Lécharny
>
-- 
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.

Re: MINA 2.1 vs MINA 2.2 API differences

[Emmanuel Lécharny]

On 17/01/2022 16:48, Jonathan Valliere wrote:
I think that piece of code is trying to move the concern of configuring 
the SSL into a place which doesn’t have enough information about the 
state.  The Ciphers can be set when the Filter is created.  If a special 
workflow is needed, you can always extend SSLFilter now which has 
convenient override handlers.


Well, I don't think it's necessary in this case.

What we need in LDAP Server is the possibility, on demand, to establish 
a crypted session. That means the previous communication was in clear, 
and we ask the server to be ready to handle a HS.


That is as simple.

Note that in Apache Directory server we have the possibility to define 
the ciphers per configuration, and this is taken into account in the 
first part of the 'if'.


I question the second part as it seems to violate the (LDAP StartTLS) RFC.

So bottom line, it's not a MINA issue, but rather a Directory one.

--
Emmanuel Lécharny

-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org

Re: MINA 2.1 vs MINA 2.2 API differences

[Jonathan Valliere]

I think that piece of code is trying to move the concern of configuring the
SSL into a place which doesn’t have enough information about the state.
The Ciphers can be set when the Filter is created.  If a special workflow
is needed, you can always extend SSLFilter now which has convenient
override handlers.

Maintaining clear understanding of which code and which flow has the
responsibility of setting up the SSL is important for maintainability and
testing.

On Mon, Jan 17, 2022 at 10:30 AM Emmanuel Lécharny 
wrote:

> Some more difference:
>
> In order to be able to programatically start a SSL session, we need the
> startSsl/stopTls methods in the SslFilter.
>
> I'm trying to figure out if this is not a superfluous addition in MINA.
> The directory server code looks like that:
>
> public void handleExtendedOperation( LdapSession session,
> ExtendedRequest req ) throws Exception
> {
>  IoFilterChain chain = session.getIoSession().getFilterChain();
>  SslFilter sslFilter = ( SslFilter ) chain.get( "sslFilter" );
>
>  if ( sslFilter == null )
>  {
>  // Establish the ssl filter
>  }
>  else
>  {
>  // Be sure we disable SSLV3
>  sslFilter.setEnabledProtocols( new String[]
>  { "TLSv1", "TLSv1.1", "TLSv1.2" } );
>  sslFilter.startSsl( session.getIoSession() ); // What for ???
>  }
>
> Actually, there is no reason to redo a handshake if the SSLFilter has
> already been established, and I think we mis-understood the RFC, which
> says:
>
> "3.1.1.  StartTLS Request Sequencing
>
> A client may send the StartTLS extended request at any time after
> establishing an LDAP session, except:
>
>- when TLS is currently established on the session,"
>
> So I guess this missing method is a no problem.
>
>
> On 17/01/2022 15:50, Jonathan Valliere wrote:
> > AFAIK the usage you described is fully compatible with the process I
> > outlined in my previous email.
> >
> > You have access to the peer certificate after the handshake is done or
> are
> > you needing access earlier?
> >
> > On Mon, Jan 17, 2022 at 9:40 AM Emmanuel Lécharny 
> > wrote:
> >
> >>
> >>
> >> On 17/01/2022 15:09, Jonathan Valliere wrote:
> >>> Emmanuel,
> >>>
> >>> The access of the SslSession was moved into an AttributeKey which is
> set
> >>> BEFORE the SECURED event is fired.  This was done to help improve best
> >>> practices for when this object is accessible.  Your application can
> >> listen
> >>> for the SECURED event then read the AttributeKey to obtain the
> >> SslSession.
> >>>
> >>>
> >>
> https://github.com/apache/mina/blob/660ab2375b4b47b5ebe86226c92f3138be4c96e8/mina-core/src/main/java/org/apache/mina/filter/ssl/SSLFilter.java#L56
> >>
> >> My second mail clarified my requirement. I need to have access to the
> >> SslSession instance, to grab the client certificate from it.
> >>
> >> --
> >> Emmanuel Lécharny
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
> >> For additional commands, e-mail: dev-h...@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.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
>
> --
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.

Re: MINA 2.1 vs MINA 2.2 API differences

[Emmanuel Lécharny]

Some more difference:

In order to be able to programatically start a SSL session, we need the 
startSsl/stopTls methods in the SslFilter.


I'm trying to figure out if this is not a superfluous addition in MINA. 
The directory server code looks like that:


public void handleExtendedOperation( LdapSession session, 
ExtendedRequest req ) throws Exception

{
IoFilterChain chain = session.getIoSession().getFilterChain();
SslFilter sslFilter = ( SslFilter ) chain.get( "sslFilter" );

if ( sslFilter == null )
{
// Establish the ssl filter
}
else
{
// Be sure we disable SSLV3
sslFilter.setEnabledProtocols( new String[]
{ "TLSv1", "TLSv1.1", "TLSv1.2" } );
sslFilter.startSsl( session.getIoSession() ); // What for ???
}

Actually, there is no reason to redo a handshake if the SSLFilter has 
already been established, and I think we mis-understood the RFC, which says:


"3.1.1.  StartTLS Request Sequencing

   A client may send the StartTLS extended request at any time after
   establishing an LDAP session, except:

  - when TLS is currently established on the session,"

So I guess this missing method is a no problem.


On 17/01/2022 15:50, Jonathan Valliere wrote:

AFAIK the usage you described is fully compatible with the process I
outlined in my previous email.

You have access to the peer certificate after the handshake is done or are
you needing access earlier?

On Mon, Jan 17, 2022 at 9:40 AM Emmanuel Lécharny 
wrote:




On 17/01/2022 15:09, Jonathan Valliere wrote:

Emmanuel,

The access of the SslSession was moved into an AttributeKey which is set
BEFORE the SECURED event is fired.  This was done to help improve best
practices for when this object is accessible.  Your application can

listen

for the SECURED event then read the AttributeKey to obtain the

SslSession.




https://github.com/apache/mina/blob/660ab2375b4b47b5ebe86226c92f3138be4c96e8/mina-core/src/main/java/org/apache/mina/filter/ssl/SSLFilter.java#L56

My second mail clarified my requirement. I need to have access to the
SslSession instance, to grab the client certificate from it.

--
Emmanuel Lécharny

-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@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.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

Re: MINA 2.1 vs MINA 2.2 API differences

[Emmanuel Lécharny]

On 17/01/2022 15:50, Jonathan Valliere wrote:

AFAIK the usage you described is fully compatible with the process I
outlined in my previous email.


Ah, crap, totally missed this one. I was focusing of the fact the 
SSL_SESSION attributeKey was missing ;-)


yeah:

session.setAttribute(SslFilter.SSL_SECURED, sslEngine.getSession())

that does the trick.



You have access to the peer certificate after the handshake is done or are
you needing access earlier?


Obviously after the HS is done :-)

--
Emmanuel Lécharny

-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org

Re: MINA 2.1 vs MINA 2.2 API differences

[Jonathan Valliere]

AFAIK the usage you described is fully compatible with the process I
outlined in my previous email.

You have access to the peer certificate after the handshake is done or are
you needing access earlier?

On Mon, Jan 17, 2022 at 9:40 AM Emmanuel Lécharny 
wrote:

>
>
> On 17/01/2022 15:09, Jonathan Valliere wrote:
> > Emmanuel,
> >
> > The access of the SslSession was moved into an AttributeKey which is set
> > BEFORE the SECURED event is fired.  This was done to help improve best
> > practices for when this object is accessible.  Your application can
> listen
> > for the SECURED event then read the AttributeKey to obtain the
> SslSession.
> >
> >
> https://github.com/apache/mina/blob/660ab2375b4b47b5ebe86226c92f3138be4c96e8/mina-core/src/main/java/org/apache/mina/filter/ssl/SSLFilter.java#L56
>
> My second mail clarified my requirement. I need to have access to the
> SslSession instance, to grab the client certificate from it.
>
> --
> Emmanuel Lécharny
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
> For additional commands, e-mail: dev-h...@mina.apache.org
>
>

Re: MINA 2.1 vs MINA 2.2 API differences

[Emmanuel Lécharny]

On 17/01/2022 15:09, Jonathan Valliere wrote:

Emmanuel,

The access of the SslSession was moved into an AttributeKey which is set
BEFORE the SECURED event is fired.  This was done to help improve best
practices for when this object is accessible.  Your application can listen
for the SECURED event then read the AttributeKey to obtain the SslSession.

https://github.com/apache/mina/blob/660ab2375b4b47b5ebe86226c92f3138be4c96e8/mina-core/src/main/java/org/apache/mina/filter/ssl/SSLFilter.java#L56


My second mail clarified my requirement. I need to have access to the 
SslSession instance, to grab the client certificate from it.


--
Emmanuel Lécharny

-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org

Re: MINA 2.1 vs MINA 2.2 API differences

[Jonathan Valliere]

Emmanuel,

The access of the SslSession was moved into an AttributeKey which is set
BEFORE the SECURED event is fired.  This was done to help improve best
practices for when this object is accessible.  Your application can listen
for the SECURED event then read the AttributeKey to obtain the SslSession.

https://github.com/apache/mina/blob/660ab2375b4b47b5ebe86226c92f3138be4c96e8/mina-core/src/main/java/org/apache/mina/filter/ssl/SSLFilter.java#L56

Since the state of SslSession is tied to actually connecting, it is really
only valid from a flow process after the first handshake is completed.  The
AttributeKey also doubles in meaning that, if present, the session is
secured.

The option to manually set UseClientMode was removed to help prevent
accidental incorrect usage.  Is there a specific reason you would like that
back?

On Mon, Jan 17, 2022 at 8:49 AM Emmanuel Lécharny 
wrote:

>
>
> On 17/01/2022 14:17, Emmanuel Lécharny wrote:
> > Hi Jonathan,
> >
> > I'm testing MINA 2.2 in Apache Directory, and there are two API
> > differences :
> >
> > - The SslSession is not anymore present in the IoSession attributes. Is
> > there any reason for the removal ?
>
> To clarify, we need this information in the Directory server:
>
>  /**
>   * {@inheritDoc}
>   */
>  public byte[] evaluateResponse( byte[] initialResponse ) throws
> SaslException
>  {
>  try
>  {
>  SSLSession sslSession = ( SSLSession )
> getLdapSession().getIoSession().getAttribute( SslFilter.SSL_SESSION );
>  Certificate[] peerCertificates =
> sslSession.getPeerCertificates();
>
>  if ( null == peerCertificates || 1 > peerCertificates.length )
>  {
>  throw new SaslException( "No peer certificate provided
> - cancel bind." );
>  }
>
>  getLdapSession().setCoreSession( authenticate(
> peerCertificates[0] ) );
>  state = NegotiationState.COMPLETED;
>  }
>
> --
> Emmanuel Lécharny
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
> For additional commands, e-mail: dev-h...@mina.apache.org
>
>

Re: MINA 2.1 vs MINA 2.2 API differences

[Emmanuel Lécharny]

On 17/01/2022 14:17, Emmanuel Lécharny wrote:

Hi Jonathan,

I'm testing MINA 2.2 in Apache Directory, and there are two API 
differences :


- The SslSession is not anymore present in the IoSession attributes. Is 
there any reason for the removal ?


To clarify, we need this information in the Directory server:

/**
 * {@inheritDoc}
 */
public byte[] evaluateResponse( byte[] initialResponse ) throws 
SaslException

{
try
{
SSLSession sslSession = ( SSLSession ) 
getLdapSession().getIoSession().getAttribute( SslFilter.SSL_SESSION );
Certificate[] peerCertificates = 
sslSession.getPeerCertificates();


if ( null == peerCertificates || 1 > peerCertificates.length )
{
throw new SaslException( "No peer certificate provided 
- cancel bind." );

}

getLdapSession().setCoreSession( authenticate( 
peerCertificates[0] ) );

state = NegotiationState.COMPLETED;
}

--
Emmanuel Lécharny

-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org

MINA 2.1 vs MINA 2.2 API differences

[Emmanuel Lécharny]

Hi Jonathan,

I'm testing MINA 2.2 in Apache Directory, and there are two API 
differences :


- The SslSession is not anymore present in the IoSession attributes. Is 
there any reason for the removal ?


- The SslFilter.setUseClientMode(boolean) has also been removed. I 
understand that we can immediately deduce if the caller is a client or a 
server, depending on the IoService in use (IoAcceptor or IoConnector). 
Can we still keep the method available, but deprecated, to ease the API 
migration?


Many thanks !

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