TLS 1.3 (RFC 8446) Incompliance Observations in wolfSSL

[X1AOxiang]

Hi, while reviewing wolfSSL's TLS 1.3 implementation against RFC 8446, we noticed several
places where the current behavior appears to differ from the specification. Each item below
cites the relevant RFC text alongside the corresponding source code for your reference.
We hope this is helpful for improving RFC conformance.

---

1. Missing illegal_parameter Alert When pre_shared_key Is Not the Last Extension

RFC Reference: RFC 8446 Section 4.2.11 (Pre-Shared Key Extension)

"The "pre_shared_key" extension MUST be the last extension in the ClientHello (this facilitates implementation as described below). Servers MUST check that it is the last extension and otherwise fail the handshake with an "illegal_parameter" alert."

Analysis:
In tls13.c at lines 6173–6177, CheckPreSharedKeys detects that the PSK extension is
not the last extension in ClientHello via the check ssl->extensions != ext, and
immediately returns PSK_KEY_ERROR. No SendAlert(ssl, alert_fatal, illegal_parameter)
call is made at this point. The only illegal_parameter alert visible in the relevant code
paths (lines 5582–5593) belongs to HelloRetryRequest processing—a separate, unrelated
path.

Source Code Evidence (tls13.c):

// tls13.c:6173-6177
/* Extensions pushed on stack/list and PSK must be last. */
if (ssl->extensions != ext) {
    WOLFSSL_ERROR_VERBOSE(PSK_KEY_ERROR);
    return PSK_KEY_ERROR;
}

---

2. Inconsistent Alert Type When signature_algorithms Extension Is Absent

RFC Reference: RFC 8446 Section 4.2.3 (Signature Algorithms) and Section 9.2

"If a server is authenticating via a certificate and the client has not sent a "signature_algorithms" extension, then the server MUST abort the handshake with a "missing_extension" alert (see Section 9.2)."

Analysis:
In tls13.c at lines 7062–7064, when the server detects that the client's ClientHello
carries no signature_algorithms extension (ssl->clSuites->hashSigAlgoSz == 0), the
code calls ERROR_OUT(INCOMPLETE_DATA, exit_dch). The handshake is still aborted, but the alert type presented to the peer does not match the specification.

Source Code Evidence (tls13.c):

// tls13.c:7060-7065
/* Can't check ssl->extensions here as SigAlgs are unconditionally
   set by TLSX_PopulateExtensions */
if (ssl->clSuites->hashSigAlgoSz == 0) {
    WOLFSSL_MSG("Client did not send a SignatureAlgorithms extension");
    ERROR_OUT(INCOMPLETE_DATA, exit_dch);
}

---

3. Predictable certificate_request_context in Post-Handshake CertificateRequest

RFC Reference: RFC 8446 Section 4.3.2 / Section 4.6.2 (Post-Handshake Authentication)

"When requesting post-handshake authentication, the server SHOULD make the context unpredictable to the client (e.g., by randomly generating it) in order to prevent an attacker who has temporary access to the client's private key from pre-computing valid CertificateVerify messages."

Analysis:
In tls13.c at lines 14148–14163, wolfSSL_request_certificate constructs a CertReqCtx struct with a fixed one-byte context (certReqCtx->len = 1) whose value starts at 0 and increments by 1 for each successive request
(certReqCtx->ctx = certReqCtx->next->ctx + 1). No cryptographic randomness source is consulted. The resulting context sequence 0, 1, 2, … is predictable, and this value is passed directly to SendTls13CertificateRequest and transmitted on the wire, differing from the RFC's recommendation that the context be unpredictable.

Source Code Evidence (tls13.c):

// tls13.c:14148-14163
certReqCtx = (CertReqCtx*)XMALLOC(sizeof(CertReqCtx), ssl->heap,
                                               DYNAMIC_TYPE_TMP_BUFFER);
if (certReqCtx == NULL)
    return MEMORY_E;
XMEMSET(certReqCtx, 0, sizeof(CertReqCtx));
certReqCtx->next = ssl->certReqCtx;
certReqCtx->len = 1;
if (certReqCtx->next != NULL)
    certReqCtx->ctx = certReqCtx->next->ctx + 1;
ssl->certReqCtx = certReqCtx;

ret = SendTls13CertificateRequest(ssl, &certReqCtx->ctx, certReqCtx->len);

---

[anhu]

HI @X1AOxiang ,

You bring up some interesting points. We will need to look into these.

I think for 3, its only a suggestion as the text SHOULD appears there. Is thing something you need in your day to day usage of wolfSSL? Would you consider filing a Feature Request for it?

Can you let us know about yourself?

• location? (country and closest metro area)
• interest? (Personal, Academic, Professional)
• institutions? (Company, Academic institution, etc.)
• anything else you think we might find relevant/interesting?

Stay tuned, I wll be assigning an engineer to look into 1 and 2. By the way , if you have Proof of Concept snippets, we would appreciate it if you send them over.

Warm regards, Anthony.

[LiD0209]

HI @X1AOxiang,
For the second point, wolfssl-master/src/internal.c (line 35362) maps INCOMPLETE_DATA to missing_extension.

int TranslateErrorToAlert(int err)
{
    switch (err) {
        case WC_NO_ERR_TRACE(BUFFER_ERROR):
            return decode_error;
        case WC_NO_ERR_TRACE(EXT_NOT_ALLOWED):
        case WC_NO_ERR_TRACE(PEER_KEY_ERROR):
        case WC_NO_ERR_TRACE(ECC_PEERKEY_ERROR):
        case WC_NO_ERR_TRACE(BAD_KEY_SHARE_DATA):
        case WC_NO_ERR_TRACE(PSK_KEY_ERROR):
        case WC_NO_ERR_TRACE(INVALID_PARAMETER):
        case WC_NO_ERR_TRACE(HRR_COOKIE_ERROR):
        case WC_NO_ERR_TRACE(BAD_BINDER):
        case WC_NO_ERR_TRACE(DUPLICATE_TLS_EXT_E):
            return illegal_parameter;
        case WC_NO_ERR_TRACE(INCOMPLETE_DATA):
            return missing_extension;
        case WC_NO_ERR_TRACE(MATCH_SUITE_ERROR):
        case WC_NO_ERR_TRACE(MISSING_HANDSHAKE_DATA):
            return handshake_failure;
        case WC_NO_ERR_TRACE(VERSION_ERROR):
            return protocol_version;
        case WC_NO_ERR_TRACE(BAD_CERTIFICATE_STATUS_ERROR):
            return bad_certificate_status_response;
        case WC_NO_ERR_TRACE(OUT_OF_ORDER_E):
            return unexpected_message;
        default:
            return invalid_alert;
    }
}

[julek-wolfssl]

Hi @X1AOxiang ,

For points 1 and 2, both are mapped to the correct alert with TranslateErrorToAlert and alerts are sent. For 3, an iterated certificate_request_context is sufficient and satisfies the RFC requirements. We don't see a need to add complexity to this mechanism.

Sincerely
Juliusz