CheckOcspRequest used to return CERT_GOOD whenever a certificate
lacked an AIA extension and no override URL was configured, with
the rationale 'Cert has no OCSP URL, assuming CERT_GOOD'. That is
a fail-open soft-fail: an operator who turned on
WOLFSSL_OCSP_CHECKALL expecting every certificate in the chain to
be revocation-checked would still silently accept a certificate
that omits its OCSP responder URL, letting a misconfigured (or
attacker-controlled) issuer bypass revocation for non-stapled
flows.
Gate the fail-open path on cm->ocspCheckAll. When the caller has
asked for full-chain OCSP checking, return OCSP_NEED_URL so the
chain is refused. The legacy behavior is preserved when
ocspCheckAll is not set, keeping the soft-fail default for plain
WOLFSSL_OCSP_ENABLE users.
F-3227
wolfSSL_set_SSL_CTX is the OpenSSL-compatible entry point that an
SNI callback uses to swap in the per-vhost certificate during the
handshake. By design it only copies the certificate chain and
private key from the new CTX. Verification settings, the trusted
CA store, CRL/OCSP configuration, minimum key-size requirements,
and cipher/version policy stay attached to the original CTX. For
multi-tenant servers where each virtual host has its own security
policy, that means one host's verification rules silently apply
to a connection meant for another.
Expand the leading comment with an explicit SECURITY WARNING
that lists the settings which are NOT inherited and points at the
WOLFSSL*-level setters callers must use inside the SNI callback
when virtual hosts have different policies. The behavior of the
function is unchanged.
F-2902
DoTls13NewSessionTicket rejects a ticket lifetime greater than
MAX_LIFETIME (RFC 8446 Section 4.6.1, 7 days), but no test
exercised the rejection: every server in the suite stays well
within the limit, so a mutation deleting that bound check would
go unnoticed.
Add a manual memio test that pokes ctx_s->ticketHint to
MAX_LIFETIME + 1 (the public setter clamps to 604800), runs a
full TLS 1.3 handshake, and reads the post-handshake
NewSessionTicket on the client. The test confirms the over-limit
lifetime surfaces from wolfSSL_read as SERVER_HINT_ERROR.
F-2121
When resuming a session wolfSSL_SetSession unconditionally
overwrote ssl->version with the version stored in the cached
session, even if that version was below the WOLFSSL's configured
minDowngrade. The overwritten version then fed straight into
SendClientHello, so a client configured to require TLS 1.2 or
higher could still emit a ClientHello advertising e.g. TLS 1.0
when resuming an old cached session. The ServerHello path catches
the actual downgrade, but the ClientHello version is already a
protocol-conformance issue and can confuse middleboxes.
Reject the session if its stored minor version is below
ssl->options.minDowngrade. The check is DTLS-aware: DTLS minor
versions decrease as the protocol version increases, so the
direction of the comparison is flipped for DTLS.
F-2105
DTLS minor versions decrease as the protocol version increases
(DTLS 1.0=0xFF, DTLS 1.2=0xFD, DTLS 1.3=0xFC), but the ticket
version comparisons in DoClientTicketCheckVersion used the TLS
direction unconditionally. As a result a DTLS server resuming a
session ticket from a different DTLS version could land on the
wrong branch: a ticket from a newer DTLS version would be treated
as a downgrade instead of being rejected, and a ticket from an
older DTLS version would be flagged as 'greater version' and
refused outright. The minDowngrade check at the bottom had the
same inversion bug.
Branch on ssl->options.dtls so the greater-version, lesser-version,
and minDowngrade comparisons all use the right direction for the
active protocol family. TLS behavior is unchanged.
F-1828
Server-side OCSP stapling was unconditionally folding
OCSP_CERT_REVOKED, OCSP_CERT_UNKNOWN, and OCSP_LOOKUP_FAIL into a
success result so a stapling failure would not break the handshake.
OCSP_CERT_REVOKED, however, is an explicit positive assertion of
revocation by the responder and must not be ignored: silently
suppressing it lets a server keep advertising a revoked certificate
to clients that rely on stapling for revocation status.
Drop OCSP_CERT_REVOKED from the suppression list in
CreateOcspResponse, the CSR2_OCSP_MULTI handler in
SendCertificateStatus, and ProcessChainOCSPRequest. Continue
suppressing OCSP_CERT_UNKNOWN and OCSP_LOOKUP_FAIL, which are true
soft-fail responder conditions where the responder cannot answer.
F-1820
David Garske
JacobBarthelmeh
Kareem
Ruby Martin
Paul Adelsbach
Daniel Pouzzner
Juliusz Sosinowicz
Sean Parkinson
Tobias Frauenschläger