wolfSSL Backend Silently Ignores --cert-status (OCSP Stapling Bypass)

How it was found

Summary

When curl is built with the wolfSSL TLS backend, --cert-status (CURLOPT_SSL_VERIFYSTATUS) is silently accepted and ignored. The wolfSSL backend sets cert_status_request = NULL in its vtable (lib/vtls/wolfssl.c:2309), meaning OCSP stapling is not implemented. The curl_easy_setopt() call returns CURLE_NOT_BUILT_IN, but the CLI tool at src/config2setopts.c:442 discards this return value — the user gets no error, no warning, and the connection proceeds without OCSP verification.

This is confirmed exploitable on the HTTP/3 (QUIC) path where a server providing no OCSP staple is accepted despite --cert-status being set.

Root Cause (

Layer 1 — wolfSSL backend lacks OCSP support: lib/vtls/wolfssl.c:2309 — vtable entry:

NULL,                            /* cert_status_request */

Zero references to verifystatus or OCSP anywhere in wolfssl.c. Compare with OpenSSL (6 references) and GnuTLS (4 references).

Layer 2 — CLI silently drops the error: src/config2setopts.c:441-442:

if(config->verifystatus)
    my_setopt_long(curl, CURLOPT_SSL_VERIFYSTATUS, 1);

my_setopt_long expands to curl_easy_setopt() and the CURLE_NOT_BUILT_IN return is discarded. No warning printed, no error to the user.

Layer 3 — QUIC path also has no check: lib/vquic/vquic-tls.c:169-186 — wolfSSL QUIC verification checks verifyhost (line 171) and pinned key (line 186) but has no verifystatus check, even as a "not supported" error.

Proof of Concept

Docker container: curl 8.23.1-DEV built with wolfSSL 5.9.4, ngtcp2 1.8.1, nghttp3 1.6.0. QUIC server: ngtcp2 wsslserver example (no OCSP staple configured).

Test A: H3 without --cert-status (control)

curl --http3-only --insecure https://127.0.0.1:4434/
→ exit:0 http:404 (works as expected)

Test B: H3 WITH --cert-status (VULNERABILITY)

curl --http3-only --insecure --cert-status https://127.0.0.1:4434/
→ exit:0 http:404

Server provides NO OCSP staple. --cert-status is set but silently ignored. Full HTTP/3 connection succeeds:

* SSL connection using TLSv1.3 / TLS13-AES128-GCM-SHA256
* [HTTP/3] [0] OPENED stream for https://127.0.0.1:4435/
> GET / HTTP/3
< HTTP/3 404

Expected behavior: Either reject the connection with CURLE_SSL_INVALIDCERTSTATUS, or error at startup with "OCSP stapling not supported with this TLS backend."

Suggested Fix

Option A (minimal): Make config2setopts.c check the return value and warn/error:

if(config->verifystatus) {
    result = my_setopt_long(curl, CURLOPT_SSL_VERIFYSTATUS, 1);
    if(result == CURLE_NOT_BUILT_IN) {
        warnf(global, "OCSP stapling not supported by this TLS backend");
        return result;
    }
}

Option B (complete): Add verifystatus check to the wolfSSL QUIC path at vquic-tls.c:

if(conn_config->verifystatus) {
    failf(data, "OCSP stapling not supported with wolfSSL QUIC");
    return CURLE_SSL_INVALIDCERTSTATUS;
}

Impact

1. User sets --cert-status expecting OCSP stapling enforcement — it is silently ignored
2. A revoked certificate that would be caught by OCSP is accepted without warning
3. Applications using CURLOPT_SSL_VERIFYSTATUS with wolfSSL have a false sense of security
4. The silent failure is worse than a crash — the user believes they have OCSP protection when they do not