test(integration): add rust test for session resumption#5683
test(integration): add rust test for session resumption#5683kaukabrizvi merged 27 commits intoaws:mainfrom
Conversation
bindings/rust/standard/integration/src/features/session_resumption.rs
Outdated
Show resolved
Hide resolved
bindings/rust/standard/integration/src/features/session_resumption.rs
Outdated
Show resolved
Hide resolved
bindings/rust/standard/integration/src/features/session_resumption.rs
Outdated
Show resolved
Hide resolved
bindings/rust/standard/integration/src/features/session_resumption.rs
Outdated
Show resolved
Hide resolved
bindings/rust/standard/integration/src/features/session_resumption.rs
Outdated
Show resolved
Hide resolved
bindings/rust/standard/integration/src/features/session_resumption.rs
Outdated
Show resolved
Hide resolved
bindings/rust/standard/integration/src/features/session_resumption.rs
Outdated
Show resolved
Hide resolved
bindings/rust/standard/integration/src/features/session_resumption.rs
Outdated
Show resolved
Hide resolved
| harness::{TlsConfigBuilder, TlsInfo}, | ||
| Mode, SigType, TlsConnPair, | ||
| }; | ||
|
|
There was a problem hiding this comment.
I can think of three other one-off test cases that we should add: 1. resumption between an s2n client and s2n server, and 2. resumption with another cert type, like ecdsa, 3. using the same ticket to reconnect multiple times with a server.
There was a problem hiding this comment.
Agreed on (1) and (3) - I’ll add coverage for resumption between s2n↔s2n and for reusing the same ticket across multiple connections.
For the additional cert type, since the cert type itself doesn’t appear to materially affect session resumption behavior, I think it’s reasonable to just test with one cert type for now.
There was a problem hiding this comment.
In this PR, I think it'd also be worth adding
"when a server receives a valid session ticket that was encrypted under a different STEK, it gracefully falls back to a full handshake".
In a separate PR, we should also add some integration tests for our session-id based resumption ...
There was a problem hiding this comment.
I added a test for 'mismatched_stek_falls_back_to_full_handshake' and I can open an issue for session-id based reumption integ tests once this is merged.
bindings/rust/standard/integration/src/features/session_resumption.rs
Outdated
Show resolved
Hide resolved
bindings/rust/standard/integration/src/features/session_resumption.rs
Outdated
Show resolved
Hide resolved
bindings/rust/standard/integration/src/features/session_resumption.rs
Outdated
Show resolved
Hide resolved
| const PROTOCOL_VERSIONS: &[SslVersion] = &[ | ||
| SslVersion::TLS1_2, | ||
| SslVersion::TLS1_1, | ||
| SslVersion::TLS1, |
There was a problem hiding this comment.
🙋 I'm confused.
Not about your code, but how does TLS 1.0 session ticket based resumption work? I never stopped to think about this, but I thought that TLS 1.0 client hellos didn't include extensions? So it shouldn't be able to supply a NST extension ...
I'm guessing that even in the "only supports" TLS 1.0 case, we're still including extensions? And the server is still reading them? Which is fascinating, and bizarre ...
There was a problem hiding this comment.
Yes, it is interesting. Since TLS 1.0 can support optional extensions, I guess it is able to send the session ticket extension and the server picks up on it.
bindings/rust/standard/integration/src/features/session_resumption.rs
Outdated
Show resolved
Hide resolved
bindings/rust/standard/integration/src/features/session_resumption.rs
Outdated
Show resolved
Hide resolved
| harness::{TlsConfigBuilder, TlsInfo}, | ||
| Mode, SigType, TlsConnPair, | ||
| }; | ||
|
|
There was a problem hiding this comment.
In this PR, I think it'd also be worth adding
"when a server receives a valid session ticket that was encrypted under a different STEK, it gracefully falls back to a full handshake".
In a separate PR, we should also add some integration tests for our session-id based resumption ...
Goal
Add Rust integration tests that validate TLS session resumption when OpenSSL is used as the peer, covering both s2n-tls client and s2n-tls server roles across supported protocol versions.
Why
We are migrating coverage from IntegV2 to the Rust-based integration test suite. Session resumption is a critical code path, so we want explicit, peer-validated coverage.
How
The Rust tests replicate the behavioral intent of the existing IntegV2 resumption tests so that it can be safely deprecated:
Positive resumption paths:
Mixed-version behavior:
Negative / fallback behavior
Callouts
This change relies on a small OpenSSL extension (
SslStreamExtension::mut_ssl) to obtain a mutableSslReffromSslStream. This is required for exercising OpenSSL session resumption behavior in Rust integration tests. An upstream PR to expose this safely exists (rust-openssl/rust-openssl#2223); until that lands, this PR has a minimal workaround scoped to test-only usage.Testing
This is a test, it runs in the PR workflow as part of the IntegRustNix batch. As this PR covers the behavioral cases previously validated by the corresponding IntegV2 session resumption tests, those IntegV2 tests are removed as part of this change.
Related
N/A
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.