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 <elecha...@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 > >> <elecha...@gmail.com <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 > >> > <jon.valli...@emoten.com <mailto:jon.valli...@emoten.com> > >> <mailto:jon.valli...@emoten.com <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 > >> > <elecha...@gmail.com <mailto:elecha...@gmail.com> > >> <mailto:elecha...@gmail.com <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&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.lecha...@busit.com <mailto:emmanuel.lecha...@busit.com> > >> <mailto:emmanuel.lecha...@busit.com > >> <mailto:emmanuel.lecha...@busit.com>> > >> > https://www.busit.com/ <https://www.busit.com/> > >> <https://www.busit.com/ <https://www.busit.com/>> > >> > > >> > > >> --------------------------------------------------------------------- > >> > To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org > >> <mailto:dev-unsubscr...@mina.apache.org> > >> > <mailto:dev-unsubscr...@mina.apache.org > >> <mailto:dev-unsubscr...@mina.apache.org>> > >> > For additional commands, e-mail: > dev-h...@mina.apache.org > >> <mailto:dev-h...@mina.apache.org> > >> > <mailto:dev-h...@mina.apache.org > >> <mailto: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 <mailto:emmanuel.lecha...@busit.com> > >> https://www.busit.com/ <https://www.busit.com/> > >> > >> > --------------------------------------------------------------------- > >> To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org > >> <mailto:dev-unsubscr...@mina.apache.org> > >> For additional commands, e-mail: dev-h...@mina.apache.org > >> <mailto: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/ > -- 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.
