[Bug]: ServerHello Extension Whitelist Runtime Recheck

[LiD0209]

Contact Details

lxd_dong@bupt.edu.cn

Version

V5.9.1

Description

ServerHello Extension Whitelist Runtime Recheck



Summary


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

The test injected a ServerHello 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 TLS 1.3 ServerHello must only include the
extensions required to establish the cryptographic context and negotiate the
protocol version.


RFC 8446 Text



ServerHello Whitelist Requirement


RFC 8446 Section 4.1.3, "Server Hello":
https://www.rfc-editor.org/rfc/rfc8446.html#section-4.1.3


extensions: A list of extensions. The ServerHello MUST only include
extensions which are required to establish the cryptographic
context and negotiate the protocol version. All TLS 1.3
ServerHello messages MUST contain the "supported_versions"
extension. Current ServerHello messages additionally contain
either the "pre_shared_key" extension or the "key_share"
extension, or both (when using a PSK with (EC)DHE key
establishment). Other extensions (see Section 4.2) are sent
separately in the EncryptedExtensions message.



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.



Alert Definition


RFC 8446 Section 6.2, "Error Alerts":
https://www.rfc-editor.org/rfc/rfc8446.html#section-6.2


unsupported_extension: Sent by endpoints receiving any handshake
message containing an extension known to be prohibited for
inclusion in the given handshake message, or including any
extensions in a ServerHello or Certificate not first offered in
the corresponding ClientHello or CertificateRequest.



wolfSSL Source Evidence



Parse Entry


TLS 1.3 ServerHello 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 pre_shared_key, wolfSSL does perform
message-type constraints; see tls.c:


if (msgType != client_hello &&
msgType != server_hello) {
WOLFSSL_ERROR_VERBOSE(EXT_NOT_ALLOWED);
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.


Alert Mapping Note


Even when wolfSSL reaches EXT_NOT_ALLOWED, the error is generally translated
to illegal_parameter, not unsupported_extension; see
internal.c. However, the issue in
this runtime test occurs earlier: the unknown extension does not enter a
rejection path at all.


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 shUnknownExt[] = {
...
0xfa, 0xfa, 0x00, 0x02, 0x03, 0x04
};


The test injects unknown extension type 0xFAFA into a TLS 1.3
ServerHello, while keeping the key-share setup controlled to avoid confusing
the result with a key-share mismatch.

Key result:


=== ServerHello-like: ServerHello + unknown extension ===
wolfSSL_UseKeyShare(secp256r1)=1
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 TLS 1.3 ServerHello, wolfSSL does
not immediately reject it in the tested build. This is inconsistent with the
strict ServerHello extension whitelist semantics in RFC 8446.

Reproduction steps

No response

Relevant log output

[cpsource]

Took a look — this is already fixed 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.2 requires.

Below: detailed analysis, a ServerHello-specific reproducer (PR #10186 included a HelloRetryRequest regression test but no equivalent for ServerHello), 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
ServerHello 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.2 requires the client to
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 "10321" →
  no PRs reference this issue number directly.
• gh search issues --repo wolfSSL/wolfssl --include-prs "10321" →
  the issue plus an unrelated 2024 PR. Two sibling issues filed by
  the same reporter the same day:
  • [Bug]: Client Certificate Extensions Offered-List Inconsistency #10319 — Client Certificate Extensions Offered-List Inconsistency
  • [Bug]: HelloRetryRequest Extension Whitelist Runtime Recheck #10320 — HelloRetryRequest Extension Whitelist Runtime Recheck
• 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).

Conclusion: this issue is already fixed 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.2 says
unsupported_extension MUST fire when a ServerHello (or HRR /
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.

What this review adds

PR #10186 already shipped a regression test
(test_tls13_unknown_ext_rejected in tests/api/test_tls13.c) that
covers the HelloRetryRequest path. There is no analogous test
on master that exercises the ServerHello path specifically
(though both paths run through the same TLSX_Parse() default:
branch, so the existing test exercises the same code).

This review provides:

1. A standalone reproducer (issue-10321-test.c) that injects
   a TLS 1.3 ServerHello with an unknown extension 0xFAFA via
   custom IO callbacks and asserts
   wolfSSL_get_error() == UNSUPPORTED_EXTENSION (-429).
2. A synthetic-revert patch (issue-10321.patch, -23 lines)
   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 ServerHello 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: a reproducer plus a reversible knob that lets a
reviewer verify PR #10186's effect without leaving the workflow.

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.
  Issue [Bug]: HelloRetryRequest Extension Whitelist Runtime Recheck #10320 (sibling, same reporter, same day) addresses
  HRR specifically — also covered by the same default: block.
  Issue [Bug]: Client Certificate Extensions Offered-List Inconsistency #10319 addresses certificate_request, which is
  intentionally excluded above 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 standalone reproducer needs no CA
  bundle (it relies on parsing aborting before certificate
  validation). If extension order is changed so 0xFAFA appears
  before supported_versions, the parser may fail differently —
  the reproducer relies on supported_versions being parsed first
  so that IsAtLeastTLSv1_3(ssl->version) is true when the unknown
  handler fires.

Tests to add

PR #10186 already includes test_tls13_unknown_ext_rejected for
HRR. A natural follow-up would be a sibling test
test_tls13_unknown_ext_rejected_sh for the ServerHello path,
mirroring issue-10321-test.c inside the test_memio framework.
This is suggested follow-up, not required by §4.2 — the
existing HRR test exercises the same default: branch.

Files touched

• No source files on master need to change.
• issue-10321.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-10321-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 ServerHello.
3. The injected ServerHello carries:
   • legacy_version = 0x0303, 32 non-magic random bytes,
     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 == server_hello,
   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 reaches a later check
   that requires key_share and returns EXT_MISSING (-428) — a
   different downstream symptom from the reporter's WANT_READ
   (-2), but the same root defect: RFC 8446 §4.2 was not enforced
   at the ServerHello extension level. The test prints FAIL.

Observed results

Scenario	Revert applied (BEFORE)	Master (AFTER)
ServerHello 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.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-10321.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-10321.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-10321-test.c — standalone TLS 1.3 client; injects ServerHello with unknown 0xFAFA

/* issue-10321-test.c
 *
 * Reproducer for wolfSSL issue #10321:
 *   "[Bug]: ServerHello Extension Whitelist Runtime Recheck"
 *
 * Sets up a TLS 1.3 client with custom I/O callbacks. The recv
 * callback feeds a hand-crafted ServerHello carrying an extra
 * unknown extension type 0xFAFA (after the mandatory
 * supported_versions). RFC 8446 Section 4.2 says the client MUST
 * abort the handshake with an unsupported_extension alert when it
 * receives an extension it did not advertise.
 *
 * 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-10321.patch)
 *     the parser logs "Unknown TLS extension type" and continues,
 *     then waits for further input; wolfSSL_get_error() ==
 *     WOLFSSL_ERROR_WANT_READ (-2). 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 ServerHello 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          : 32 bytes (non-magic; not the 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
 *
 * The unknown extension is placed second so that mandatory parsing
 * of supported_versions runs first and the client has set
 * ssl->version = TLSv1.3 by the time the unknown handler fires.
 */
static const unsigned char sh_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,
    /* random: 32 non-magic bytes */
    0xa1, 0xa2, 0xa3, 0xa4, 0xa5, 0xa6, 0xa7, 0xa8,
    0xa9, 0xaa, 0xab, 0xac, 0xad, 0xae, 0xaf, 0xb0,
    0xb1, 0xb2, 0xb3, 0xb4, 0xb5, 0xb6, 0xb7, 0xb8,
    0xb9, 0xba, 0xbb, 0xbc, 0xbd, 0xbe, 0xbf, 0xc0,
    /* 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 sh_pos = 0;        /* read cursor into sh_unknown_ext   */
static int client_out_len = 0; /* sink for the client's ClientHello */
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(sh_unknown_ext) - sh_pos;
    if (avail <= 0)
        return WOLFSSL_CBIO_ERR_WANT_READ;
    n = (avail < sz) ? avail : sz;
    memcpy(buf, sh_unknown_ext + sh_pos, (size_t)n);
    sh_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;
    }

    /* Caller does not present a CA bundle; parsing must abort before
     * the client gets to certificate validation, so this is fine. */
    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;
    }

    /* Drive the handshake. wolfSSL_connect serialises a ClientHello
     * into client_out_buf via send_cb, then tries to read the server's
     * response from recv_cb, which feeds sh_unknown_ext. The parser
     * walks supported_versions, 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 ServerHello extension "
               "(err=UNSUPPORTED_EXTENSION, RFC 8446 4.2 obeyed)\n");
        rc = 0;
    }
    else if (err == WOLFSSL_ERROR_WANT_READ) {
        printf("FAIL  unknown ServerHello extension silently accepted; "
               "client kept waiting (err=WANT_READ -2). "
               "This is the V5.9.1 symptom the reporter saw: "
               "RFC 8446 4.2 violated.\n");
        rc = 1;
    }
    else if (err == WC_NO_ERR_TRACE(EXT_MISSING)) {
        printf("FAIL  unknown ServerHello 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.2 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 #10321
# ("ServerHello 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-10321.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="10321"
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 "ServerHello + 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 "ServerHello + 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  ServerHello+unknown : "; fmt_expected_fail "$RC_BEF"; echo
printf "  AFTER   ServerHello+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 #10321 ServerHello case."; echo
    exit 0
else
    echo; bold "Overall: at least one outcome was UNEXPECTED."; echo
    exit 1
fi

If a ServerHello-specific test in tests/api/test_tls13.c (sibling to the HRR-focused test_tls13_unknown_ext_rejected from PR #10186) would be useful, happy to turn this into a PR.

[LiD0209]

This PR #10186 looks different from my question

[kareem-wolfssl]

Hi @LiD0209,

Thanks for the report! I'm not able to access the reproducer or log, can you reattach them?
Are you confident PR #10186, specifically the check in tls.c will not address this? https://github.com/wolfSSL/wolfssl/pull/10186/changes#diff-bb132d62ad3f3a5eac6006e2a383ad909e30072360265a49a962ac765962be34R17665
Can you retest on the current master to confirm? Thanks.

[LiD0209]

Hi @kareem-wolfssl

Thanks for the follow-up.

I retested this on the current master, including the relevant PR #10186 changes, and I can confirm that the issue is no longer reproducible in my test environment. The extra unknown extension in TLS 1.3 ServerHello is now rejected as expected, so this looks fixed from my side.

Thanks for addressing it.