From: Pauli Date: Thu, 20 Jul 2023 02:40:49 +0000 (+1000) Subject: quic compliance: 10.2.3 dropping instead of closing X-Git-Tag: openssl-3.2.0-alpha1~307 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=bed20874870da6cf5fa60734964072504563fdac;p=thirdparty%2Fopenssl.git quic compliance: 10.2.3 dropping instead of closing Reviewed-by: Tim Hudson Reviewed-by: Hugo Landau (Merged from https://github.com/openssl/openssl/pull/21429) --- diff --git a/ssl/quic/quic_channel.c b/ssl/quic/quic_channel.c index f6f5b86125c..091b94c0991 100644 --- a/ssl/quic/quic_channel.c +++ b/ssl/quic/quic_channel.c @@ -2026,6 +2026,18 @@ static void ch_rx_handle_packet(QUIC_CHANNEL *ch) * RFC 9000 s. 17.2.2: Clients that receive an Initial packet with a * non-zero Token Length field MUST either discard the packet or * generate a connection error of type PROTOCOL_VIOLATION. + * + * TODO(QUIC): consider the implications of RFC 9000 s. 10.2.3 + * Immediate Close during the Handshake: + * However, at the cost of reducing feedback about + * errors for legitimate peers, some forms of denial of + * service can be made more difficult for an attacker + * if endpoints discard illegal packets rather than + * terminating a connection with CONNECTION_CLOSE. For + * this reason, endpoints MAY discard packets rather + * than immediately close if errors are detected in + * packets that lack authentication. + * I.e. should we drop this packet instead of closing the connection? */ ossl_quic_channel_raise_protocol_error(ch, QUIC_ERR_PROTOCOL_VIOLATION, 0, "client received initial token");