-
Notifications
You must be signed in to change notification settings - Fork 739
Closed
Labels
Description
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:
Openssl-3.0-fips does not allow MD5 or SHA1, which also means it doesn't support TLS <1.2. We should just accept that limitation rather than try to work around it.
Solution:
We'll need to
- Remove existing openssl-1.0.2-fips special md5 "enable even if fips" logic 8d521fc
- Gate access to MD5 and SHA1 hashes with openssl-3.0-fips
- Enforce TLS1.2+ negotiation with openssl-3.0-fips
- Handle "non-core" use of MD5/SHA1:
- key check in s2n_ecdsa_keys_match
- JA3 (probably just disable for openssl-3.0-fips)
- 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?