TLS 1.2 CertificateVerify: validate sig alg matches peer key

[SparkiDev]

Description

Don't proceed with parsing CertificateVerify message in TLS 1.2 if the signature algorithm doesn't match the peer's key (key from client certificate).

Fixes zd#20771

Testing

Tested enabling/disabling RSA, ECC, Ed25519 and Ed448 in all combinations.

Checklist

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

[devin-ai-integration]

🛟 Devin Lifeguard found 1 likely issues in this PR

• check-return-codes snippet: Inspect SetDigest’s prototype; if it returns an int, capture the result (e.g., ret = SetDigest(...)) and propagate or handle any non-zero return before continuing.

@SparkiDev
please take a look at the above issues which Devin flagged. Devin will not fix these issues automatically.

[SparkiDev]

SetDigest is void return.

[GSoJC234]

Hi Sean,

The updated code correctly prevents the CertificateVerify message that uses the DSA+SHA1 algorithm.
However, when the message contains the ECDSA+SHA1 algorithm, the server still accepts it.

Would it be possible to compare the signature and hash algorithms in the CertificateVerify message against the server-supported algorithms listed in the CertificateRequest message (e.g., ssl->suites->hashSigAlgo)?

According to RFC 5246,

"The hash and signature algorithms used in the signature MUST be one of those present in the supported_signature_algorithms field of the CertificateRequest message."

[julek-wolfssl]

Would be great if there was some tests in place to check that mismatches error out the tls stack.

[GSoJC234]

I’ve reviewed the latest commit, and the server correctly validates that the signature/hash algorithm in the CertificateVerify message matches one of the algorithms listed in the CertificateRequest message.

Thanks for the quick and thorough fix!