[Bug]: HelloRetryRequest Extension Whitelist Runtime Recheck

[LiD0209]

Contact Details

lxd_dong@bupt.edu.cn

Version

V5.9.1

Description

HelloRetryRequest Extension Whitelist Runtime Recheck



Summary


The recheck result is that wolfSSL, in the tested build, does not strictly
reject an extra unknown extension in HelloRetryRequest.

The test injected a TLS 1.3 HelloRetryRequest containing an unknown extension
type 0xFAFA. wolfSSL did not immediately fail and did not send a fatal alert;
instead, the client remained in WOLFSSL_ERROR_WANT_READ.


Scope


This note concerns the rule that a HelloRetryRequest must not contain
extensions that were not first offered by the client, except for cookie.


RFC 8446 Text



HelloRetryRequest Extension Constraint


RFC 8446 Section 4.1.4, "Hello Retry Request":
https://www.rfc-editor.org/rfc/rfc8446.html#section-4.1.4


The server's extensions MUST contain "supported_versions".
Additionally, it SHOULD contain the minimal set of extensions
necessary for the client to generate a correct ClientHello pair. As
with the ServerHello, a HelloRetryRequest MUST NOT contain any
extensions that were not first offered by the client in its
ClientHello, with the exception of optionally the "cookie" (see
Section 4.2.2) extension.



Extension Response Rule


RFC 8446 Section 4.2, "Extensions":
https://www.rfc-editor.org/rfc/rfc8446.html#section-4.2


Implementations MUST NOT send extension responses if the remote
endpoint did not send the corresponding extension requests, with the
exception of the "cookie" extension in the HelloRetryRequest. Upon
receiving such an extension, an endpoint MUST abort the handshake
with an "unsupported_extension" alert.



wolfSSL Source Evidence



Parse Entry


HelloRetryRequest extensions eventually enter TLSX_Parse() from
tls13.c:


if (args->totalExtSz > 0 && IsAtLeastTLSv1_3(ssl->version)) {
ret = TLSX_Parse(ssl, input + args->idx, args->totalExtSz,
*extMsgType, NULL);



Known Extension Message Constraints


For known extensions such as cookie, wolfSSL does perform message-type
constraints; see tls.c:


if (msgType != client_hello &&
msgType != hello_retry_request) {
return EXT_NOT_ALLOWED;
}



Unknown Extension Handling


The key generic branch is in tls.c:


default:
WOLFSSL_MSG("Unknown TLS extension type");


This branch does not return an error or send an alert. It only logs the
unknown extension and continues parsing.


Additional HRR Consistency Check


wolfSSL also checks whether HRR causes a meaningful ClientHello change; see
tls13.c:


if (!ssl->options.hrrSentKeyShare
#ifdef WOLFSSL_SEND_HRR_COOKIE
&& !ssl->options.hrrSentCookie
#endif
) {
SendAlert(ssl, alert_fatal, illegal_parameter);
return EXT_MISSING;
}


This check is useful, but it does not replace the strict requirement to reject
extra unknown HRR extensions.


Runtime Reproduction


Test program: test_tls13_ext_whitelist_269_271.c
Runtime log: runtime_269_271_whitelist_check.log

Constructed input:


static const unsigned char hrrUnknownExt[] = {
...
0xfa, 0xfa, 0x00, 0x00
};


The HRR keeps valid supported_versions and key_share, then adds an unknown
extension type 0xFAFA.

Key result:


=== HRR-like: HRR + unknown extension ===
result: pending (want io), lastErr=2
alert.last_tx: level=-1 code=-1
alert.last_rx: level=-1 code=-1


Meaning:


• no immediate fatal error,
• no fatal alert,
• the client remains in WOLFSSL_ERROR_WANT_READ.
  

Conclusion


When an extra unknown extension is added to HelloRetryRequest, wolfSSL does
not immediately reject it in the tested build. This is inconsistent with the
strict HRR extension whitelist rule in RFC 8446.

Reproduction steps

No response

Relevant log output

[cpsource]

Took a look — this is already fixed and regression-tested on master by PR #10186 (merged 2026-04-13). The V5.9.1 build the reporter tested predates that fix; current HEAD aborts with unsupported_extension as RFC 8446 §4.1.4 + §4.2 require. PR #10186 also shipped test_tls13_unknown_ext_rejected in tests/api/test_tls13.c covering this exact HelloRetryRequest path.

Below: detailed analysis, an external standalone reproducer, and a BEFORE/AFTER harness that demonstrates the flip by synthetically reverting PR #10186's TLSX_Parse() default: block.

---

The bug

A reporter on wolfSSL V5.9.1 observed that injecting a TLS 1.3
HelloRetryRequest carrying an unknown extension 0xFAFA produced
no fatal alert and no immediate error: the client logged
Unknown TLS extension type and remained in
WOLFSSL_ERROR_WANT_READ. RFC 8446 §4.1.4 says an HRR MUST NOT
contain extensions the client did not first offer (with the sole
exception of cookie); §4.2 says the client MUST abort with an
unsupported_extension alert.

Upstream status

Checked on 2026-04-27 with gh:

• Issue opened 2026-04-27 by LiD0209 (Li Xiangdong); 0 comments,
  no assignee, label bug. Reporter stated wolfSSL version V5.9.1.
• gh pr list --repo wolfSSL/wolfssl --state all --search "10320" →
  no PRs reference this issue number directly.
• gh search issues --repo wolfSSL/wolfssl --include-prs "10320" →
  the issue itself plus two unrelated 2024 PRs. Two sibling issues
  filed by the same reporter on the same day:
  • [Bug]: Client Certificate Extensions Offered-List Inconsistency #10319 — Client Certificate Extensions Offered-List Inconsistency
  • [Bug]: ServerHello Extension Whitelist Runtime Recheck #10321 — ServerHello Extension Whitelist Runtime Recheck (reviewed
    separately; same root cause and same upstream fix as this issue)
• Keyword scan: PR Error out in case of unknown extensions in response message in TLS 1.3 #10186 "Error out in case of unknown
  extensions in response message in TLS 1.3" by Frauschi, merged
  to master 2026-04-13 (commit 043413996). This is the redo of
  PR Error out in case of unknown extensions in response message in TLS 1.3 #9909 (initially reverted in PR revert PR 9909 #9944 because it incorrectly
  failed on GREASE in NewSessionTicket).
• PR Error out in case of unknown extensions in response message in TLS 1.3 #10186 also shipped a dedicated regression test for this
  exact case: test_tls13_unknown_ext_rejected in
  tests/api/test_tls13.c. Its hand-crafted message is an HRR with
  an unknown extension 0xFABC, walked through test_memio to
  the client; the test asserts
  wolfSSL_get_error() == UNSUPPORTED_EXTENSION and that the
  client transmits the fatal alert record on the wire.

Conclusion: this issue is already fixed and tested on master.
PR #10186 is present in current HEAD (6074a2dbe Merge pull request #10308..., 2026-04-24). The reporter ran V5.9.1, which
predates the fix.

Root cause (under V5.9.1, pre-fix)

TLSX_Parse() in src/tls.c had a default: branch that simply
logged unknown extension types without rejecting them. From PR
#10186's pre-fix snapshot (V5.9.1):

default:
    WOLFSSL_MSG("Unknown TLS extension type");
}

There was no message-type-aware rejection. RFC 8446 §4.1.4 / §4.2
say unsupported_extension MUST fire when an HRR (or ServerHello /
EncryptedExtensions / Certificate) carries an extension the client
did not advertise.

How master fixes it (PR #10186)

In current src/tls.c (around TLSX_Parse() line 17993) the
default: branch now reads:

default:
    WOLFSSL_MSG("Unknown TLS extension type");
#if defined(WOLFSSL_TLS13)
    /* RFC 8446 Sec. 4.2: a TLS 1.3 client MUST abort with an
     * unsupported_extension alert ... */
    if (IsAtLeastTLSv1_3(ssl->version) &&
            (msgType == server_hello ||
             msgType == hello_retry_request ||
             msgType == encrypted_extensions ||
             msgType == certificate)) {
        SendAlert((WOLFSSL*)ssl, alert_fatal, unsupported_extension);
        WOLFSSL_ERROR_VERBOSE(UNSUPPORTED_EXTENSION);
        return UNSUPPORTED_EXTENSION;
    }
#endif
}

The set { server_hello, hello_retry_request, encrypted_extensions, certificate } is exactly the message types whose extensions are
responses to the ClientHello — the scope §4.2 governs.
certificate_request and new_session_ticket are excluded
deliberately, because they are server-initiated payloads and per
RFC 8701 (GREASE) the server may legitimately stuff unknown values
in them. cookie is a known type with its own handler, so it does
not reach the default: branch — its message-type constraints are
enforced separately at tls.c:17423.

What this review adds

PR #10186 already shipped test_tls13_unknown_ext_rejected for
the HRR path — the same path this issue is about. Master is
therefore both fixed and regression-tested. This review provides:

1. A standalone reproducer (issue-10320-test.c) outside the
   tests/api framework. It injects an HRR (with the RFC 8446
   §4.1.3 random sentinel) carrying unknown extension 0xFAFA via
   custom IO callbacks, then asserts
   wolfSSL_get_error() == UNSUPPORTED_EXTENSION (-429).
2. A synthetic-revert patch (issue-10320.patch, -23 lines) —
   identical to the one used in the issue-10321 review — that
   removes PR Error out in case of unknown extensions in response message in TLS 1.3 #10186's default: block, restoring the pre-fix
   behaviour.
3. A harness (test.sh) that applies the revert (BEFORE,
   expect FAIL — bug returns), then removes it (AFTER, expect PASS
   — master fix in place). This proves PR Error out in case of unknown extensions in response message in TLS 1.3 #10186's lines are what
   make the difference for the HRR case.

This is not a fix-forward review. There is nothing on master that
needs changing for the reporter's specific scenario. The artefact
is documentary: an external reproducer plus a reversible knob that
lets a reviewer verify PR #10186's effect without touching the
in-tree test framework.

Caveats and risks

• Scope of the fix: PR Error out in case of unknown extensions in response message in TLS 1.3 #10186 covers server_hello,
  hello_retry_request, encrypted_extensions, and certificate.
  This issue (HRR) is one of the four in scope and is regression-
  tested upstream. The sibling issue [Bug]: Client Certificate Extensions Offered-List Inconsistency #10319
  (certificate_request) is intentionally excluded from PR Error out in case of unknown extensions in response message in TLS 1.3 #10186's
  scope and is a separate question.
• GREASE compatibility: PR Error out in case of unknown extensions in response message in TLS 1.3 #10186's first attempt (PR Error out in case of unknown extensions in response message in TLS 1.3 #9909) was
  reverted because it broke GREASE in NewSessionTicket. The
  current scoping (only the four "response" message types) is the
  fix for that regression.
• Build-config guards: the master fix is gated on
  WOLFSSL_TLS13. Non-TLS-1.3 builds are unchanged.
• Reproducer caveats: the reproducer relies on the
  supported_versions extension being parsed before 0xFAFA so
  that IsAtLeastTLSv1_3(ssl->version) is true when the unknown
  handler fires. The wire bytes here put supported_versions first
  (matching PR Error out in case of unknown extensions in response message in TLS 1.3 #10186's own test), so this is satisfied.

Tests to add

PR #10186 already added test_tls13_unknown_ext_rejected covering
this exact case. No new in-tree test is needed for this issue. The
companion issue-10321 review noted that a sibling test for the
ServerHello path would be useful; in contrast, the HRR path is
already covered.

Files touched

• No source files on master need to change.
• issue-10320.patch is a synthetic revert of PR Error out in case of unknown extensions in response message in TLS 1.3 #10186's
  default: block, used only by the harness to demonstrate
  BEFORE/AFTER on a master tree.

Appendix — end-to-end verification

issue-10320-test.c:

1. Calls wolfSSL_Init, builds a client WOLFSSL_CTX with
   wolfTLSv1_3_client_method(), sets VERIFY_NONE (no CA needed —
   the handshake aborts before certificate validation).
2. Wires up custom recv_cb and send_cb via
   wolfSSL_CTX_SetIO{Recv,Send}. send_cb discards the client's
   ClientHello bytes; recv_cb feeds a 59-byte hand-crafted HRR.
3. The injected HRR carries:
   • legacy_version = 0x0303,
   • HRR random sentinel 0xCF, 0x21, 0xAD, 0x74, …, 0x33, 0x9C
     (RFC 8446 §4.1.3) so the message is recognised as HRR rather
     than a regular ServerHello,
   • session_id_len = 0, cipher_suite = 0x1301
     (TLS_AES_128_GCM_SHA256), compression = 0,
   • extensions_length = 10,
   • supported_versions (0x002b, body 0x0304),
   • unknown 0xFAFA with zero-length value.
4. wolfSSL_connect() is invoked. The parser walks
   supported_versions first — this sets the negotiated version to
   TLS 1.3 — then encounters 0xFAFA.
5. On master, TLSX_Parse()'s default: block sees
   IsAtLeastTLSv1_3(ssl->version) && msgType == hello_retry_request, sends a fatal unsupported_extension
   alert, and returns UNSUPPORTED_EXTENSION (-429).
   wolfSSL_get_error() returns -429; the test prints PASS.
6. With the revert applied, the unknown extension is silently
   logged and parsing continues. The client falls through to a
   later check that requires either a sent key_share or cookie and
   returns EXT_MISSING (-428) — a different downstream symptom
   from the reporter's WANT_READ (-2), but the same root defect:
   RFC 8446 §4.1.4 / §4.2 were not enforced at the HRR extension
   level. The test prints FAIL.

Observed results

Scenario	Revert applied (BEFORE)	Master (AFTER)
HRR with unknown 0xFAFA, custom IO	FAIL — wolfSSL_connect ret=-1 err=-428 (EXT_MISSING; unknown ext silently accepted)	PASS — wolfSSL_connect ret=-1 err=-429 (UNSUPPORTED_EXTENSION; client aborted per §4.1.4 + §4.2)

The BEFORE/AFTER distinction proves the lines added by PR #10186
to TLSX_Parse()'s default: branch are the difference between
the V5.9.1-style behaviour (silent accept, fail downstream) and the
master behaviour (immediate unsupported_extension alert).

Running the test harness

test.sh alongside this README automates the BEFORE/AFTER
verification. From this directory:

./test.sh

What it does, in order:

1. Resets src/tls.c via git checkout and asserts the master
   marker for PR Error out in case of unknown extensions in response message in TLS 1.3 #10186 is present.
2. Runs ./configure --enable-harden-tls --enable-tls13.
3. Builds wolfSSL and the reproducer.
4. BEFORE: applies issue-10320.patch (synthetic revert) and
   rebuilds; runs the reproducer; expects FAIL.
5. AFTER: removes the revert via git checkout and rebuilds;
   runs the reproducer; expects PASS.
6. Prints a colored summary.
7. On exit, restores the tree (trap).

Exit status: 0 only when BEFORE FAILs and AFTER PASSes.

---

issue-10320.patch — synthetic revert of PR #10186 (-23 lines), used only by the harness

diff --git a/src/tls.c b/src/tls.c
index c60826121..6806b51d5 100644
--- a/src/tls.c
+++ b/src/tls.c
@@ -17991,29 +17991,6 @@ int TLSX_Parse(WOLFSSL* ssl, const byte* input, word16 length, byte msgType,
 #endif
             default:
                 WOLFSSL_MSG("Unknown TLS extension type");
-#if defined(WOLFSSL_TLS13)
-                /* RFC 8446 Sec. 4.2: a TLS 1.3 client MUST abort with an
-                 * unsupported_extension alert when it receives an extension
-                 * "response" that was not advertised in the ClientHello. The
-                 * rule applies only to messages whose extensions are responses
-                 * to the ClientHello: ServerHello, HelloRetryRequest,
-                 * EncryptedExtensions and Certificate.
-                 *
-                 * Extensions in CertificateRequest and NewSessionTicket are
-                 * independent server-initiated payloads, not responses, and
-                 * per RFC 8701 (GREASE) the server MAY include unknown
-                 * (GREASE) extension types there which the client MUST treat
-                 * like any other unknown value (i.e. ignore them). */
-                if (IsAtLeastTLSv1_3(ssl->version) &&
-                        (msgType == server_hello ||
-                         msgType == hello_retry_request ||
-                         msgType == encrypted_extensions ||
-                         msgType == certificate)) {
-                    SendAlert((WOLFSSL*)ssl, alert_fatal, unsupported_extension);
-                    WOLFSSL_ERROR_VERBOSE(UNSUPPORTED_EXTENSION);
-                    return UNSUPPORTED_EXTENSION;
-                }
-#endif
         }
 
         /* offset should be updated here! */

issue-10320-test.c — standalone TLS 1.3 client; injects HRR with unknown 0xFAFA

/* issue-10320-test.c
 *
 * Reproducer for wolfSSL issue #10320:
 *   "[Bug]: HelloRetryRequest Extension Whitelist Runtime Recheck"
 *
 * Sets up a TLS 1.3 client with custom I/O callbacks. The recv
 * callback feeds a hand-crafted HelloRetryRequest carrying an extra
 * unknown extension type 0xFAFA (after the mandatory
 * supported_versions). RFC 8446 Section 4.1.4 + Section 4.2 say the
 * client MUST abort the handshake with an unsupported_extension
 * alert when an HRR carries an extension the client did not advertise
 * (and which is not the cookie extension).
 *
 * The injected message uses the HelloRetryRequest random sentinel
 * defined by RFC 8446 Section 4.1.3 ("CF 21 AD 74 ...") so the
 * server_hello-shaped record is interpreted as an HRR.
 *
 * Behaviour:
 *   - On current master (PR #10186 in place, merged 2026-04-13)
 *     wolfSSL_connect returns -1 with wolfSSL_get_error() ==
 *     UNSUPPORTED_EXTENSION (-429); the test prints PASS and exits 0.
 *   - With PR #10186's default-case block reverted (issue-10320.patch)
 *     the parser logs "Unknown TLS extension type" and continues,
 *     then returns a different error class downstream; the test
 *     prints FAIL and exits 1.
 *
 * The harness (test.sh) applies the revert patch in BEFORE and removes
 * it in AFTER, then verifies the BEFORE FAIL / AFTER PASS contract.
 */

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

#include <wolfssl/options.h>
#include <wolfssl/ssl.h>
#include <wolfssl/error-ssl.h>

/* Hand-crafted HelloRetryRequest carrying an unknown extension 0xFAFA.
 *
 * Layout:
 *   TLS record header: type=handshake(0x16), version=TLS1.2(0x0303), len=54
 *   Handshake header : type=server_hello(0x02), len=50 (0x000032)
 *   ServerHello body :
 *     legacy_version  : 0x0303 (TLS 1.2 compat)
 *     random          : the RFC 8446 4.1.3 HRR sentinel
 *     session_id_len  : 0
 *     cipher_suite    : 0x1301 (TLS_AES_128_GCM_SHA256)
 *     compression     : 0x00 (null)
 *     extensions_len  : 10 (0x000a)
 *     extension #1    : supported_versions (0x002b), len 2, body 0x0304
 *     extension #2    : unknown 0xFAFA, len 0
 */
static const unsigned char hrr_unknown_ext[] = {
    /* TLS record header */
    0x16, 0x03, 0x03, 0x00, 0x36,
    /* Handshake header: ServerHello (0x02), len = 50 */
    0x02, 0x00, 0x00, 0x32,
    /* legacy_version: TLS 1.2 */
    0x03, 0x03,
    /* HelloRetryRequest random sentinel (RFC 8446 4.1.3) */
    0xcf, 0x21, 0xad, 0x74, 0xe5, 0x9a, 0x61, 0x11,
    0xbe, 0x1d, 0x8c, 0x02, 0x1e, 0x65, 0xb8, 0x91,
    0xc2, 0xa2, 0x11, 0x16, 0x7a, 0xbb, 0x8c, 0x5e,
    0x07, 0x9e, 0x09, 0xe2, 0xc8, 0xa8, 0x33, 0x9c,
    /* session_id_len = 0 */
    0x00,
    /* cipher_suite = TLS_AES_128_GCM_SHA256 */
    0x13, 0x01,
    /* compression_method = null */
    0x00,
    /* extensions_length = 10 */
    0x00, 0x0a,
    /* extension 1: supported_versions (0x002b), len 2, body 0x0304 */
    0x00, 0x2b, 0x00, 0x02, 0x03, 0x04,
    /* extension 2: unknown type 0xFAFA, zero-length value */
    0xfa, 0xfa, 0x00, 0x00
};

static int hrr_pos = 0;
static int client_out_len = 0;
static char client_out_buf[16384];

static int recv_cb(WOLFSSL* ssl, char* buf, int sz, void* ctx)
{
    int avail;
    int n;
    (void)ssl; (void)ctx;
    avail = (int)sizeof(hrr_unknown_ext) - hrr_pos;
    if (avail <= 0)
        return WOLFSSL_CBIO_ERR_WANT_READ;
    n = (avail < sz) ? avail : sz;
    memcpy(buf, hrr_unknown_ext + hrr_pos, (size_t)n);
    hrr_pos += n;
    return n;
}

static int send_cb(WOLFSSL* ssl, char* buf, int sz, void* ctx)
{
    (void)ssl; (void)ctx;
    if (client_out_len + sz > (int)sizeof(client_out_buf))
        return WOLFSSL_CBIO_ERR_WANT_WRITE;
    memcpy(client_out_buf + client_out_len, buf, (size_t)sz);
    client_out_len += sz;
    return sz;
}

int main(int argc, char** argv)
{
    int          rc = 1;
    WOLFSSL_CTX* ctx = NULL;
    WOLFSSL*     ssl = NULL;
    int          ret;
    int          err;

    (void)argc; (void)argv;

    wolfSSL_Init();

    ctx = wolfSSL_CTX_new(wolfTLSv1_3_client_method());
    if (ctx == NULL) {
        fprintf(stderr, "ctx alloc failed\n");
        goto out;
    }
    wolfSSL_CTX_set_verify(ctx, WOLFSSL_VERIFY_NONE, NULL);
    wolfSSL_CTX_SetIORecv(ctx, recv_cb);
    wolfSSL_CTX_SetIOSend(ctx, send_cb);

    ssl = wolfSSL_new(ctx);
    if (ssl == NULL) {
        fprintf(stderr, "ssl alloc failed\n");
        goto out;
    }

    /* wolfSSL_connect serialises a ClientHello via send_cb, then tries
     * to read the server's response from recv_cb, which feeds the
     * hand-crafted HRR. The parser walks supported_versions first
     * (sets ssl->version to TLS 1.3), then encounters 0xFAFA. */
    ret = wolfSSL_connect(ssl);
    err = wolfSSL_get_error(ssl, ret);

    printf("wolfSSL_connect ret=%d err=%d\n", ret, err);

    if (ret != WOLFSSL_SUCCESS &&
        err == WC_NO_ERR_TRACE(UNSUPPORTED_EXTENSION)) {
        printf("PASS  client rejected unknown HRR extension "
               "(err=UNSUPPORTED_EXTENSION, RFC 8446 4.1.4 + 4.2 obeyed)\n");
        rc = 0;
    }
    else if (err == WOLFSSL_ERROR_WANT_READ) {
        printf("FAIL  unknown HRR extension silently accepted; "
               "client kept waiting (err=WANT_READ -2). "
               "This is the V5.9.1 symptom the reporter saw: "
               "RFC 8446 4.1.4 violated.\n");
        rc = 1;
    }
    else if (err == WC_NO_ERR_TRACE(EXT_MISSING)) {
        printf("FAIL  unknown HRR extension silently accepted; "
               "client failed later on required-extension check "
               "(err=EXT_MISSING -428). "
               "Different downstream symptom than the reporter's WANT_READ, "
               "but same root defect: RFC 8446 4.1.4 violated.\n");
        rc = 1;
    }
    else {
        printf("FAIL  unexpected error class (err=%d); "
               "expected UNSUPPORTED_EXTENSION on a fixed master\n", err);
        rc = 1;
    }

out:
    if (ssl != NULL) wolfSSL_free(ssl);
    if (ctx != NULL) wolfSSL_CTX_free(ctx);
    wolfSSL_Cleanup();
    return rc;
}

test.sh — BEFORE (revert applied) / AFTER (master) harness

#!/bin/bash
# Verification harness for wolfSSL issue #10320
# ("HelloRetryRequest Extension Whitelist Runtime Recheck").
#
# This issue is ALREADY FIXED on current master (PR #10186, merged
# 2026-04-13). This harness demonstrates that fact:
#
#   1. Resets src/tls.c to clean (master state, fix in place).
#   2. Configures + builds wolfSSL.
#   3. Builds the standalone reproducer.
#   4. BEFORE pass: APPLIES issue-10320.patch — a synthetic *revert*
#      that deletes PR #10186's default-case unsupported_extension
#      block from TLSX_Parse — and rebuilds. Runs the reproducer.
#      Expected: FAIL (the client logs "Unknown TLS extension type"
#      and waits, matching the V5.9.1 behaviour the reporter saw).
#   5. AFTER pass:  REMOVES the revert (back to clean master) and
#      rebuilds. Runs the reproducer. Expected: PASS (the client
#      aborts with UNSUPPORTED_EXTENSION).
#   6. Restores src/tls.c on exit via trap.
#
# Exit code: 0 iff BEFORE FAILs and AFTER PASSes.
#
# NOTE: in a typical "review-N" harness the patch is the proposed
# *fix*; here the proposed fix is already in master, so the patch
# file is the inverse. The README explains.

set -u

ISSUE_N="10320"
SOURCE_FILE_RELATIVE="src/tls.c"
CFG_FLAGS="--enable-harden-tls --enable-tls13"
# Marker text that PR #10186 introduced. Present on master, absent
# under the synthetic revert.
PATCH_MARKER="RFC 8446 Sec. 4.2: a TLS 1.3 client MUST abort"

HERE="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
REPO="$(cd "$HERE/../.." && pwd)"
cd "$REPO"

TEST_BIN="$HERE/issue-${ISSUE_N}-test"
TEST_SRC="$HERE/issue-${ISSUE_N}-test.c"
PATCH="$HERE/issue-${ISSUE_N}.patch"
LIB_DIR="$REPO/src/.libs"
CFG_LOG="/tmp/wolfssl-cfg-${ISSUE_N}.log"
BLD_LOG="/tmp/wolfssl-build-${ISSUE_N}.log"

red()   { printf '\033[31m%s\033[0m' "$*"; }
green() { printf '\033[32m%s\033[0m' "$*"; }
bold()  { printf '\033[1m%s\033[0m'  "$*"; }
section() { echo; echo "==================== $* ===================="; }

restore_tree() {
    echo
    echo "Restoring tree to pre-script state..."
    git -C "$REPO" checkout -- "$SOURCE_FILE_RELATIVE"
    make -C "$REPO" -j"$(nproc)" >"$BLD_LOG" 2>&1 || true
}
trap restore_tree EXIT

section "Reset $SOURCE_FILE_RELATIVE to clean (master) state"
git -C "$REPO" checkout -- "$SOURCE_FILE_RELATIVE"
if ! grep -q "$PATCH_MARKER" "$REPO/$SOURCE_FILE_RELATIVE"; then
    echo "ERROR: master $SOURCE_FILE_RELATIVE does not contain PR #10186 marker."
    echo "       Either the tree is on an old commit, or PR #10186 was reverted."
    exit 1
fi
echo "  PR #10186 marker present (master clean)"

section "Configure wolfSSL ($CFG_FLAGS)"
./configure $CFG_FLAGS >"$CFG_LOG" 2>&1 || {
    echo "configure failed; tail of $CFG_LOG:"
    tail -30 "$CFG_LOG"
    exit 1
}

section "Build wolfSSL (master)"
make -j"$(nproc)" >"$BLD_LOG" 2>&1 || {
    echo "build failed; tail of $BLD_LOG:"
    tail -40 "$BLD_LOG"
    exit 1
}

section "Build reproducer"
gcc -Wall -Wextra -I"$REPO" -L"$LIB_DIR" \
    "$TEST_SRC" -lwolfssl -lm -o "$TEST_BIN" || {
    echo "reproducer compile failed"
    exit 1
}
echo "  built $TEST_BIN"

run_repro() {
    local label="$1"
    echo; echo "  --- $label ---"
    LD_LIBRARY_PATH="$LIB_DIR" "$TEST_BIN" 2>&1
    local rc=$?
    echo "  reproducer exit = $rc"
    return $rc
}

# ---------- BEFORE: apply revert (re-introduce bug) ----------
section "Apply issue-${ISSUE_N}.patch (synthetic revert of PR #10186) and rebuild"
git -C "$REPO" apply "$PATCH" || {
    echo "git apply failed"
    exit 1
}
if grep -q "$PATCH_MARKER" "$REPO/$SOURCE_FILE_RELATIVE"; then
    echo "ERROR: revert did not remove the marker"
    exit 1
fi
echo "  marker now absent (V5.9.1-equivalent code path)"
make -j"$(nproc)" >"$BLD_LOG" 2>&1 || {
    echo "patched build failed; tail of $BLD_LOG:"
    tail -40 "$BLD_LOG"
    exit 1
}

section "BEFORE (revert applied) — expected: FAIL"
run_repro "HRR + unknown 0xFAFA"
RC_BEF=$?

# ---------- AFTER: remove revert (back to master) ----------
section "Remove revert (back to master) and rebuild"
git -C "$REPO" checkout -- "$SOURCE_FILE_RELATIVE"
if ! grep -q "$PATCH_MARKER" "$REPO/$SOURCE_FILE_RELATIVE"; then
    echo "ERROR: marker still missing after checkout"
    exit 1
fi
echo "  marker present (master fix in place)"
make -j"$(nproc)" >"$BLD_LOG" 2>&1 || {
    echo "rebuild failed; tail of $BLD_LOG:"
    tail -40 "$BLD_LOG"
    exit 1
}

section "AFTER (master, PR #10186 in place) — expected: PASS"
run_repro "HRR + unknown 0xFAFA"
RC_AFT=$?

# ---------- summary ----------
section "Summary"
fmt_expected_fail() { [ "$1" != "0" ] && green "FAIL (expected — bug returns under revert)" || red "PASS (UNEXPECTED — bug not reproduced)"; }
fmt_expected_pass() { [ "$1"  = "0" ] && green "PASS (expected — master fix in place)"  || red "FAIL (UNEXPECTED — fix did not hold)"; }

printf "  BEFORE  HRR+unknown : "; fmt_expected_fail "$RC_BEF"; echo
printf "  AFTER   HRR+unknown : "; fmt_expected_pass "$RC_AFT"; echo

OK=1
[ "$RC_BEF" = "0" ] && OK=0
[ "$RC_AFT" = "0" ] || OK=0

if [ "$OK" = "1" ]; then
    echo; bold "Overall: PR #10186 verified to fix issue #10320 HRR case."; echo
    exit 0
else
    echo; bold "Overall: at least one outcome was UNEXPECTED."; echo
    exit 1
fi

Master is already correct here and has the in-tree regression test. Closing-this-as-already-fixed seems like the right call; happy to follow up otherwise.

[LiD0209]

This PR #10186 looks different from my question

[gasbytes]

Hello @LiD0209,

thanks for the report(s) and for the RFC citations, which are correct.

But from the code I see this.
As you can see, the default: branch does not stop at the log message; immediately after it, there is a tls 1.3 guard that enforces
the RFC 8446 section 4.2.

So an unknown extension in HRR does send a fatal unsupported_extension alert and abort the handshake.

The WANT_READ you observed in the reproducer is more consistent with the injected HRR failing an earlier length/framing check (so TLSX_Parse was never reached for the 0xFAFA extension with msgType == hello_retry_request), rather than the whitelist being unenforced.

Could you re-run with --enable-debug and share the trace? Also please share the reproducer, since the files that you shared don't seem to download correctly from my side.

Thank you!

[LiD0209]

I reran with DEBUG_WOLFSSL enabled and attached the reproducer plus debug trace.

The trace shows that the injected HRR does reach TLSX_Parse. wolfSSL parses supported_versions and key_share, then logs "Unknown TLS extension type" for 0xFAFA, and TLSX_Parse returns 0. No unsupported_extension alert is sent; alert history remains empty.

So the WANT_READ result does not appear to be caused by the HRR failing an earlier length/framing check before TLSX_Parse.

wolfssl_hrr_unknown_ext_recheck_artifacts.zip

[gasbytes]

@LiD0209, thanks for sharing the reproducer, can you also share what configuration and at what commit hash you are building wolfssl from? I forgot to ask it in the previous message.
So that I can fully reproduce the issue locally. thanks.

[LiD0209]

Thanks.

The debug trace I shared was generated from wolfSSL 5.9.0. Unfortunately my local source directory does not contain .git metadata, so I cannot provide a reliable commit hash from that exact tree.

The build configuration was:

cmake -S wolfssl-master -B build/wolfssl-debug-static -G Ninja -DBUILD_SHARED_LIBS=OFF -DWOLFSSL_DEBUG=yes

Environment:

Windows x64
MinGW GCC
Ninja
static libwolfssl.a

Relevant generated options:

WOLFSSL_TLS13 enabled
HAVE_TLS_EXTENSIONS enabled
HAVE_ECC enabled
HAVE_SUPPORTED_CURVES enabled
NO_OLD_TLS enabled
NO_PSK enabled
WOLFSSL_SEND_HRR_COOKIE disabled
DEBUG_WOLFSSL enabled

The reproducer was then linked against:

build/wolfssl-debug-static/libwolfssl.a

I can also rerun it against a fresh wolfSSL git clone if you would like an exact commit hash.

[gasbytes]

@LiD0209

Thanks for the build details, that confirms that v5.9.0 is from before the unknown-extension guard landed in TLSX_Parse's default: branch (src/tls.c:17992-18016 from the latest master), which is why your trace shows Unknown TLS extension type followed by TLSX_Parse, return 0 with no alert.
I rebuilt your both of your files against current master and the HRR + unknown extension case now gives:

  Unknown TLS extension type
  SendAlert: 110 unsupported_extension
  result: fatal, lastErr=-429
  alert.last_tx: level=2 code=110

So the client sends a fatal unsupported_extension (110) and aborts with UNSUPPORTED_EXTENSION (-429), per RFC 8446 section 4.2.

And Yes, please re-run against a fresh clone of master if you can; I'd expect to see the same alert on your side.

Thanks!

[LiD0209]

Thanks, and sorry for taking up your time on this.

I reran the reproducer on my side against a fresh clone of current master:

d7a34d4

I can confirm the current-master behavior you described. For the HRR + unknown extension case, I now get:

result: fatal, lastErr=-429
alert.last_tx: level=2 code=110

and the trace shows:

HelloRetryRequest format
Unknown TLS extension type
SendAlert: 110 unsupported_extension

So current master does correctly reject the extra unknown HelloRetryRequest extension. My earlier result was from the older 5.9.0 tree.

[gasbytes]

@LiD0209

No worries, happy to help!
Glad you are seeing the same results, this fix will be included in the next release (it was initially included in this PR apparently from what I can tell with a quick git blame: #10186)

I'll go ahead and close this issue as solved, thanks again for your work and your reports.