tests: Integrationv2 Openssl provider might need versioning

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:

While adding Openssl3 libcrypto to the nix devShell, observed that many integration tests, and happy_path specifically, fail under nix, while passing on our standard Ubuntu18 image.

On ubuntu18, even when we build s2n-tls against openssl3, we're testing using the openssl 1.1.1 binary for s_client. Testing under nix with the openssl3 binary for s_client fails. We may need to create a new test provider for openssl3 and make sure our flags and interaction with s_client are version aware.

246: [gw0] [  2%] FAILED test_happy_path.py::test_s2n_server_happy_path[RSA_1024_SHA256-TLS1.1-P-256-S2N-OpenSSL-DHE-RSA-AES128-SHA]

s2nd launched with:

246: Command line: s2nd -X --self-service-blinding --non-blocking --key ../pems/rsa_1024_sha256_client_key.pem --cert ../pems/rsa_1024_sha256_client_cert.pem --insecure -c test_all_tls12 -T localhost 8216openssl: stdout available
246:
246: Exit code: 255
246: Stdout: Listening on localhost:8216

s_client launched with:

246: Command line: openssl s_client -connect localhost:8216 -debug -tlsextdebug -state -tls1_1 -cipher DHE-RSA-AES128-SHA -curves P-256
246: Exit code: 1

Solution:

WIP

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?

Stderr: SSL_connect:before SSL initialization
SSL_connect:SSLv3/TLS write client hello
SSL_connect:SSLv3/TLS write client hello
Can't use SSL_get_servername
SSL_connect:SSLv3/TLS read server hello
depth=0 C = US, ST = WA, L = Seattle, O = Amazon, OU = s2n, CN = localhost
verify error:num=18:self-signed certificate
verify return:1
depth=0 C = US, ST = WA, L = Seattle, O = Amazon, OU = s2n, CN = localhost
verify return:1
SSL_connect:SSLv3/TLS read server certificate
SSL3 alert write:fatal:internal error
SSL_connect:error in error
20D4AF86FFFF0000:error:0A00014D:SSL routines:tls_process_key_exchange:legacy sigalg disallowed or unsupported:ssl/statem/statem_clnt.c:2254:

It looks like this is probably a result of OpenSSL 3.0 disabling a number of legacy parameters.

When I restricted the Protocols to TLS 1.2 and TLS 1.3 the happy path test successfully completed with OpenSSL 3.0.8 as a provider.

aws / s2n-tls