OCSP feature only supports SHA1 hashes

Security issue notifications

If you discover a potential security issue in s2n we ask that you notify
AWS Security via our vulnerability reporting page. Please do not create a public github issue.

Problem:

When debugging a RHEL9 build test failures in this PR, I noticed that we assume SHA1 is used to read and verify the response cert_id and therefore the test fails with an OCSP response generated with SHA256 hashed cert_id:

s2n-tls/tls/s2n_x509_validator.c

Lines 877 to 879 in ff03b94

    
           /* sha1 is the only supported OCSP digest */ 
        
           OCSP_CERTID *cert_id = OCSP_cert_to_id(EVP_sha1(), subject, issuer); 
        
           RESULT_ENSURE_REF(cert_id);

There is no explicit mention of enforcing SHA1 in OCSP RFC

Solution:

Investigate why only SHA1 is supported for OSCP digest, and consider adding support for other hash algorithms.
If we decide not to implement them, document the reasons.

Requirements / Acceptance Criteria:

What must a solution address in order to solve the problem? How do we know the solution is complete?

Out of scope:

Is there anything the solution will intentionally NOT address?

I was not able to find relevant conversation on why we only support SHA1 for cert_id hashing algorithm. Here, I documented my investigation.

What is cert_id used for?

The cert_id field in the OCSP response file is used to uniquely identify the certificate whose status is being queried. It is used to ensure that the correct certificate is being checked for its validity status.

How it is used:

Relevant code here

During OCSP request, when a client wants to check the status of a certificate, it sends an OCSP request containing the cert_id to the OCSP responder
The OCSP responder processes the request and generates a response that includes the status of the certificate identified by the cert_id. The status can be either "good", "revoked", or "unknown"
The client then validates the response to determine the certificate status

Impact of compromised `cert_id`

Since SHA-1 is vulnerable to collision attacks, an attacker could create a different certificate that produces the same cert_id hash values. This could potentially allow the attacker to obtain a valid OCSP response for a fraudulent certificate. However, other security measures in the TLS protocol mitigate potential risks:

By default, OCSP responses are signed using SHA256WithRSA. This ensures that even if an attacker can forge a cert_id, they cannot impersonate the OCSP responder without the responder's private key.
The client performs additional checks on the certificate chain and the validity of the certificates involved, further reducing the risk of fraud.

Recommended action

SHA-1 has been adequate for uniquely identifying certificates in most scenarios, which is likely why it remains the default hashing algorithm in OpenSSL's OCSP feature (OpenSSL Documentation). While there is an option to specify a different hashing algorithm, we currently do not recognize any significant customer demand for this.

~~If customer needs it, we can consider adding support for other hashing algorithms, such as SHA-256.~~

It will be a poor user experience if an OCSP response happens to use a hashing algorithm other than SHA-1, as it will fail with an error message "CERTIFICATE UNTRUSTED" even when the certificate is actually valid. Therefore, we should look to support known hashing algorithms for the OCSP cert_id field to prevent such issues and ensure robust and flexible security practices for our users.

	/* sha1 is the only supported OCSP digest */
	OCSP_CERTID *cert_id = OCSP_cert_to_id(EVP_sha1(), subject, issuer);
	RESULT_ENSURE_REF(cert_id);