Kernel TLS Offload Crates Move Under rustls Organization
Two years after starting work on ktls and ktls-sys, a pair of crates that expose Kernel TLS offload (kTLS) to Rust, the projects are being adopted into the rustls GitHub organization. The move is intended to keep the crates better synchronized with rustls releases.
kTLS hands off encryption, framing, and related connection work to the kernel and any supporting network interface — but only after a TLS connection is established. The handshake phase (hellos, cipher negotiation, certificate verification, and so on) still requires a userland TLS implementation. In Rust, that has typically meant rustls, which received a favorable security audit in 2020. The higher-level ktls crate therefore depends on rustls.
Working Around rustls's Key Secrecy
Using rustls as the handshake layer presented an early complication: to let the kernel continue encryption where rustls leaves off, the crate must handle any data rustls has already decrypted (TLS frames, TCP segments, and buffer contents from read/recvmsg don't necessarily align). It also has to extract session keys and sequence numbers, which rustls deliberately keeps well hidden.
The exact data to export depends on the cipher in use. Finding an API design acceptable to both the rustls maintainers and the ktls author took time — the work began two years ago in a rustls pull request and landed in the library in under a month.
// The ktls API takes a rustls ClientConnection or ServerConnection
// (kTLS works in either direction) and returns a TcpStream plus a Vec<u8>
// of already-decrypted data.Current API Shape
Today, ktls's API accepts a rustls ClientConnection or ServerConnection and returns a TcpStream along with a Vec<u8> containing already-decrypted data. An example from loona, an HTTP/1+2 implementation, demonstrates the usage.
Release Synchronization Benefits
rustls evolves with occasional API changes as better interfaces are found. With each new version, dependent crates such as tokio-rustls and ktls require updates to stay compatible. In the past, there have been multi-month gaps between rustls updates and corresponding tokio-rustls releases. After a recent complaint about that lag, the rustls maintainers responded that both packages now live under the same GitHub organization and that coordinated releases are expected going forward. They offered the same arrangement for ktls, which would allow simultaneous releases of rustls, tokio-rustls, and ktls.
The rustls org's Dirkjan made the adoption offer. The ktls author will remain involved to address whatever comes up.
