Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tracking issue: Update "default" and "default_fips" to support TLS1.3 #4765

Open
3 of 9 tasks
toidiu opened this issue Sep 11, 2024 · 0 comments
Open
3 of 9 tasks

Tracking issue: Update "default" and "default_fips" to support TLS1.3 #4765

toidiu opened this issue Sep 11, 2024 · 0 comments

Comments

@toidiu
Copy link
Contributor

toidiu commented Sep 11, 2024

Security issue notifications

As a modern TLS library, s2n-tls aims to provide sane and safe default. The goal of this task is to add TLS1.3 support to the "default" and "default_fips" policies.

Solution: add a TLS 1.2 CI job

To de-risk the loss of TLS 1.2 coverage, this solution will add a new TLS 1.2 test to our CI. This new job will toggle the default policy to TLS 1.2 and execute all unit tests. Since this will be a single job, we will lose some coverage (platform, feature probing, libcrypto), but we expect this to be an acceptable risk.

Project plan:

  • Set up a single GeneralBatch job which tests with a default TLS 1.2 policy. This will preserve majority of the current testing behavior when TLS 1.3 becomes the default. However, due to conditional compilation/feature probing (libcrypto, platform), this does sacrifice some code coverage. We consider this an acceptable risk.
  • Add TLS1.3 support to the "default" and "default_fips" policies

Post MVP:

  • script to clean up double instances of s2n_config_set_cipher_preferences after auto gen script
 s2n_config_set_cipher_preferences(client_config, s2n_auto_gen_old_default_security_policy());
 s2n_config_set_cipher_preferences(client_config, "20170210");

Solution: Pin to number policy:

Solution not implemented due to new findings
This solution was attempting to pin TLS-1.2-tests to the numbered equivalent "20240501". However, we also have tests that actually want to test the "default" policy. ("default"-policy-tests), and should not be pinned. There is no easy way to detect "default"-policy-tests vs TLS-1.2-tests, which means so we cannot implement this solution.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants