subject:"Trouble with deleghated tasks in MINA 2.2 SSLHandler"

Re: Trouble with deleghated tasks in MINA 2.2 SSLHandler

2022-02-25 Thread Emmanuel Lécharny

Some more insight:

When a exception is thrown while processing a task, the SslEngine do 
close the InputBound (normal). The probelm now that we can't really call 
the receive_loop() again to send back the Alert, because tghis method 
first check the InputBoud status:

protected void receive_loop(final NextFilter next, final IoBuffer 
message) throws SSLException {
System.out.println(toString() + " receive_loop() - source " + 
message);

if (LOGGER.isDebugEnabled()) {
LOGGER.debug("{} receive_loop() - source {}", toString(), 
message);

}

if (mEngine.isInboundDone()) {
System.out.println(toString() + " receive_loop() - closed");
throw new IllegalStateException("closed");
}

so we never send back the alert.

If I do something like :

synchronized protected void throw_pending_error(NextFilter next) 
throws SSLException {

final SSLException e = this.mPendingError;
if (e != null) {
this.mPendingError = null;
this.receive_loop(next, null);  // Call the loop
throw e;
}
}

and:

protected void receive_loop(final NextFilter next, final IoBuffer 
message) throws SSLException {
System.out.println(toString() + " receive_loop() - source " + 
message);

if (LOGGER.isDebugEnabled()) {
LOGGER.debug("{} receive_loop() - source {}", toString(), 
message);

}

if (mEngine.isInboundDone()) {
System.out.println(toString() + " receive_loop() - closed");

switch (mEngine.getHandshakeStatus()) {
case NEED_WRAP:
System.out.println(toString() + " receive_loop() - 
handshake needs wrap, invoking write");

if (LOGGER.isDebugEnabled()) {
LOGGER.debug("{} receive_loop() - handshake 
needs wrap, invoking write", toString());

}
this.write_handshake(next);
break;
}
throw new IllegalStateException("closed");
}

then all come back on its feet. But it's kind of ugly...

On 25/02/2022 14:55, Emmanuel Lécharny wrote:

Hi Jonathan,

we need to close the connection, but the error alert should be sent 
before that. Actually, that should inform the remote peer that there was 
some problem.

What I don't k now ATM is what happens when the SSLEngine fail at some 
task. We should check the HS status, and I guess it will return a 
NEED_WRAP, which will produce the Error Alert, that we should send to 
the remote peer and the close the session.

The receive_loop currently do that:

     protected void receive_loop(final NextFilter next, final IoBuffer 
message) throws SSLException {

     ...
     final SSLEngineResult result = mEngine.unwrap(source.buf(), 
dest.buf());

 ...
     switch (result.getHandshakeStatus()) {
     ...
     case NEED_TASK:
     if (LOGGER.isDebugEnabled()) {
     LOGGER.debug("{} receive_loop() - handshake needs 
task, scheduling", toString());

     }
     this.schedule_task(next);
     break;
     ...
     }
     }

and we get out immediately while the tasks are being executed, which 
leave the HS pending. If one task fails, we need to enter into the loop 
again in order to send the Alert.

On 25/02/2022 13:47, Jonathan Valliere wrote:
If we close the ssl instantly then that’s a point of DDOS.  Relying on 
the idleness timers is important for handling connections in a bad 
state like this example. What’s the exception that unit test is 
supposed to cause?

On Thu, Feb 24, 2022 at 4:56 PM Emmanuel Lécharny > wrote:

    So the idea is first to loop on a NEED_TASK because we may need to 
send

    the alert before closing the connection (but I need to triple check
    that, it's a bit late here, and the day was a bit tough on my brain
    with
    all the bad news...)

    On 24/02/2022 19:18, Emmanuel Lécharny wrote:
 >
 >
 > On 24/02/2022 17:21, Jonathan Valliere wrote:
 >> If we were to elevate this error in another way like an error
    handler
 >> then what would you do? Close the session?
 >
 > Actually, yes, we should send a Error alert (see
 > https://datatracker.ietf.org/doc/html/rfc8446#section-6
    , par. 6.2)
    and
 > close the session.
 >
 >
 >>
 >> On Thu, Feb 24, 2022 at 10:35 AM Emmanuel Lécharny
 >> mailto:elecha...@gmail.com>
    >> wrote:
 >>
 >>     Understood, but here if a task fails, I'm not sure the 
exception

 >>     will be
 >>     handled at all. In the case of a handshake, nothing will be
    written
 >>     back
 >>     to the remote client, AFAICT, so the connection

Re: Trouble with deleghated tasks in MINA 2.2 SSLHandler

2022-02-25 Thread Emmanuel Lécharny


Hi Jonathan,

we need to close the connection, but the error alert should be sent 
before that. Actually, that should inform the remote peer that there was 
some problem.


What I don't k now ATM is what happens when the SSLEngine fail at some 
task. We should check the HS status, and I guess it will return a 
NEED_WRAP, which will produce the Error Alert, that we should send to 
the remote peer and the close the session.


The receive_loop currently do that:

protected void receive_loop(final NextFilter next, final IoBuffer 
message) throws SSLException {

...
final SSLEngineResult result = mEngine.unwrap(source.buf(), 
dest.buf());

...
switch (result.getHandshakeStatus()) {
...
case NEED_TASK:
if (LOGGER.isDebugEnabled()) {
LOGGER.debug("{} receive_loop() - handshake needs 
task, scheduling", toString());

}
this.schedule_task(next);
break;
...
}
}

and we get out immediately while the tasks are being executed, which 
leave the HS pending. If one task fails, we need to enter into the loop 
again in order to send the Alert.


On 25/02/2022 13:47, Jonathan Valliere wrote:
If we close the ssl instantly then that’s a point of DDOS.  Relying on 
the idleness timers is important for handling connections in a bad state 
like this example. What’s the exception that unit test is supposed to cause?


On Thu, Feb 24, 2022 at 4:56 PM Emmanuel Lécharny > wrote:


So the idea is first to loop on a NEED_TASK because we may need to send
the alert before closing the connection (but I need to triple check
that, it's a bit late here, and the day was a bit tough on my brain
with
all the bad news...)

On 24/02/2022 19:18, Emmanuel Lécharny wrote:
 >
 >
 > On 24/02/2022 17:21, Jonathan Valliere wrote:
 >> If we were to elevate this error in another way like an error
handler
 >> then what would you do? Close the session?
 >
 > Actually, yes, we should send a Error alert (see
 > https://datatracker.ietf.org/doc/html/rfc8446#section-6
, par. 6.2)
and
 > close the session.
 >
 >
 >>
 >> On Thu, Feb 24, 2022 at 10:35 AM Emmanuel Lécharny
 >> mailto:elecha...@gmail.com>
>> wrote:
 >>
 >>     Understood, but here if a task fails, I'm not sure the exception
 >>     will be
 >>     handled at all. In the case of a handshake, nothing will be
written
 >>     back
 >>     to the remote client, AFAICT, so the connection will remain
pending
 >>     forever.
 >>
 >>     On 24/02/2022 14:23, Jonathan Valliere wrote:
 >>  > The reason I did this was an ensure the concurrency model
of the
 >>  > filterchain.
 >>  >
 >>  > On Thu, Feb 24, 2022 at 8:22 AM Jonathan Valliere
 >>  > mailto:jon.valli...@emoten.com>
>
 >>      >     wrote:
 >>  >
 >>  >     The pending error is elevated back on either read or
 >> write.  That
 >>  >     way the async error will be thrown on a filter chain
call
 >> stack.
 >>  >
 >>  >     On Wed, Feb 23, 2022 at 11:13 PM Emmanuel Lécharny
 >>  >     mailto:elecha...@gmail.com>
>
 >>     
>  >
 >>  >         Hi Jonathan,
 >>  >
 >>  >         I have a test that isn't happy with the way we
deal with
 >>  >         delegatedTasks
 >>  >         in MINA 2.2 new SSLFilter implementation.
 >>  >
 >>  >         The context:
 >>  >         We do a TLS connection with a wrong certificate, the
 >> test is
 >>  >         expected to
 >>  >         fail, because of this error:
 >>  >
 >>  >         javax.net.ssl.SSLHandshakeException: PKIX path
building
 >>     failed:
 >>  >
 >>  sun.security.provider.certpath.SunCertPathBuilderException:
 >>  >         unable to
 >>  >         find valid certification path to requested target
 >>  >
 >>  >         The problem is that this exception is never
caught, for
 >> some
 >>  >         reason I'm
 >>  >         trying to understand.The SSLHandlerG0.execute_task do
 >>     catch an
 >>  >         exception
 >>  >         and stores it

Re: Trouble with deleghated tasks in MINA 2.2 SSLHandler

2022-02-25 Thread Jonathan Valliere

If we close the ssl instantly then that’s a point of DDOS.  Relying on the
idleness timers is important for handling connections in a bad state like
this example. What’s the exception that unit test is supposed to cause?

On Thu, Feb 24, 2022 at 4:56 PM Emmanuel Lécharny 
wrote:

> So the idea is first to loop on a NEED_TASK because we may need to send
> the alert before closing the connection (but I need to triple check
> that, it's a bit late here, and the day was a bit tough on my brain with
> all the bad news...)
>
> On 24/02/2022 19:18, Emmanuel Lécharny wrote:
> >
> >
> > On 24/02/2022 17:21, Jonathan Valliere wrote:
> >> If we were to elevate this error in another way like an error handler
> >> then what would you do? Close the session?
> >
> > Actually, yes, we should send a Error alert (see
> > https://datatracker.ietf.org/doc/html/rfc8446#section-6, par. 6.2) and
> > close the session.
> >
> >
> >>
> >> On Thu, Feb 24, 2022 at 10:35 AM Emmanuel Lécharny
> >> mailto:elecha...@gmail.com>> wrote:
> >>
> >> Understood, but here if a task fails, I'm not sure the exception
> >> will be
> >> handled at all. In the case of a handshake, nothing will be written
> >> back
> >> to the remote client, AFAICT, so the connection will remain pending
> >> forever.
> >>
> >> On 24/02/2022 14:23, Jonathan Valliere wrote:
> >>  > The reason I did this was an ensure the concurrency model of the
> >>  > filterchain.
> >>  >
> >>  > On Thu, Feb 24, 2022 at 8:22 AM Jonathan Valliere
> >>  > mailto:jon.valli...@emoten.com>
> >> >>
> >> wrote:
> >>  >
> >>  > The pending error is elevated back on either read or
> >> write.  That
> >>  > way the async error will be thrown on a filter chain call
> >> stack.
> >>  >
> >>  > On Wed, Feb 23, 2022 at 11:13 PM Emmanuel Lécharny
> >>  > mailto:elecha...@gmail.com>
> >> >> wrote:
> >>  >
> >>  > Hi Jonathan,
> >>  >
> >>  > I have a test that isn't happy with the way we deal with
> >>  > delegatedTasks
> >>  > in MINA 2.2 new SSLFilter implementation.
> >>  >
> >>  > The context:
> >>  > We do a TLS connection with a wrong certificate, the
> >> test is
> >>  > expected to
> >>  > fail, because of this error:
> >>  >
> >>  > javax.net.ssl.SSLHandshakeException: PKIX path building
> >> failed:
> >>  >
> >>  sun.security.provider.certpath.SunCertPathBuilderException:
> >>  > unable to
> >>  > find valid certification path to requested target
> >>  >
> >>  > The problem is that this exception is never caught, for
> >> some
> >>  > reason I'm
> >>  > trying to understand.The SSLHandlerG0.execute_task do
> >> catch an
> >>  > exception
> >>  > and stores it into the mPendingError variable, but this
> >> is never
> >>  > used.
> >>  >
> >>  > --
> >>  > *Emmanuel Lécharny - CTO* 205 Promenade des Anglais –
> >> 06200 NICE
> >>  >
> >>  <
> https://www.google.com/maps/search/205+Promenade+des+Anglais+%E2%80%93+06200+NICE?entry=gmail=g
> >> <
> https://www.google.com/maps/search/205+Promenade+des+Anglais+%E2%80%93+06200+NICE?entry=gmail=g>>
>
> >>
> >>  > 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.
> >>  >
> >>  > --
> >>  > CONFIDENTIALITY NOTICE: The contents of this email message and
> any
> >>  > attachments are intended solely for the addressee(s) and may
> >> contain
> >>  >

Re: Trouble with deleghated tasks in MINA 2.2 SSLHandler

2022-02-24 Thread Emmanuel Lécharny

So the idea is first to loop on a NEED_TASK because we may need to send 
the alert before closing the connection (but I need to triple check 
that, it's a bit late here, and the day was a bit tough on my brain with 
all the bad news...)


On 24/02/2022 19:18, Emmanuel Lécharny wrote:



On 24/02/2022 17:21, Jonathan Valliere wrote:
If we were to elevate this error in another way like an error handler 
then what would you do? Close the session?


Actually, yes, we should send a Error alert (see 
https://datatracker.ietf.org/doc/html/rfc8446#section-6, par. 6.2) and 
close the session.





On Thu, Feb 24, 2022 at 10:35 AM Emmanuel Lécharny 
mailto:elecha...@gmail.com>> wrote:


    Understood, but here if a task fails, I'm not sure the exception
    will be
    handled at all. In the case of a handshake, nothing will be written
    back
    to the remote client, AFAICT, so the connection will remain pending
    forever.

    On 24/02/2022 14:23, Jonathan Valliere wrote:
 > The reason I did this was an ensure the concurrency model of the
 > filterchain.
 >
 > On Thu, Feb 24, 2022 at 8:22 AM Jonathan Valliere
 > mailto:jon.valli...@emoten.com>
    >>
    wrote:
 >
 >     The pending error is elevated back on either read or 
write.  That
 >     way the async error will be thrown on a filter chain call 
stack.

 >
 >     On Wed, Feb 23, 2022 at 11:13 PM Emmanuel Lécharny
 >     mailto:elecha...@gmail.com>
    >> wrote:
 >
 >         Hi Jonathan,
 >
 >         I have a test that isn't happy with the way we deal with
 >         delegatedTasks
 >         in MINA 2.2 new SSLFilter implementation.
 >
 >         The context:
 >         We do a TLS connection with a wrong certificate, the 
test is

 >         expected to
 >         fail, because of this error:
 >
 >         javax.net.ssl.SSLHandshakeException: PKIX path building
    failed:
 >
 sun.security.provider.certpath.SunCertPathBuilderException:

 >         unable to
 >         find valid certification path to requested target
 >
 >         The problem is that this exception is never caught, for 
some

 >         reason I'm
 >         trying to understand.The SSLHandlerG0.execute_task do
    catch an
 >         exception
 >         and stores it into the mPendingError variable, but this
    is never
 >         used.
 >
 >         --
 >         *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.
 >
 > --
 > 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
    

--
CONFIDENTIALITY NOTICE: The contents of this email message and any 
attachments are intended solely for the addressee(s) and may contain

Re: Trouble with deleghated tasks in MINA 2.2 SSLHandler

2022-02-24 Thread Emmanuel Lécharny





On 24/02/2022 17:21, Jonathan Valliere wrote:
If we were to elevate this error in another way like an error handler 
then what would you do? Close the session?


Actually, yes, we should send a Error alert (see 
https://datatracker.ietf.org/doc/html/rfc8446#section-6, par. 6.2) and 
close the session.





On Thu, Feb 24, 2022 at 10:35 AM Emmanuel Lécharny > wrote:


Understood, but here if a task fails, I'm not sure the exception
will be
handled at all. In the case of a handshake, nothing will be written
back
to the remote client, AFAICT, so the connection will remain pending
forever.

On 24/02/2022 14:23, Jonathan Valliere wrote:
 > The reason I did this was an ensure the concurrency model of the
 > filterchain.
 >
 > On Thu, Feb 24, 2022 at 8:22 AM Jonathan Valliere
 > mailto:jon.valli...@emoten.com>
>>
wrote:
 >
 >     The pending error is elevated back on either read or write.  That
 >     way the async error will be thrown on a filter chain call stack.
 >
 >     On Wed, Feb 23, 2022 at 11:13 PM Emmanuel Lécharny
 >     mailto:elecha...@gmail.com>
>> wrote:
 >
 >         Hi Jonathan,
 >
 >         I have a test that isn't happy with the way we deal with
 >         delegatedTasks
 >         in MINA 2.2 new SSLFilter implementation.
 >
 >         The context:
 >         We do a TLS connection with a wrong certificate, the test is
 >         expected to
 >         fail, because of this error:
 >
 >         javax.net.ssl.SSLHandshakeException: PKIX path building
failed:
 >         sun.security.provider.certpath.SunCertPathBuilderException:
 >         unable to
 >         find valid certification path to requested target
 >
 >         The problem is that this exception is never caught, for some
 >         reason I'm
 >         trying to understand.The SSLHandlerG0.execute_task do
catch an
 >         exception
 >         and stores it into the mPendingError variable, but this
is never
 >         used.
 >
 >         --
 >         *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.
 >
 > --
 > 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


--
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: Trouble with deleghated tasks in MINA 2.2 SSLHandler

2022-02-24 Thread Jonathan Valliere

If we were to elevate this error in another way like an error handler then
what would you do? Close the session?

On Thu, Feb 24, 2022 at 10:35 AM Emmanuel Lécharny 
wrote:

> Understood, but here if a task fails, I'm not sure the exception will be
> handled at all. In the case of a handshake, nothing will be written back
> to the remote client, AFAICT, so the connection will remain pending
> forever.
>
> On 24/02/2022 14:23, Jonathan Valliere wrote:
> > The reason I did this was an ensure the concurrency model of the
> > filterchain.
> >
> > On Thu, Feb 24, 2022 at 8:22 AM Jonathan Valliere
> > mailto:jon.valli...@emoten.com>> wrote:
> >
> > The pending error is elevated back on either read or write.  That
> > way the async error will be thrown on a filter chain call stack.
> >
> > On Wed, Feb 23, 2022 at 11:13 PM Emmanuel Lécharny
> > mailto:elecha...@gmail.com>> wrote:
> >
> > Hi Jonathan,
> >
> > I have a test that isn't happy with the way we deal with
> > delegatedTasks
> > in MINA 2.2 new SSLFilter implementation.
> >
> > The context:
> > We do a TLS connection with a wrong certificate, the test is
> > expected to
> > fail, because of this error:
> >
> > javax.net.ssl.SSLHandshakeException: PKIX path building failed:
> > sun.security.provider.certpath.SunCertPathBuilderException:
> > unable to
> > find valid certification path to requested target
> >
> > The problem is that this exception is never caught, for some
> > reason I'm
> > trying to understand.The SSLHandlerG0.execute_task do catch an
> > exception
> > and stores it into the mPendingError variable, but this is never
> > used.
> >
> > --
> > *Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE
> > <
> https://www.google.com/maps/search/205+Promenade+des+Anglais+%E2%80%93+06200+NICE?entry=gmail=g
> >
> > 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.
> >
> > --
> > 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
>
> --
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: Trouble with deleghated tasks in MINA 2.2 SSLHandler

2022-02-24 Thread Emmanuel Lécharny

Understood, but here if a task fails, I'm not sure the exception will be 
handled at all. In the case of a handshake, nothing will be written back 
to the remote client, AFAICT, so the connection will remain pending forever.


On 24/02/2022 14:23, Jonathan Valliere wrote:
The reason I did this was an ensure the concurrency model of the 
filterchain.


On Thu, Feb 24, 2022 at 8:22 AM Jonathan Valliere 
mailto:jon.valli...@emoten.com>> wrote:


The pending error is elevated back on either read or write.  That
way the async error will be thrown on a filter chain call stack.

On Wed, Feb 23, 2022 at 11:13 PM Emmanuel Lécharny
mailto:elecha...@gmail.com>> wrote:

Hi Jonathan,

I have a test that isn't happy with the way we deal with
delegatedTasks
in MINA 2.2 new SSLFilter implementation.

The context:
We do a TLS connection with a wrong certificate, the test is
expected to
fail, because of this error:

javax.net.ssl.SSLHandshakeException: PKIX path building failed:
sun.security.provider.certpath.SunCertPathBuilderException:
unable to
find valid certification path to requested target

The problem is that this exception is never caught, for some
reason I'm
trying to understand.The SSLHandlerG0.execute_task do catch an
exception
and stores it into the mPendingError variable, but this is never
used.

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

--
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: Trouble with deleghated tasks in MINA 2.2 SSLHandler

Re: Trouble with deleghated tasks in MINA 2.2 SSLHandler

Re: Trouble with deleghated tasks in MINA 2.2 SSLHandler

Re: Trouble with deleghated tasks in MINA 2.2 SSLHandler

Re: Trouble with deleghated tasks in MINA 2.2 SSLHandler

Re: Trouble with deleghated tasks in MINA 2.2 SSLHandler

Re: Trouble with deleghated tasks in MINA 2.2 SSLHandler

7 matches

Site Navigation

Mail list logo

Footer information