However, this method is implemented on config::Builder so it is not available after the config is created.
Solution:
Workarounds
The one workaround that I can think of for this is using the ClientHello callback to always resolve to a "most recent" config. You would create a new config every hour with the rotation of the STEKs. This is not a pretty solution 😬
Code Changes
Ideally the add_session_ticket_key would be available on the config::Config.
should it take a &self or &mut self?
does it need to do any internal synchronization?
Clients currently have to implement rotation themselves, and I wonder if it might make sense to switch to something like rustls' ticketer api?
Requirements / Acceptance Criteria:
Customers should be able to rotate STEKs when using the bindings. I think as part of the acceptance criteria, we should add an example server with STEKs that rotate every hour.
Problem:
There is no obvious way to rotate STEK material when using s2n-tls through the rust bindings.
s2n_config_add_ticket_crypto_key
is exposed in the Rust bindings https://github.com/aws/s2n-tls/blob/933f379bb5aca82ac3fcc9687cdc83dba4c93a4c/bindings/rust/s2n-tls/src/config.rs#L672-L679However, this method is implemented on
config::Builder
so it is not available after the config is created.Solution:
Workarounds
The one workaround that I can think of for this is using the ClientHello callback to always resolve to a "most recent" config. You would create a new config every hour with the rotation of the STEKs. This is not a pretty solution 😬
Code Changes
Ideally the
add_session_ticket_key
would be available on theconfig::Config
.&self
or&mut self
?Clients currently have to implement rotation themselves, and I wonder if it might make sense to switch to something like rustls' ticketer api?
Requirements / Acceptance Criteria:
Customers should be able to rotate STEKs when using the bindings. I think as part of the acceptance criteria, we should add an example server with STEKs that rotate every hour.