OCSP digest support for SHA-256

[samuel40791765]

Problem:

SHA1 seems to be the only OCSP digest supported by s2n: https://github.com/aws/s2n-tls/blob/main/tls/s2n_x509_validator.c#L473-L478
However, the support for SHA1 in OCSP is a bit outdated. The latest OCSP RFC states that it's mandatory for clients that request OCSP services to be able to process responses signed using SHA-256.

Proposed Solution:

Update OCSP digest support to handle SHA-256.

• Does this change what S2N sends over the wire? No

• Does this change any public APIs? No

• Which versions of TLS will this impact? N/A

• RFC links:

  • Old OCSP RFC: https://datatracker.ietf.org/doc/html/rfc2560#section-4.3
  • Latest OCSP RFC: https://datatracker.ietf.org/doc/html/rfc6960#section-4.3

• Related Issues: https://shufflesharding.com/posts/improving-security-in-s2n

• Will the Usage Guide or other documentation need to be updated?

• Testing: Would need to update s2n unit tests to test against OCSP responses signed using SHA-256, along with new OCSP test files.

  • Will this change trigger SAW changes? Not sure
  • Should this change be fuzz tested? Not sure

[goatgoose]

I believe section 4.3 of RFC 6960 is referring to the signature algorithm used in the OCSP response:

Clients that request OCSP services SHALL be capable of processing
responses signed using RSA with SHA-256 (identified by the
sha256WithRSAEncryption OID specified in [RFC4055]).

s2n-tls does support this signature algorithm, and there is integration and unit test coverage via tests/pems/ocsp/ocsp_response.der:

❯ openssl ocsp -respin ocsp_response.der -text | grep "Signature Algorithm"
    Signature Algorithm: sha256WithRSAEncryption
        Signature Algorithm: sha256WithRSAEncryption
    Signature Algorithm: sha256WithRSAEncryption

The code linked in this issue is now here:

s2n-tls/tls/s2n_x509_validator.c

Lines 583 to 584 in e9f4c0a

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

This line constructs a certificate ID with the SHA-1 hash, which is not being used cryptographically.

I'm closing this issue for now, but please feel free to reopen it if there are further concerns.