feat: verify certificate issuer intent by default

[CarolYeh910]

Goal

Enable certificate intent validation by default

Why

Previously, a client certificate issued for a non-TLS purpose would be accepted as valid by s2n-tls. This lack of validation allows certificates intended for other purposes, such as code signing, to be used for TLS.

How

s2n_x509_validator_verify_intent() will be added to validate the intent of all untrusted certs in the chain of trust (i.e. the leaf cert and all the intermediate certs). We call s2n_x509_validator_verify_intent_for_cert() on each individual cert, which invokes an OpenSSL API X509_check_purpose() to check if the cert satisfies the SSL_CLIENT or SSL_SERVER purpose. If not, our X509 validation will reject the cert chain and fail the handshake.

Given that this might be a breaking change for some users, the s2n_config_disable_x509_intent_verification() API can be used to disable the validation if the impacted users could not update their incompatible certs.

To facilitate the evaluation of whether a certificate is compatible with the intent validation, the following section offers a more detailed explanation.

Certificate issuers indicate their intent for a certificate in two X509 extensions: Key Usage and Extended Key Usage. A valid certificate must include the proper fields if these extensions exist.

Key Usage (KU) extensions

s2n-tls already validates that intermediate CA certificates set valid Key Usage fields. The new validation will require leaf certificates to satisfy the following conditions:

• Client leaf certificates containing a Key Usage extension MUST set the digitalSignature or the keyAgreement fields.
• Server leaf certificates containing a Key Usage extension MUST set the digitalSignature or the keyEncipherment or the keyAgreement fields.
• The Key Usage extension MAY set other fields in addition to any of these fields. Leaf certificates MAY omit a Key Usage extension.

Extended Key Usage (EKU) extensions

If a leaf or intermediate certificate contains an EKU, the TLS authentication field MUST be set for the correct TLS mode (TLS clientAuth for client certificates and TLS serverAuth for server certificates).

Similar to KU extensions, other fields MAY be set in addition to the correct field, such as setting both TLS authentication fields, or setting the correct TLS authentication field in addition to the codeSigning field. Certificates MAY omit an Extended Key Usage extension.

Callouts

It seems difficult to regenerate the OCSP certificates, so I disabled the intent validation for some of the OCSP tests instead.

Testing

Added a unit test against the certs in the /tests/pems/intent folder with different KU and EKU combinations. Also included a section at the beginning to test the disable_x509_intent_verification API.

Related

#5622, #5630, #5651

release summary: enable certificate intent validation by default; add a config API s2n_config_disable_x509_intent_verification() to disable it if necessary

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.