You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mina.apache.org by Emmanuel Lécharny <el...@gmail.com> on 2022/02/24 04:13:30 UTC
Triuble with deleghated tasks in MINA 2.2 SSLHandler
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.lecharny@busit.com https://www.busit.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@mina.apache.org
For additional commands, e-mail: dev-help@mina.apache.org
Re: Trouble with deleghated tasks in MINA 2.2 SSLHandler
Posted by Emmanuel Lécharny <el...@gmail.com>.
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 <elecharny@gmail.com
>> <ma...@gmail.com>> 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
>> <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
>> >> <elecharny@gmail.com <ma...@gmail.com>
>> <mailto:elecharny@gmail.com <ma...@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
>> >> > <jon.valliere@emoten.com <ma...@emoten.com>
>> <mailto:jon.valliere@emoten.com <ma...@emoten.com>>
>> >> <mailto:jon.valliere@emoten.com
>> <ma...@emoten.com> <mailto:jon.valliere@emoten.com
>> <ma...@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
>> >> > <elecharny@gmail.com <ma...@gmail.com>
>> <mailto:elecharny@gmail.com <ma...@gmail.com>>
>> >> <mailto:elecharny@gmail.com <ma...@gmail.com>
>> <mailto:elecharny@gmail.com <ma...@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&source=g
>> <https://www.google.com/maps/search/205+Promenade+des+Anglais+%E2%80%93+06200+NICE?entry=gmail&source=g>
>>
>> >>
>>
>> <https://www.google.com/maps/search/205+Promenade+des+Anglais+%E2%80%93+06200+NICE?entry=gmail&source=g
>>
>>
>> <https://www.google.com/maps/search/205+Promenade+des+Anglais+%E2%80%93+06200+NICE?entry=gmail&source=g>>>
>>
>>
>> >>
>> >> > T. +33 (0)4 89 97 36 50
>> >> > P. +33 (0)6 08 33 32 61
>> >> > emmanuel.lecharny@busit.com
>> <ma...@busit.com>
>> <mailto:emmanuel.lecharny@busit.com
>> <ma...@busit.com>>
>> >> <mailto:emmanuel.lecharny@busit.com
>> <ma...@busit.com>
>> >> <mailto:emmanuel.lecharny@busit.com
>> <ma...@busit.com>>>
>> >> > https://www.busit.com/ <https://www.busit.com/>
>> <https://www.busit.com/ <https://www.busit.com/>>
>> >> <https://www.busit.com/ <https://www.busit.com/>
>> <https://www.busit.com/ <https://www.busit.com/>>>
>> >> >
>> >> >
>> >>
>>
>> ---------------------------------------------------------------------
>> >> > To unsubscribe, e-mail:
>> dev-unsubscribe@mina.apache.org
>> <ma...@mina.apache.org>
>> >> <mailto:dev-unsubscribe@mina.apache.org
>> <ma...@mina.apache.org>>
>> >> > <mailto:dev-unsubscribe@mina.apache.org
>> <ma...@mina.apache.org>
>> >> <mailto:dev-unsubscribe@mina.apache.org
>> <ma...@mina.apache.org>>>
>> >> > For additional commands, e-mail:
>> dev-help@mina.apache.org <ma...@mina.apache.org>
>> >> <mailto:dev-help@mina.apache.org
>> <ma...@mina.apache.org>>
>> >> > <mailto:dev-help@mina.apache.org
>> <ma...@mina.apache.org>
>> >> <mailto:dev-help@mina.apache.org
>> <ma...@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.lecharny@busit.com <ma...@busit.com>
>> <mailto:emmanuel.lecharny@busit.com
>> <ma...@busit.com>>
>> >> https://www.busit.com/ <https://www.busit.com/>
>> <https://www.busit.com/ <https://www.busit.com/>>
>> >>
>> >>
>> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: dev-unsubscribe@mina.apache.org
>> <ma...@mina.apache.org>
>> >> <mailto:dev-unsubscribe@mina.apache.org
>> <ma...@mina.apache.org>>
>> >> For additional commands, e-mail: dev-help@mina.apache.org
>> <ma...@mina.apache.org>
>> >> <mailto:dev-help@mina.apache.org
>> <ma...@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.lecharny@busit.com <ma...@busit.com>
>> https://www.busit.com/ <https://www.busit.com/>
>>
>> --
>> 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.lecharny@busit.com https://www.busit.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@mina.apache.org
For additional commands, e-mail: dev-help@mina.apache.org
Re: Trouble with deleghated tasks in MINA 2.2 SSLHandler
Posted by Emmanuel Lécharny <el...@gmail.com>.
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 <elecharny@gmail.com
> <ma...@gmail.com>> 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
> <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
> >> <elecharny@gmail.com <ma...@gmail.com>
> <mailto:elecharny@gmail.com <ma...@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
> >> > <jon.valliere@emoten.com <ma...@emoten.com>
> <mailto:jon.valliere@emoten.com <ma...@emoten.com>>
> >> <mailto:jon.valliere@emoten.com
> <ma...@emoten.com> <mailto:jon.valliere@emoten.com
> <ma...@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
> >> > <elecharny@gmail.com <ma...@gmail.com>
> <mailto:elecharny@gmail.com <ma...@gmail.com>>
> >> <mailto:elecharny@gmail.com <ma...@gmail.com>
> <mailto:elecharny@gmail.com <ma...@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&source=g <https://www.google.com/maps/search/205+Promenade+des+Anglais+%E2%80%93+06200+NICE?entry=gmail&source=g>
> >>
> <https://www.google.com/maps/search/205+Promenade+des+Anglais+%E2%80%93+06200+NICE?entry=gmail&source=g
> <https://www.google.com/maps/search/205+Promenade+des+Anglais+%E2%80%93+06200+NICE?entry=gmail&source=g>>>
>
> >>
> >> > T. +33 (0)4 89 97 36 50
> >> > P. +33 (0)6 08 33 32 61
> >> > emmanuel.lecharny@busit.com
> <ma...@busit.com>
> <mailto:emmanuel.lecharny@busit.com
> <ma...@busit.com>>
> >> <mailto:emmanuel.lecharny@busit.com
> <ma...@busit.com>
> >> <mailto:emmanuel.lecharny@busit.com
> <ma...@busit.com>>>
> >> > https://www.busit.com/ <https://www.busit.com/>
> <https://www.busit.com/ <https://www.busit.com/>>
> >> <https://www.busit.com/ <https://www.busit.com/>
> <https://www.busit.com/ <https://www.busit.com/>>>
> >> >
> >> >
> >>
> ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail:
> dev-unsubscribe@mina.apache.org <ma...@mina.apache.org>
> >> <mailto:dev-unsubscribe@mina.apache.org
> <ma...@mina.apache.org>>
> >> > <mailto:dev-unsubscribe@mina.apache.org
> <ma...@mina.apache.org>
> >> <mailto:dev-unsubscribe@mina.apache.org
> <ma...@mina.apache.org>>>
> >> > For additional commands, e-mail:
> dev-help@mina.apache.org <ma...@mina.apache.org>
> >> <mailto:dev-help@mina.apache.org
> <ma...@mina.apache.org>>
> >> > <mailto:dev-help@mina.apache.org
> <ma...@mina.apache.org>
> >> <mailto:dev-help@mina.apache.org
> <ma...@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.lecharny@busit.com <ma...@busit.com>
> <mailto:emmanuel.lecharny@busit.com
> <ma...@busit.com>>
> >> https://www.busit.com/ <https://www.busit.com/>
> <https://www.busit.com/ <https://www.busit.com/>>
> >>
> >>
> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@mina.apache.org
> <ma...@mina.apache.org>
> >> <mailto:dev-unsubscribe@mina.apache.org
> <ma...@mina.apache.org>>
> >> For additional commands, e-mail: dev-help@mina.apache.org
> <ma...@mina.apache.org>
> >> <mailto:dev-help@mina.apache.org
> <ma...@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.lecharny@busit.com <ma...@busit.com>
> https://www.busit.com/ <https://www.busit.com/>
>
> --
> 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.lecharny@busit.com https://www.busit.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@mina.apache.org
For additional commands, e-mail: dev-help@mina.apache.org
Re: Trouble with deleghated tasks in MINA 2.2 SSLHandler
Posted by Jonathan Valliere <jo...@emoten.com>.
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 <el...@gmail.com>
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
> >> <elecharny@gmail.com <ma...@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
> >> > <jon.valliere@emoten.com <ma...@emoten.com>
> >> <mailto:jon.valliere@emoten.com <ma...@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
> >> > <elecharny@gmail.com <ma...@gmail.com>
> >> <mailto:elecharny@gmail.com <ma...@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&source=g
> >> <
> https://www.google.com/maps/search/205+Promenade+des+Anglais+%E2%80%93+06200+NICE?entry=gmail&source=g>>
>
> >>
> >> > T. +33 (0)4 89 97 36 50
> >> > P. +33 (0)6 08 33 32 61
> >> > emmanuel.lecharny@busit.com <ma...@busit.com>
> >> <mailto:emmanuel.lecharny@busit.com
> >> <ma...@busit.com>>
> >> > https://www.busit.com/ <https://www.busit.com/>
> >> <https://www.busit.com/ <https://www.busit.com/>>
> >> >
> >> >
> >> ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: dev-unsubscribe@mina.apache.org
> >> <ma...@mina.apache.org>
> >> > <mailto:dev-unsubscribe@mina.apache.org
> >> <ma...@mina.apache.org>>
> >> > For additional commands, e-mail:
> dev-help@mina.apache.org
> >> <ma...@mina.apache.org>
> >> > <mailto:dev-help@mina.apache.org
> >> <ma...@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.lecharny@busit.com <ma...@busit.com>
> >> https://www.busit.com/ <https://www.busit.com/>
> >>
> >>
> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@mina.apache.org
> >> <ma...@mina.apache.org>
> >> For additional commands, e-mail: dev-help@mina.apache.org
> >> <ma...@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.lecharny@busit.com https://www.busit.com/
>
--
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
Posted by Emmanuel Lécharny <el...@gmail.com>.
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
>> <elecharny@gmail.com <ma...@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
>> > <jon.valliere@emoten.com <ma...@emoten.com>
>> <mailto:jon.valliere@emoten.com <ma...@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
>> > <elecharny@gmail.com <ma...@gmail.com>
>> <mailto:elecharny@gmail.com <ma...@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&source=g
>> <https://www.google.com/maps/search/205+Promenade+des+Anglais+%E2%80%93+06200+NICE?entry=gmail&source=g>>
>>
>> > T. +33 (0)4 89 97 36 50
>> > P. +33 (0)6 08 33 32 61
>> > emmanuel.lecharny@busit.com <ma...@busit.com>
>> <mailto:emmanuel.lecharny@busit.com
>> <ma...@busit.com>>
>> > https://www.busit.com/ <https://www.busit.com/>
>> <https://www.busit.com/ <https://www.busit.com/>>
>> >
>> >
>> ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@mina.apache.org
>> <ma...@mina.apache.org>
>> > <mailto:dev-unsubscribe@mina.apache.org
>> <ma...@mina.apache.org>>
>> > For additional commands, e-mail: dev-help@mina.apache.org
>> <ma...@mina.apache.org>
>> > <mailto:dev-help@mina.apache.org
>> <ma...@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.lecharny@busit.com <ma...@busit.com>
>> https://www.busit.com/ <https://www.busit.com/>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@mina.apache.org
>> <ma...@mina.apache.org>
>> For additional commands, e-mail: dev-help@mina.apache.org
>> <ma...@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.lecharny@busit.com https://www.busit.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@mina.apache.org
For additional commands, e-mail: dev-help@mina.apache.org
Re: Trouble with deleghated tasks in MINA 2.2 SSLHandler
Posted by Emmanuel Lécharny <el...@gmail.com>.
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 <elecharny@gmail.com
> <ma...@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
> > <jon.valliere@emoten.com <ma...@emoten.com>
> <mailto:jon.valliere@emoten.com <ma...@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
> > <elecharny@gmail.com <ma...@gmail.com>
> <mailto:elecharny@gmail.com <ma...@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&source=g <https://www.google.com/maps/search/205+Promenade+des+Anglais+%E2%80%93+06200+NICE?entry=gmail&source=g>>
> > T. +33 (0)4 89 97 36 50
> > P. +33 (0)6 08 33 32 61
> > emmanuel.lecharny@busit.com <ma...@busit.com>
> <mailto:emmanuel.lecharny@busit.com
> <ma...@busit.com>>
> > https://www.busit.com/ <https://www.busit.com/>
> <https://www.busit.com/ <https://www.busit.com/>>
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@mina.apache.org
> <ma...@mina.apache.org>
> > <mailto:dev-unsubscribe@mina.apache.org
> <ma...@mina.apache.org>>
> > For additional commands, e-mail: dev-help@mina.apache.org
> <ma...@mina.apache.org>
> > <mailto:dev-help@mina.apache.org
> <ma...@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.lecharny@busit.com <ma...@busit.com>
> https://www.busit.com/ <https://www.busit.com/>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@mina.apache.org
> <ma...@mina.apache.org>
> For additional commands, e-mail: dev-help@mina.apache.org
> <ma...@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.lecharny@busit.com https://www.busit.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@mina.apache.org
For additional commands, e-mail: dev-help@mina.apache.org
Re: Trouble with deleghated tasks in MINA 2.2 SSLHandler
Posted by Jonathan Valliere <jo...@emoten.com>.
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 <el...@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
> > <jon.valliere@emoten.com <ma...@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
> > <elecharny@gmail.com <ma...@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&source=g
> >
> > T. +33 (0)4 89 97 36 50
> > P. +33 (0)6 08 33 32 61
> > emmanuel.lecharny@busit.com <ma...@busit.com>
> > https://www.busit.com/ <https://www.busit.com/>
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@mina.apache.org
> > <ma...@mina.apache.org>
> > For additional commands, e-mail: dev-help@mina.apache.org
> > <ma...@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.lecharny@busit.com https://www.busit.com/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@mina.apache.org
> For additional commands, e-mail: dev-help@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
Posted by Emmanuel Lécharny <el...@gmail.com>.
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
> <jon.valliere@emoten.com <ma...@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
> <elecharny@gmail.com <ma...@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&source=g>
> T. +33 (0)4 89 97 36 50
> P. +33 (0)6 08 33 32 61
> emmanuel.lecharny@busit.com <ma...@busit.com>
> https://www.busit.com/ <https://www.busit.com/>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@mina.apache.org
> <ma...@mina.apache.org>
> For additional commands, e-mail: dev-help@mina.apache.org
> <ma...@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.lecharny@busit.com https://www.busit.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@mina.apache.org
For additional commands, e-mail: dev-help@mina.apache.org
Re: Triuble with deleghated tasks in MINA 2.2 SSLHandler
Posted by Jonathan Valliere <jo...@emoten.com>.
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 <jo...@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 <el...@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&source=g>
>> T. +33 (0)4 89 97 36 50
>> P. +33 (0)6 08 33 32 61
>> emmanuel.lecharny@busit.com https://www.busit.com/
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@mina.apache.org
>> For additional commands, e-mail: dev-help@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.
Re: Triuble with deleghated tasks in MINA 2.2 SSLHandler
Posted by Jonathan Valliere <jo...@emoten.com>.
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 <el...@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&source=g>
> T. +33 (0)4 89 97 36 50
> P. +33 (0)6 08 33 32 61
> emmanuel.lecharny@busit.com https://www.busit.com/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@mina.apache.org
> For additional commands, e-mail: dev-help@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.