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 <[email protected]
<mailto:[email protected]>> 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
>> <[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>> 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
>> > <[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>
>> <mailto:[email protected]
<mailto:[email protected]> <mailto:[email protected]
<mailto:[email protected]>>>>
>> 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
>> > <[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>
>> <mailto:[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>>> 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
>> > [email protected]
<mailto:[email protected]>
<mailto:[email protected]
<mailto:[email protected]>>
>> <mailto:[email protected]
<mailto:[email protected]>
>> <mailto:[email protected]
<mailto:[email protected]>>>
>> > 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:
[email protected]
<mailto:[email protected]>
>> <mailto:[email protected]
<mailto:[email protected]>>
>> > <mailto:[email protected]
<mailto:[email protected]>
>> <mailto:[email protected]
<mailto:[email protected]>>>
>> > For additional commands, e-mail:
[email protected] <mailto:[email protected]>
>> <mailto:[email protected]
<mailto:[email protected]>>
>> > <mailto:[email protected]
<mailto:[email protected]>
>> <mailto:[email protected]
<mailto:[email protected]>>>
>> >
>> > --
>> > 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
>> [email protected] <mailto:[email protected]>
<mailto:[email protected]
<mailto:[email protected]>>
>> https://www.busit.com/ <https://www.busit.com/>
<https://www.busit.com/ <https://www.busit.com/>>
>>
>>
---------------------------------------------------------------------
>> To unsubscribe, e-mail: [email protected]
<mailto:[email protected]>
>> <mailto:[email protected]
<mailto:[email protected]>>
>> For additional commands, e-mail: [email protected]
<mailto:[email protected]>
>> <mailto:[email protected]
<mailto:[email protected]>>
>>
>> --
>> 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
[email protected] <mailto:[email protected]>
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
[email protected] https://www.busit.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
