openssl-3.0-fips does not support RSA 1024 certs

[lrstewart]

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:

s2n-tls does not support RSA 1024 certs when built with openssl-3.0-fips. The fips provider will refuse to sign (and probably verify, although I didn't check that) with an RSA 1024 certificate.

Need By Date:

No known need by date

Solution:

We already retrieve non-fips hash algorithms from the non-fips provider when signing:

s2n-tls/crypto/s2n_evp_signing.c

Lines 75 to 92 in 178c48b

	static EVP_PKEY_CTX *s2n_evp_pkey_ctx_new(EVP_PKEY *pkey, s2n_hash_algorithm hash_alg)
	{
	PTR_ENSURE_REF(pkey);
	switch (hash_alg) {
	#if S2N_LIBCRYPTO_SUPPORTS_PROVIDERS
	/* For openssl-3.0, pkey methods will do an implicit fetch for the signing
	* algorithm, which includes the hash algorithm. If using a legacy hash
	* algorithm, specify the non-fips version.
	*/
	case S2N_HASH_MD5:
	case S2N_HASH_MD5_SHA1:
	case S2N_HASH_SHA1:
	return EVP_PKEY_CTX_new_from_pkey(NULL, pkey, "-fips");
	#endif
	default:
	return EVP_PKEY_CTX_new(pkey, NULL);
	}
	}

I think we could also switch to the non-fips provider when signing with a non-fips key like RSA 1024, but that would require us to know the size of the key at that point. Libcrypto methods exist to retrieve that info (EVP_PKEY_get_bits, I think?), but we don't currently call them.

Make sure you update the integration tests. They currently skip openssl-3.0-fips + RSA-1024. You can search for this issue link to find the skips.

• Does this change what S2N sends over the wire? If yes, explain.
• Does this change any public APIs? If yes, explain.
• Which versions of TLS will this impact?

Requirements / Acceptance Criteria:

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

• RFC links: Links to relevant RFC(s)
• Related Issues: Link any relevant issues
• Will the Usage Guide or other documentation need to be updated?
• Testing: How will this change be tested? Call out new integration tests, functional tests, or particularly interesting/important unit tests.
  • Will this change trigger SAW changes? Changes to the state machine, the s2n_handshake_io code that controls state transitions, the DRBG, or the corking/uncorking logic could trigger SAW failures.
  • Should this change be fuzz tested? Will it handle untrusted input? Create a separate issue to track the fuzzing work.

Out of scope:

Is there anything the solution will intentionally NOT address?