[Bug]: wolfSSL certificate_authorities Length-Boundary Verification

[LiD0209]

Contact Details

lxd_dong@bupt.edu.cn

Version

v5.9.1

Description

wolfSSL certificate_authorities Length-Boundary Verification

Scope

This note verifies whether wolfSSL truly has the certificate_authorities extension length-boundary issue.

RFC baseline

From TLS1.3.txt (RFC 8446 presentation language):

• opaque DistinguishedName<1..2^16-1>;
• opaque authorities<3..2^16-1>;
• struct { opaque authorities<3..2^16-1>; } CertificateAuthoritiesExtension;

So the CA list payload must not be shorter than 3 bytes (before counting the outer extension header).

Build-dependent behavior

Default build (build/wolfssl-default)

• OPENSSL_EXTRA is not enabled in this build (options.h shows it undefined).
• In internal.h, CA Names support is gated and WOLFSSL_NO_CA_NAMES is set when OPENSSL_EXTRA is not enabled.
• Therefore, certificate_authorities semantic parsing is not active in this build.

Observed probe results:

• size=2 -> ret=-328 (BUFFER_ERROR)
• size=3 -> ret=0
• size=4 -> ret=0
• size=6 -> ret=0

Interpretation: after generic extension framing checks, this extension is effectively treated as unsupported/unknown in default build (except the generic minimum-size guard path catches size=2).

OpenSSL-enabled build (build/wolfssl-openssl)

Probe results:

• size=2 -> ret=-328 (BUFFER_ERROR)
• size=3 -> ret=-328 (BUFFER_ERROR)
• size=4 -> ret=-132 (BUFFER_E)
• size=6 (DN=30 00) -> ret=0

Interpretation: when CA Names feature is enabled, malformed short payloads are rejected; the reported low-boundary problem is not reproduced in this build.

Code evidence

• Generic extension minimum-size check: src/tls.c (TLSX_Parse) enforces size < TLSX_GET_MIN_SIZE_CLIENT(...) rejection.
• CA extension parser path: src/tls.c (TLSX_CA_Names_Parse) validates length framing and per-entry boundaries.
• Feature gate: wolfssl/internal.h CA Names macros tie support to OPENSSL_EXTRA.

Verdict

For wolfSSL, this is primarily configuration-dependent behavior, not a confirmed universal parser boundary bug:

• In OpenSSL-enabled CA Names build: boundary violation was not reproduced.
• In default build: CA Names path is not active, so this is better classified as feature-gated/non-covered behavior.

Reproduction steps

No response

Relevant log output

[cpsource]

Took a look — your verdict (feature-gated/non-covered behavior, not a confirmed universal parser boundary bug) reproduces on current master. No patch proposed; this reply documents the design rationale and supplies a verification reproducer that asserts the four-row probe table you observed in V5.9.1 still holds on HEAD (commit 6074a2dbe, 2026-04-24).

The short version of why the default-build silent-accept is RFC-conformant: certificate_authorities lands in CertificateRequest, which PR #10186's TLSX_Parse() default: rejection deliberately excludes — the comment at src/tls.c:18002 is explicit that this exclusion exists so RFC 8701 GREASE in CertificateRequest stays valid. Full analysis below.

---

The bug

The reporter performed a length-boundary probe of the TLS 1.3
certificate_authorities extension (RFC 8446 §4.2.4, type
0x002F) against TLSX_Parse() and asked whether wolfSSL has a
universal parser-boundary defect. Their own verdict (verbatim):

For wolfSSL, this is primarily configuration-dependent
behavior, not a confirmed universal parser boundary bug:

• In OpenSSL-enabled CA Names build: boundary violation was
  not reproduced.
• In default build: CA Names path is not active, so this is
  better classified as feature-gated/non-covered behavior.

This review confirms the reporter's analysis on current master.
There is no fix-forward proposed; the artefacts here are a
verification reproducer, harness, and an explanation of why the
default-build behaviour is RFC-conformant by design.

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 ran wolfSSL v5.9.1.
• gh pr list --repo wolfSSL/wolfssl --state all --search "10316" →
  no PRs reference this issue.
• gh search issues --repo wolfSSL/wolfssl --include-prs "10316" →
  only the issue itself.
• Keyword scan for certificate_authorities:
  • PR Add support for certificate_authorities extension in ClientHello #9209 (merged 2025-10-01) "Add support for
    certificate_authorities extension in ClientHello" — adds
    TLSX_CA_Names_Parse() and the
    case TLSX_CERTIFICATE_AUTHORITIES arms in TLSX_Parse().
    Both gated on !defined(WOLFSSL_NO_CA_NAMES).
  • PR Fenrir fixes #10230 "Fenrir fixes" (open) — unrelated.
• WOLFSSL_NO_CA_NAMES is #defined in
  wolfssl/internal.h:1004,1020-1021 whenever OPENSSL_EXTRA is
  not enabled, so default builds carry WOLFSSL_NO_CA_NAMES on.

Conclusion: there is no in-flight upstream work that would change
the default-build behaviour observed by the reporter.

Root cause (or rather, designed behaviour)

TLSX_Parse() in src/tls.c dispatches by extension type. In
default builds:

• The enum value TLSX_CERTIFICATE_AUTHORITIES is not defined
  (wolfssl/internal.h:3037-3038, gated on
  !defined(NO_CERTS) && !defined(WOLFSSL_NO_CA_NAMES)).
• The corresponding case TLSX_CERTIFICATE_AUTHORITIES arms are
  also gated out (src/tls.c:14828, 15062, 15351, 15938).
• An incoming type-0x002F extension therefore falls through the
  switch to the default: branch at src/tls.c:17992.

The default: branch was tightened by PR #10186 (merged
2026-04-13) to abort with unsupported_extension — but
deliberately scoped to four message types only:

/* src/tls.c:18007 */
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;
}

The accompanying comment (lines 18002-18006) explicitly explains
the exclusion of certificate_request and new_session_ticket:
those are server-initiated payloads, not extension responses
to a ClientHello, and per RFC 8701 (GREASE) the server MAY include
unknown extension types in them which the client MUST treat like
any other unknown value (i.e. ignore them).

certificate_authorities legitimately rides in CertificateRequest,
so an unknown-feature instance of it lands in the GREASE-tolerant
arm by design.

The size=2 row in the reporter's table is a separate code path: the
generic TLSX_GET_MIN_SIZE_CLIENT() guard at src/tls.c:17371-17374
fires before per-type dispatch and rejects size < min(type)
unconditionally for client_hello. This is what produces the
-328 BUFFER_ERROR for size=2 even with the feature off.

Why the current design exists

PR #10186 was the redo of PR #9909, which had been reverted (PR
#9944) precisely because its broader rejection scope broke RFC 8701
GREASE in NewSessionTicket. The current scoping — only the four
client-side response-shaped messages — is the considered fix for
that regression. Extending the scope to certificate_request would
re-break GREASE in CertificateRequest, which RFC 8701 §3 explicitly
permits.

Proposed fix

None. The reporter's verdict is correct: the default-build
behaviour is feature-gated forward-compatibility, not a parser
boundary bug.

If a stronger guarantee is wanted in default builds — reject any
non-GREASE unknown extension type in CertificateRequest — that
would be a non-trivial follow-up: it requires either a GREASE-bit
test ((type & 0x0F0F) == 0x0A0A) or an IANA-types whitelist.
That is policy beyond what the issue asks for and is not proposed
here.

Caveats and risks

• Standards posture: silent acceptance of unknown extensions in
  CertificateRequest is RFC-conformant. RFC 8446 §4.2's MUST-abort
  rule applies to extension responses, not server-initiated
  messages. The default: comment in src/tls.c:18002 makes this
  explicit.
• Practical impact: the silently-accepted bytes are consumed
  but never dereferenced (the case body isn't compiled). No memory
  effect, no auth bypass, no parser-state desync.
• OpenSSL-enabled builds: the case TLSX_CERTIFICATE_AUTHORITIES
  arm and TLSX_CA_Names_Parse() are active and do enforce per-RFC
  framing — the reporter's probes confirm that.
• size=2 row: the BUFFER_ERROR observed there comes from the
  generic min-size guard, not from the feature-gated parser. This
  is the same regardless of whether OPENSSL_EXTRA is set.

Tests to add

This review provides issue-10316-test.c, a direct-call probe
against TLSX_Parse() (statically linked against libwolfssl.a)
that asserts the reporter's four-row table on a default build:

size	observed	matches table
2	-328 (BUFFER_ERROR)	yes
3	0 (silent accept)	yes
4	0 (silent accept)	yes
6	0 (silent accept)	yes

A natural follow-up would be to extend the harness with the
OpenSSL-enabled build the reporter also tested, asserting the
boundary-rejection table there too. Not included in this review.

Files touched by the proposed patch

None. There is no issue-10316.patch in this directory.

Appendix — end-to-end verification

issue-10316-test.c:

1. Initialises wolfSSL, builds a TLS 1.3 client WOLFSSL_CTX*
   and a WOLFSSL* from it.
2. Allocates an 8 KB zero-filled blob to satisfy TLSX_Parse()'s
   (isRequest && !suites) guard. Type 0x002F is not a recognised
   case in default builds, so the buffer is never dereferenced.
3. For each probe size in {2, 3, 4, 6}:
   • Constructs a 4-byte extension header
     0x00 0x2F | size_high | size_low followed by size zero
     bytes.
   • Calls TLSX_Parse(ssl, blob, 4+size, client_hello, suites).
4. Asserts each return code matches the reporter's table.
5. PASS iff all four match; FAIL iff any diverges (which would
   indicate a different build configuration or upstream behaviour
   change).

Observed results

Scenario	Reported (V5.9.1)	This review (master)
size=2	-328 BUFFER_ERROR	-328 BUFFER_ERROR
size=3	0 silent accept	0 silent accept
size=4	0 silent accept	0 silent accept
size=6	0 silent accept	0 silent accept

The verification confirms the reporter's classification.

Running the test harness

test.sh alongside this README runs the verification once. From
this directory:

./test.sh

What it does, in order:

1. Runs ./configure --enable-tls13 --enable-static (no
   --enable-opensslextra, so WOLFSSL_NO_CA_NAMES is on).
2. Builds wolfSSL.
3. Builds the reproducer linked statically against
   libwolfssl.a so the WOLFSSL_LOCAL symbol TLSX_Parse
   resolves.
4. Runs the reproducer; expects all four probes to match the
   table.
5. Prints a colored summary.

There is no BEFORE/AFTER step — there is no patch. Exit status:
0 only when the table matches.

---

issue-10316-test.c — direct TLSX_Parse() probe via static link

/* issue-10316-test.c
 *
 * Verification reproducer for wolfSSL issue #10316:
 *   "[Bug]: wolfSSL certificate_authorities Length-Boundary Verification"
 *
 * The reporter ran a four-row probe against TLSX_Parse with
 * extension type 0x002F (`certificate_authorities`, RFC 8446 §4.2.4)
 * at varying inner-payload sizes, on a default build (no
 * OPENSSL_EXTRA, hence WOLFSSL_NO_CA_NAMES). Their observation:
 *
 *   size=2 -> ret=-328  (BUFFER_ERROR, generic minimum-size guard)
 *   size=3 -> ret=0     (silent accept)
 *   size=4 -> ret=0     (silent accept)
 *   size=6 -> ret=0     (silent accept)
 *
 * They concluded this is "feature-gated/non-covered behavior, not a
 * confirmed universal parser boundary bug." This program runs the
 * same probes against current master and asserts that the table
 * still reproduces.
 *
 * Why current master ends here, after PR #10186 (merged 2026-04-13):
 *
 *   * In default builds `case TLSX_CERTIFICATE_AUTHORITIES` is not
 *     compiled (it sits inside `!defined(WOLFSSL_NO_CA_NAMES)`),
 *     and the enum value itself is conditional, so type 0x002F
 *     reaches the `default:` branch in `TLSX_Parse()`.
 *   * PR #10186's `default:`-branch rejection deliberately scopes
 *     to `{server_hello, hello_retry_request, encrypted_extensions,
 *     certificate}`, which excludes `certificate_request`, the
 *     message that legitimately carries `certificate_authorities`.
 *     The exclusion exists so RFC 8701 GREASE in CertificateRequest
 *     stays valid. Comment in src/tls.c:18002 makes this explicit.
 *
 *   * The size=2 row still returns `BUFFER_ERROR` because the
 *     msgType=client_hello path runs the
 *     `TLSX_GET_MIN_SIZE_CLIENT()` guard before any per-type
 *     dispatch — that guard fires regardless of feature gates.
 *
 * This reproducer exits 0 (PASS) when the table matches.
 */

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

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

extern int TLSX_Parse(WOLFSSL* ssl, const unsigned char* input,
                      unsigned short length, unsigned char msgType,
                      void* suites);

/* From wolfssl/internal.h enum HandShakeType. */
#define HS_CLIENT_HELLO 1

/* TLS extension type for certificate_authorities (RFC 8446 §4.2.4). */
#define EXT_TYPE_CERT_AUTHORITIES 0x002F

/* Build a single-extension input list:
 *   ext_type(2) | ext_len(2) | ext_body(size)
 *
 * `size` is the inner extension-data length (the `ext_len` field
 * value), matching the reporter's table semantics.
 */
static int probe_size(WOLFSSL* ssl, void* suites, int size, int* out_ret)
{
    unsigned char  buf[260];
    int            i;

    if (size < 0 || size + 4 > (int)sizeof(buf))
        return -1;

    buf[0] = (EXT_TYPE_CERT_AUTHORITIES >> 8) & 0xFF;
    buf[1] =  EXT_TYPE_CERT_AUTHORITIES       & 0xFF;
    buf[2] = (size >> 8) & 0xFF;
    buf[3] =  size       & 0xFF;
    for (i = 0; i < size; i++)
        buf[4 + i] = 0x00;

    *out_ret = TLSX_Parse(ssl, buf, (unsigned short)(4 + size),
                          HS_CLIENT_HELLO, suites);
    return 0;
}

int main(int argc, char** argv)
{
    int           rc = 1;
    WOLFSSL_CTX*  ctx = NULL;
    WOLFSSL*      ssl = NULL;
    void*         suites_blob = NULL;
    int           probe_sizes[4]      = { 2, 3, 4, 6 };
    int           probe_expected[4]   = { -328, 0, 0, 0 };
    int           probe_results[4]    = { 99, 99, 99, 99 };
    int           probe_ok            = 1;
    int           i;

    (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;
    }
    ssl = wolfSSL_new(ctx);
    if (ssl == NULL) {
        fprintf(stderr, "ssl alloc failed\n"); goto out;
    }

    /* TLSX_Parse with isRequest=true (msgType=client_hello) needs a
     * non-NULL `suites` pointer; the per-type handler for type
     * 0x002F is not compiled in a default build, so the buffer is
     * never dereferenced — a zero-filled blob suffices. Sized to
     * comfortably exceed sizeof(Suites). */
    suites_blob = calloc(1, 8192);
    if (suites_blob == NULL) {
        fprintf(stderr, "suites alloc failed\n"); goto out;
    }

    for (i = 0; i < 4; i++) {
        if (probe_size(ssl, suites_blob, probe_sizes[i],
                       &probe_results[i]) != 0) {
            fprintf(stderr, "probe build failed (size=%d)\n",
                    probe_sizes[i]);
            goto out;
        }
        printf("size=%d -> ret=%d (expected %d)\n",
               probe_sizes[i], probe_results[i], probe_expected[i]);
        if (probe_results[i] != probe_expected[i])
            probe_ok = 0;
    }

    if (probe_ok) {
        printf("PASS  observed behavior matches reporter's verification "
               "table on default build (CA Names feature-gated; "
               "type 0x002F falls through TLSX_Parse default; PR #10186 "
               "intentionally excludes certificate_request to preserve "
               "RFC 8701 GREASE forward-compat).\n");
        rc = 0;
    }
    else {
        printf("FAIL  observed behavior diverges from reporter's table; "
               "either the build configuration is not default (e.g. "
               "OPENSSL_EXTRA enabled) or upstream behaviour changed.\n");
        rc = 1;
    }

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

test.sh — verification harness (no BEFORE/AFTER)

#!/bin/bash
# Verification harness for wolfSSL issue #10316
# ("certificate_authorities Length-Boundary Verification").
#
# This issue is a verification note rather than a proposed fix:
# the reporter explicitly concluded "feature-gated/non-covered
# behavior, not a confirmed universal parser boundary bug." This
# harness confirms the reporter's probe table still reproduces on
# current master under a default build.
#
# Steps:
#   1. ./configure --enable-tls13 --enable-static (no
#      --enable-opensslextra, so WOLFSSL_NO_CA_NAMES is set and the
#      case TLSX_CERTIFICATE_AUTHORITIES is not compiled).
#   2. Build wolfSSL.
#   3. Build the reproducer linked statically against libwolfssl.a
#      so the WOLFSSL_LOCAL TLSX_Parse symbol resolves.
#   4. Run the reproducer; expect PASS.
#
# There is no BEFORE/AFTER step — there is no patch. Exit code 0
# iff the verification matches.

set -u

ISSUE_N="10316"
SOURCE_FILE_RELATIVE="src/tls.c"
CFG_FLAGS="--enable-tls13 --enable-static"

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"
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 "==================== $* ===================="; }

# Sanity: src/tls.c should be clean (no leftover edits from prior
# review runs).
git -C "$REPO" checkout -- "$SOURCE_FILE_RELATIVE" 2>/dev/null || true

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

# Sanity: confirm OPENSSL_EXTRA is NOT defined (we want WOLFSSL_NO_CA_NAMES on).
if grep -q "define OPENSSL_EXTRA\b" "$REPO/wolfssl/options.h" 2>/dev/null; then
    echo "WARNING: OPENSSL_EXTRA is defined; this is not the default build."
fi

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

section "Build reproducer (statically linked)"
gcc -Wall -Wextra -I"$REPO" \
    "$TEST_SRC" "$LIB_DIR/libwolfssl.a" \
    -lm -lpthread -o "$TEST_BIN" || {
    echo "reproducer compile/link failed"
    exit 1
}

section "Run verification reproducer"
echo
"$TEST_BIN" 2>&1
RC=$?
echo
echo "  reproducer exit = $RC"

section "Summary"
fmt_expected_pass() { [ "$1"  = "0" ] && green "PASS (expected — verification matches)" || red "FAIL (UNEXPECTED — table did not match)"; }

printf "  Verification : "; fmt_expected_pass "$RC"; echo

if [ "$RC" = "0" ]; then
    echo; bold "Overall: reporter's table reproduces on master; behaviour is as designed."; echo
    exit 0
else
    echo; bold "Overall: verification failed — see reproducer output above."; echo
    exit 1
fi

If you'd like a stronger guarantee on the default-build path — e.g. reject any non-GREASE unknown extension type in CertificateRequest — that would be a non-trivial follow-up (needs either a GREASE-bit test (type & 0x0F0F) == 0x0A0A or an IANA-types whitelist). Happy to draft it as a separate proposal if useful.

[jackctj117]

Confirmed not a bug — default builds intentionally compile out the
certificate_authorities parser and let the extension fall through to the
unknown-extension handler, which per RFC 8701 (GREASE) MUST ignore unknown extensions in
CertificateRequest (see the rationale comment added in PR #10186 at
src/tls.c:18002-18006). OPENSSL_EXTRA builds enable TLSX_CA_Names_Parse, which properly
rejects malformed short payloads as your probe table shows; closing as expected behavior.