SSLyze scans fail with some libcryptos

[goatgoose]

Problem:

Some SSLyze scans fail when building s2n-tls with various libcryptos. Many of these scans result with a "BUG_IN_SSLYZE" error. As such, it's possible that for some scans there is actually a bug in SSLyze. However, it should be determined if that is the case, or if there is a problem with s2n-tls or how the integration test is implemented.

The following are the errors seen in each libcrypto:

• All libcryptos
  • BUG_IN_SSLYZE errors from elliptic curve scans with ECDSA certificates
• All fips libcryptos
  • BUG_IN_SSLYZE errors / TLS version supported assertion failures for ECDSA scans in SSLv3 and RSA with TLS version < 1.2
  • BUG_IN_SSLYZE error in TLS compression and session renegotiation scans in when TLS version < 1.3
• openssl 1.0.2 fips
  • supports_ecdh_key_exchange assertion failed in elliptic curves scan
  • Cipher suite scan results in rejected ciphers that should have been accepted for TLS 1.2
  • BUG_IN_SSLYZE error for session resumption scan

The failing SSLyze tests are skipped in the integration test via functions passed to the uncollect_if pytest marks. Replace the functions passed here with the default invalid_test_parameters function, and rerun the test to replicate. This was run in Codebuild with openssl-1.0.2 fips, openssl 1.1.1, and awslc fips libcryptos. The log can be found here.

Solution:

• 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:

Ensure that any remaining SSLyze errors skipped in the integration test are not due to s2n-tls or the integration test implementation.

• 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?