fix: initial config should not influence sslv2

[jmayclin]

Resolved issues:

#4585

Description of changes:

This PR separate out parsing and processing for sslv2 formatted client hellos. Previously both items were handled by s2n_sslv2_client_hello_recv. Splitting these out into two functions allows us to

1. parse the sslv2 client hello without touching anything on the config
2. invoke the client hello callback
3. then process the sslv2 client hello (which requires touching the config)

Call-outs:

This code is basically stolen respectfully appropriated from an earlier draft of #4676 , so thanks @maddeleine!

Testing:

I added a unit test that confirms the config isn't de-referenced in the parsing of the SSLV2 client hello.

I also ran this test with the old code to confirm that it correct detects the issue. The code fails as expected.

263/274 Test  #58: s2n_config_test ..................................***Failed    5.58 sec
Running /home/ubuntu/workspace/s2n-tls/tests/unit/s2n_config_test.c ... NOTE: Some details are omitted, run with S2N_PRINT_STACKTRACE=1 for a verbose backtrace.
See https://github.com/aws/s2n-tls/blob/main/docs/usage-guide
FAILED test 2745
(s2n_errno) == (S2N_ERR_CONFIG_NULL_BEFORE_CH_CALLBACK) is not true  (/home/ubuntu/workspace/s2n-tls/tests/unit/s2n_config_test.c:1268)
Error Message: 'NULL pointer encountered'
 Debug String: 'Error encountered in /home/ubuntu/workspace/s2n-tls/tls/s2n_connection.c:703'
 System Error: Success (0)

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

[jmayclin]

conn->server_protocol_version is set to s2n_highest_protocol_version in s2n_connection_new. s2n_highest_protocol_version is either TLS 1.2 or TLS 1.3, depending on whether s2n_disable/enable_tls13_test functions have been used.

Previously

server_protocol_version was never modified for SSLv2 client hellos. This line was just asserting on s2n_highest_protocol_version which was toggled between test runs by s2n_disable/enable_tls13_test.

Proposed

server_protocol_version is now modified by this section in process_client_hello.

s2n-tls/tls/s2n_client_hello.c

Lines 535 to 538 in cc2ea72

	if (!s2n_connection_supports_tls13(conn) || !s2n_security_policy_supports_tls13(security_policy)) {
	conn->server_protocol_version = MIN(conn->server_protocol_version, S2N_TLS12);
	conn->actual_protocol_version = MIN(conn->server_protocol_version, S2N_TLS12);
	}

From my reading/audit of the codebase, server_protocol_version is mostly used for various checks and assertions related to downgrade protection. From the brief audit that I did, I didn't see any places that this would be a noticeable behavior change, but this part of the codebase is pretty new to me and our SSLV2 test coverage is pretty low ☹️

I'll also throw out that server_protocol_version being set to TLS13 while using SSLV2 client hellos seems suspicious given this RFC requirement

Implementations MUST NOT negotiate TLS 1.3 or later using an SSL version 2.0 compatible CLIENT-HELLO.
https://www.rfc-editor.org/rfc/rfc8446#appendix-D.5

Note: I think the code chunk above should just always be assigning S2N_TLS12. When I made that change, all the test cases continued to pass exception one of the renegotiate ones. Need to investigate further

[lrstewart]

server_protocol_version was never modified for SSLv2 client hellos

That's definitely a bug. Later code is going to assume that server_protocol_version was set properly, regardless of what it's currently used for.

But the TLS1.3 case not working makes sense. SSLv2 ClientHellos don't contain extensions, and the only way to negotiate TLS1.3 is via extension. Even if that wasn't the case, we're using a hard-coded ClientHello so s2n_disable/enable_tls13_test would have no effect on it.

So yes, your fix is correct. But it's arguable whether the two different test setups are even necessary. Yes, s2n_disable/enable_tls13_test would still affect the server itself, but we're only setting the "tls12_config" on the server. I think this test needs a little more attention.

[maddeleine]

Maybe just remove s2n_enable/disable_tls13_in_test() for this test? If we're explicitly setting the config then it's not necessary.

[jmayclin]

Thanks for the feedback. In the current revision I removed the toggling and removed the assertion on server_protocol_version, which was the main thing that was confusing in the first place. The goal of this test is to confirm that the client protocol version and the actual protocol version are correctly set, but we don't care about/don't expect this to affect the server protocol version.

Maybe just remove s2n_enable/disable_tls13_in_test()

I started doing this, but fixing all of the other tests in this file is going to be non-trivial. ☹️

[lrstewart]

Would it make more sense for this branching to happen in s2n_set_cipher_as_tls_server?

[jmayclin]

Yes, but it might be messy to do it in this PR.

s2n_set_cipher_as_tls_server would need to take in the length of the wire information rather than the count of cipher suites, which is gonna add ~ 60 lines of unit test diff to the PR. If you're fine with the noise then I can roll that into this.

[lrstewart]

Nah, sounds like it'd be better as a potential follow-up then.