[PATCH 2 of 8] QUIC: added check to prevent packet output with discarded keys

[Sergey Kandaurov]

> On 18 Sep 2023, at 11:08, Roman Arutyunyan <arut at nginx.com> wrote:
> 
> Hi,
> 
> On Thu, Sep 07, 2023 at 07:13:54PM +0400, Sergey Kandaurov wrote:
>> # HG changeset patch
>> # User Sergey Kandaurov <pluknet at nginx.com>
>> # Date 1694041352 -14400
>> #      Thu Sep 07 03:02:32 2023 +0400
>> # Node ID 02c86eac80c907adb7790c79ac6892afabcee5f4
>> # Parent  be1862a28fd8575a88475215ccfce995e392dfab
>> QUIC: added check to prevent packet output with discarded keys.
>> 
>> In addition to triggering alert, it ensures that such packets won't be sent.
>> 
>> With the previous change that marks server keys as discarded by zeroing the
>> key lengh, it is now an error to send packets with discarded keys.  OpenSSL
>> based stacks tolerate such behaviour because key length isn't used in packet
>> protection, but BoringSSL will raise the UNSUPPORTED_KEY_SIZE cipher error.
>> It won't be possible to use discarded keys with reused crypto contexts.
>> 
>> diff --git a/src/event/quic/ngx_event_quic_output.c b/src/event/quic/ngx_event_quic_output.c
>> --- a/src/event/quic/ngx_event_quic_output.c
>> +++ b/src/event/quic/ngx_event_quic_output.c
>> @@ -519,6 +519,21 @@ ngx_quic_output_packet(ngx_connection_t 
>> 
>>     qc = ngx_quic_get_connection(c);
>> 
>> +    if (!ngx_quic_keys_available(qc->keys, ctx->level, 1)) {
>> +        ngx_log_error(NGX_LOG_ALERT, c->log, 0, "quic %s write keys discarded",
>> +                      ngx_quic_level_name(ctx->level));
>> +
>> +        while (!ngx_queue_empty(&ctx->frames)) {
>> +            q = ngx_queue_head(&ctx->frames);
>> +            ngx_queue_remove(q);
>> +
>> +            f = ngx_queue_data(q, ngx_quic_frame_t, queue);
>> +            ngx_quic_free_frame(c, f);
>> +        }
>> +
>> +        return 0;
>> +    }
>> +
>>     ngx_quic_init_packet(c, ctx, &pkt, qc->path);
>> 
>>     min_payload = ngx_quic_payload_size(&pkt, min);
> 
> In ngx_quic_create_datagrams(), before calling ngx_quic_output_packet(),
> ngx_quic_generate_ack() generates ACK frames for the current level.
> Maybe it's better to add this block before generating ACKs?  Otherwise we
> generate an ACK and then immediately remove it.

This patch is a catch all measure against using non-existing keys,
which should normally not happen, hence the alert log level.
Frames are removed, because there's no more sense to keep them
in the queue (and to avoid repetitive alerts).

The actual fix is the next patch in the series.

>  This technically would require
> a similar block in ngx_quic_create_segments(),

This creates complexity for no reason, I would rather not.

> although the application level
> should normally never be in a discarded key situation.

Agree.
Although discarding all available keys is added in this series as part of
connection tear down, it should not affect ngx_quic_create_segments().

> 
> It's true however that the next patch partially solves the issue by not
> generating the last handshake ACK.  

Indeed, that patch appears incomplete, I will remove it.
What you suggest about ngx_quic_generate_ack() seems to be
the right direction, see below.

> That however does not seem to be a complete
> solution since there could be previous ACKs.  

There should not be previous ACKs sitting in ctx->frames because
Initial and Handshake packets involved in establishing TLS handshake
are acknowledged immediately.

Though, I see other ways to generate ACKs, which my patch didn't
address.  For example, client may send out of order packets, or
multiple packets with holes in packets numbers, resulting in too
many ACK ranges.  In both cases, ACKs are generated directly in
ngx_quic_ack_packet(), without posting a push event.  So, I added
keys availability check to ngx_quic_ack_packet() as a common place.

# HG changeset patch
# User Sergey Kandaurov <pluknet at nginx.com>
# Date 1697110950 -14400
#      Thu Oct 12 15:42:30 2023 +0400
# Node ID 4586b12e6a73811dc60fa78e6c0a82af36ea2957
# Parent  96af5e3a2a3a4e6b11f0dc084c9a60d836de70c4
QUIC: prevented generating ACK frames with discarded keys.

Previously it was possible to generate ACK frames using formally discarded
protection keys, in particular, when acknowledging a client Handshake packet
used to complete the TLS handshake and to discard handshake protection keys.
As it happens late in packet processing, it could be possible to generate ACK
frames after the keys were already discarded.

ACK frames are generated from ngx_quic_ack_packet(), either using a posted
push event, which envolves ngx_quic_generate_ack() as a part of the final
packet assembling, or directly in ngx_quic_ack_packet(), such as when there
is no room to add a new ACK range or when the received packet is out of order.
The added keys availability check is used to avoid generating late ACK frames
in both cases.

diff --git a/src/event/quic/ngx_event_quic_ack.c b/src/event/quic/ngx_event_quic_ack.c
--- a/src/event/quic/ngx_event_quic_ack.c
+++ b/src/event/quic/ngx_event_quic_ack.c
@@ -907,6 +907,10 @@ ngx_quic_ack_packet(ngx_connection_t *c,
                    " nranges:%ui", pkt->pn, (int64_t) ctx->largest_range,
                    ctx->first_range, ctx->nranges);
 
+    if (!ngx_quic_keys_available(qc->keys, ctx->level, 1)) {
+        return NGX_OK;
+    }
+
     prev_pending = ctx->pending_ack;
 
     if (pkt->need_ack) {

-- 
Sergey Kandaurov