Enforce RFC 8446 SHA-1 certificate rule on TLS 1.3 chains

[embhorn]

Description

signature_algorithms_cert was parsed into ssl->certHashSigAlgo but never read again, so a TLS 1.3 peer sent whatever chain was configured regardless of what the other side advertised.

RFC 8446 Section 4.4.2.2 allows a fallback chain the peer did not advertise support for, but the chain MUST NOT use SHA-1 unless the peer's advertisement permits it. Section 4.4.2.3 applies the same rule to the client. Only that requirement is enforced; a chain that merely fails to match is still sent, as the RFC intends.

Fixes zd22288

Testing

1. SHA-1 leaf, client offers no SHA-1 fails, MATCH_SUITE_ERROR
2. same leaf, client offers rsa_pkcs1_sha1 succeeds
3. SHA-256 chain, default client succeeds
4. SHA-256 leaf under self signed SHA-1 root succeeds
5. SHA-1 client chain, request omits SHA-1 succeeds, SEND_BLANK_CERT
6. same chain, request offers SHA-1 succeeds, SEND_CERT

Checklist

• added tests
• updated/added doxygen
• updated appropriate READMEs
• Updated manual and documentation

[Copilot]

Copilot encountered an error and was unable to review this pull request. You can try again by re-requesting a review.

[embhorn]

retest this please

[Copilot]

Pull request overview

Copilot reviewed 10 out of 10 changed files in this pull request and generated no new comments.

Suppressed comments (2)

src/tls13.c:9976

• This comment says “self signed and therefore a trust anchor”, but IsSelfSignedCert() relies on DecodedCert->selfSigned, which is set from an issuer/subject name-hash compare (not a validated self-signature). That makes the comment misleading and can confuse future maintenance of the RFC 8446 trust-anchor exemption logic.

/* Certificate is self signed and therefore a trust anchor. RFC 8446
 * Section 4.4.2.2 allows it to be left out of the chain entirely, so its
 * signature does not constrain what may be sent.
 *

src/tls13.c:10034

• The leaf certificate check exempts “self signed” certificates from the SHA-1 restriction. A leaf certificate cannot be omitted as a trust anchor per RFC 8446 (only the trust anchor/root can be omitted), so a self-signed SHA-1 leaf would incorrectly be allowed when the peer didn’t advertise SHA-1.

    if (IsSha1SignedCert(ssl->buffers.certificate->buffer,
                         ssl->buffers.certificate->length) &&
            !IsSelfSignedCert(ssl, ssl->buffers.certificate->buffer,
                              ssl->buffers.certificate->length)) {
        ret = MATCH_SUITE_ERROR;

[wolfSSL-Fenrir-bot]

Fenrir Automated Review — PR #11100

Scan targets checked: wolfcrypt-rs-bugs, wolfssl-bugs, wolfssl-src

Findings: 8
8 finding(s) posted as inline comments (see file-level comments below)

This review was generated automatically by Fenrir. Findings are non-blocking.

[github-actions]

MemBrowse Memory Report

gcc-arm-cortex-m4-dtls13

• FLASH: .text +576 B (+0.3%, 182,780 B / 1,048,576 B, total: 17% used)

gcc-arm-cortex-m4-openssl-compat

• FLASH: .rodata +24 B, .text +640 B (+0.1%, 775,508 B / 1,048,576 B, total: 74% used)

gcc-arm-cortex-m4-pq

• FLASH: .text +576 B (+0.2%, 297,500 B / 1,048,576 B, total: 28% used)

gcc-arm-cortex-m4-rsa-only

• FLASH: .text +640 B (+0.2%, 328,304 B / 1,048,576 B, total: 31% used)

gcc-arm-cortex-m4-tls13

• FLASH: .text +576 B (+0.2%, 238,241 B / 262,144 B, total: 91% used)

gcc-arm-cortex-m7-pq

• FLASH: .text +576 B (+0.2%, 298,396 B / 1,048,576 B, total: 28% used)

gcc-arm-cortex-m7-tls13

• FLASH: .text +576 B (+0.2%, 238,305 B / 262,144 B, total: 91% used)

linuxkm-standard

• Data: __patchable_function_entries +16 B (+0.0%, 49,224 B)
  No memory changes detected for:
• gcc-arm-cortex-m0plus
• gcc-arm-cortex-m3
• gcc-arm-cortex-m4
• gcc-arm-cortex-m4-baremetal
• gcc-arm-cortex-m4-crypto-only
• gcc-arm-cortex-m4-min-ecc
• gcc-arm-cortex-m4-pkcs7
• gcc-arm-cortex-m4-sp-math
• gcc-arm-cortex-m4-tls12
• gcc-arm-cortex-m7
• linuxkm-pie
• stm32-sim-stm32h753