From f1c918c26147cb5f970e13fbe427caf4c579e99d Mon Sep 17 00:00:00 2001 From: Jon Shallow Date: Tue, 6 Aug 2024 16:25:02 +0100 Subject: [PATCH] Support DTLS1.3 downgrade when server supports CID With --enable-dtlscid, a client sending a Client Hello to a DLTS1.2 server that supports CID, the server provides the appropriate CID and assumes that CID has been negotiated. However, in the case of MbedTLS, it then rejects packets that do not match its expected CID from the client - as wolfSSL no longer sends the CID as it is not DTLS1.2. https://datatracker.ietf.org/doc/html/rfc9147#section-4 If a Connection ID is negotiated, then it MUST be contained in all datagrams. This fix drops the CID if a Hello Verify Request is received, so the second Client Hello does not include the CID. https://datatracker.ietf.org/doc/html/rfc6347#section-4.2.1 When responding to a HelloVerifyRequest, the client MUST use the same parameter values (version, random, session_id, cipher_suites, compression_method) as it did in the original ClientHello. Dropping the CID extension does not violate this. --- src/internal.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/src/internal.c b/src/internal.c index 6395f0a23..0a35848f4 100644 --- a/src/internal.c +++ b/src/internal.c @@ -29593,6 +29593,10 @@ static int HashSkeData(WOLFSSL* ssl, enum wc_HashType hashType, #ifdef WOLFSSL_DTLS if (ssl->options.dtls) { DtlsMsgPoolReset(ssl); +#ifdef WOLFSSL_DTLS_CID + if (ssl->options.useDtlsCID) + DtlsCIDOnExtensionsParsed(ssl); +#endif /* WOLFSSL_DTLS_CID */ } #endif