Repository navigation
Support new rustls KernelConnection API, and thence TLS1.3 KeyUpdates #59
Description
Activity
I was planning on taking a shot at this once rustls/rustls#2370 ends up getting merged. I already have code written for a sync version, and translating that to async should be pretty straightforward. However, if you would prefer to do this yourself then that is fine as well and I'll hold off from making a PR.
Reacted by Hantong ChenReacted by Hantong ChenPlease do if you have work in flight!
Reacted by Sean Lynch and Hantong ChenCross-linking from a downstream consumer: I'm building Overdrive, which does transparent kernel mTLS (eBPF sockops + kTLS with per-workload SPIFFE SVIDs). TLS 1.3
KeyUpdatesupport here is the blocker for in-place SVID rekey on long-lived connections — without it, rotation falls back to teardown + reconnect when a workload's short-lived SVID expires. I'm tracking it at overdrive-sh/overdrive#229.The
rustls::kernelrewrite in #62 looks like the right path. Happy to help: I can test against real kTLS east-west workloads on a pinned 6.18 kernel, and review once it's split into smaller PRs. Is #62 still the active line of work, or would a smaller KeyUpdate-only PR on top of the current crate be preferred?Is #62 still the active line of work, or would a smaller KeyUpdate-only PR on top of the current crate be preferred?
I don't think there is an active line of work right now, the maintainers are also kind of busy with other stuff (working on rustls 0.24) so I'm not sure we'll be able to make progress on this in the short term.
Reacted by Marcus Schack
See rustls/rustls#2362 for background. I plan to work on this as part of integrating KTLS into https://github.com/rustls/rustls-openssl-compat.