refactor: remove openssl-1.0.2-fips 'allow md5' logic

[lrstewart]

Release Summary:

Resolved issues:

related to #5045. We need to cleanup the old mess before we add a new mess.

Description of changes:

I remove the s2n_hash_allow_md5_for_fips, s2n_digest_is_md5_allowed_for_fips, and s2n_digest_allow_md5_for_fips methods because after the removal of openssl-1.0.2-fips support, they're not actually doing anything. I explain more in in-line comments, but:

• s2n_hash_allow_md5_for_fips and s2n_digest_allow_md5_for_fips are a no-op for every libcrypto except openssl-1.0.2-fips
• s2n_digest_is_md5_allowed_for_fips is mostly just used to gate calls to *_allow_md5_for_fips

Call-outs:

if you search for the removed methods, you'll still find references in the CBMC proofs. To keep this PR reviewable, I'm going to clean those up as a follow-up, since they don't affect testing.

Testing:

Existing tests continue to pass. I only needed to update one unit test, and I explain why in-line.

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

[lrstewart]

This translates to "if openssl+fips, call an API to allow md5". With the removal of openssl-1.0.2-fips, we no longer support openssl+fips, and this is a no-op. I've removed it everywhere it appears.

[jouho]

Does Openssl-3-fips support the use of md5? Just want to make sure we won't need to add any of these logic back when we add support for openssl-3-fips

[lrstewart]

openssl-3.0-fips doesn't support the use of md5, or a couple other options. But openssl-3.0 also doesn't support enabling MD5 this way. There's no overlap between how openssl-3.0 does fips and how openssl-1.0.2 did fips. We can't reuse the openssl-1.0.2-fips logic, so it's cleaner to just tear it out where we find it. And this particular logic is way more complicated / deceptive than it needs to be anyway.

[lrstewart]

This one's a bit trickier. It roughly translates to:

if not fips: false
If openssl+fips: maybe true
If awslc+fips: true

So with the removal of openssl+fips via openssl-1.0.2-fips, this method boils down to "is fips?".

We only use this method for two purposes (see search):

• Gate calls to s2n_hash_allow_md5_for_fips: unnecessary since s2n_hash_allow_md5_for_fips is a no-op
• Decide whether or not to initialize a handshake hash: unnecessary because of refactor: remove openssl-1.0.2-fips 'allow md5' logic #5048 (comment). Basically, we check "is not fips, or is fips".

[lrstewart]

If I delete this file, I have to update ALL of the s2n_hash CBMC proofs because they all declare it as a source file. It's unnecessary noise, so I'd prefer to do it in a follow-up PR: fe97ffa

[lrstewart]

This was not really true even before this change. You could use md5 with fips in awslc, just not in openssl-1.0.2. So whenever we checked s2n_hash_is_available and got "false" because of fips, we'd then check s2n_digest_is_md5_allowed_for_fips and get "true", overriding the original "false". I'm just skipping straight to the final "true".

You can confirm the limited non-test usage of this method: https://github.com/search?q=repo%3Aaws%2Fs2n-tls+s2n_hash_is_available+-path%3A*tests%2Funit%2F*.c&type=code

[jouho]

Since we are here, can we also update this comment to reflect the current behavior?
The handshake MD5 hash state will fail the s2n_hash_is_available() check since MD5 is not permitted in FIPS mode is no longer correct

s2n-tls/tls/s2n_handshake_transcript.c

Lines 50 to 55 in 431f014

	/* The handshake MD5 hash state will fail the s2n_hash_is_available() check
	* since MD5 is not permitted in FIPS mode. This check will not be used as
	* the handshake MD5 hash state is specifically used by the TLS 1.0 and TLS 1.1
	* PRF, which is required to comply with the TLS 1.0 and 1.1 RFCs and is approved
	* as per NIST Special Publication 800-52 Revision 1.
	*/

[lrstewart]

This test just kept using the hashes initialized to whatever hash algorithm was set last in the loop above, which just happens to be sha512 (the md5+sha1 was previously skipped). I kept the sha512 "choice", but made it explicit.

[lrstewart]

Instead of just skipping the md5 algorithms, I checked that they really aren't supported so that we can't lose valid coverage.