add unit test for decyption of future keys #4095
Conversation
|
|
||
| /* Client sends non-empty ST extension. Server does an abbreviated handshake without issuing NST. */ |
There was a problem hiding this comment.
Can you give this test a better name? This comment should describe the scenario you're trying to test. So something like "Server can decrypt session ticket with key before the key's introduction time, but will not issue new ticket".
I'm also wondering if this test is overkill. Maybe we don't need a full self-talk test. If you don't care about the actual handshake (like how the client and server exchange tickets / issue new tickets), and you're only interested in whether the ticket can be decrypted, you could probably just test s2n_decrypt_session_ticket directly (in s2n_resume_test.c)
There was a problem hiding this comment.
Will do on the naming.
And I can move the test to s2n_decrypt_session_ticket, but I don't know that it ends up being simpler.
For those tests the server is issuing the tickets, so I either need two separate configs with different key configurations (and therefore need two different connections) or I need to do some time-reversal black-magic clock-mockery to test my "decrypt before encryption time". Out of those options, I think I prefer the multiple config approach. Thoughts?
| EXPECT_SUCCESS(s2n_config_free(resuming_config)); | ||
| } | ||
|
|
||
| /* Server can decrypt session ticket with key before the key's introduction time */ |
There was a problem hiding this comment.
I like this option better, but it feels weird to be swapping out the config for a connection?
|
This PR has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
|
This PR has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
Description of changes:
This PR adds a unit test that confirms a session ticket can be decrypted even if it's encryption key has not yet reached it's intro time. This is useful in distributed systems scenarios where clock skew prevents precise synchronization of key usage. By adding a STEK to the
s2n-tlsconfig far before it'sintroTime, endpoints can neatly deal with the clock skew issue.Testing:
There is no new behavior being added, just a unit test to confirm current behavior, and prevent any changes to the current behavior.
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.