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

s2n_connection_set_session shouldn't mutate on failure #4102

Closed
lrstewart opened this issue Jul 19, 2023 · 0 comments · Fixed by #4110
Closed

s2n_connection_set_session shouldn't mutate on failure #4102

lrstewart opened this issue Jul 19, 2023 · 0 comments · Fixed by #4110

Comments

@lrstewart
Copy link
Contributor

Problem:

When calling s2n_connection_set_session with a TLS1.2 ticket, we copy values like cipher suite and the master secret from the ticket to the connection: https://github.com/aws/s2n-tls/blob/main/tls/s2n_resume.c#L236-L252 This means that we mutate the connection even if s2n_connection_set_session fails.

There's a more minor version of the problem for TLS1.3, where on a failure we won't clear conn->client_ticket like we should: https://github.com/aws/s2n-tls/blob/main/tls/s2n_resume.c#L355C1-L361

Solution:

Rewrite the deserialization so that the connection isn't affected unless we actually successfully deserialize the ticket.

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

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