Executive Summary

This vulnerability involves the acceptance of an un-negotiated Raw Public Key (RPK) in place of an X.509 certificate, which bypasses the usual chain validation process. Normally, a raw public key has no certificate chain, so the function ParseCertRelative() accepts it without performing any trust verification. This acceptance should only happen if RPK was explicitly negotiated for that peer. The vulnerability arises because if no certificate type is negotiated, the system defaults to expecting an X.509 certificate, but previously it could accept an un-negotiated raw public key, leading to a security bypass.

The fix enforces that when no certificate type is negotiated, the expected type defaults to X.509 as per RFC 7250 and RFC 8446. Any mismatch, including receiving an un-negotiated raw public key, is rejected with an UNSUPPORTED_CERTIFICATE error. This issue only affects builds of wolfSSL with Raw Public Key support enabled (HAVE_RPK), which is disabled by default in standalone builds but included when using --enable-all.

Useful 0 Not Useful 0

Impact Analysis

This vulnerability can allow an attacker to bypass the normal certificate chain validation by presenting a raw public key that was not negotiated, potentially leading to acceptance of an untrusted or malicious key. This undermines the trust model of TLS connections, possibly enabling man-in-the-middle attacks or unauthorized access by impersonating a legitimate server or client.

Useful 0 Not Useful 0

Mitigation Strategies

To mitigate this vulnerability, ensure that your wolfSSL library is updated to version 5.9.2 or later, which includes fixes that enforce stricter validation of negotiated certificate types and reject un-negotiated raw public keys.

Additionally, verify that Raw Public Key (RPK) support (HAVE_RPK) is disabled if not explicitly needed, as it is disabled by default in standalone builds but enabled with the --enable-all option.

Useful 0 Not Useful 0

Compliance Impact

The vulnerability involves accepting an un-negotiated Raw Public Key (RPK) in place of an X.509 certificate, bypassing chain validation and trust verification. This flaw could potentially allow unauthorized or untrusted entities to be accepted as valid peers, undermining the security guarantees of the TLS communication.

Since standards and regulations like GDPR and HIPAA require strong protection of data in transit, including proper authentication and encryption, this vulnerability could negatively impact compliance by weakening the trust model of TLS connections. Improper certificate validation may lead to exposure of sensitive data or unauthorized access.

However, the fix enforces default acceptance of only X.509 certificates unless RPK was explicitly negotiated, rejecting un-negotiated RPKs. This correction aligns with RFC 7250 and RFC 8446, restoring proper certificate validation and helping maintain compliance with security requirements in common standards.

Useful 0 Not Useful 0