Seamless Kernel-Based Non-Human Identity with kTLS and SPIFFE

Modern infrastructure requires strong, scalable, and transparent identity mechanisms - especially for non-human actors like services, workloads, jobs, or agents. Riptides is a novel approach that anchors non-human identity at the kernel level, leveraging SPIFFE, kTLS, and in-kernel mTLS handshakes to offer zero-intrusion security (identity and encrypted communication) for user-space applications.

In this post, we’ll walk through how Riptides works, why kTLS is a game-changer for performance and security, and why this effort lives in the kernel rather than in eBPF.

What is Riptides?

Riptides is an identity platform purpose-built to deliver seamless, policy-based identity for non-human workloads. At the heart of the system is the riptides-driverkernel module that integrates directly into the Linux TCP stack. It intercepts TCP connection establishment and performs mutual TLS (mTLS) handshakes entirely within the kernel, together with kTLS record encryption. These handshakes are guided by identity and authorization policies defined in a central Riptides control plane.

To bridge user space and kernel space, Riptides uses a dedicated user-space daemon. This communicates with the kernel module via device driver communication, synchronizing policies, trust bundles, and secrets down to the kernel. The result is a system where applications continue to open plain TCP connections as usual, while Riptides transparently upgrades those connections to authenticated and encrypted mTLS sessions. The application code remains unchanged, while security, identity enforcement, and observability are handled entirely beneath it, without even redeployment.

Why kTLS?

kTLS (Kernel TLS) is a Linux kernel feature that offloads TLS record encryption/decryption to the kernel. Handshakes still have to be done in user-space, so applications need to maintain the TLS sessions themselves. kTLS offers several advantages:

• Performance: Avoids costly user/kernel context switches for each TLS record, improving throughput and reducing CPU usage.
• Zero-copy: Enables efficient data paths by combining TLS with sendfile() and splice().
• Offloading: Makes it easier to offload TLS operations to NICs that support TLS hardware acceleration.
• Security surface: Minimizes the attack surface by keeping TLS state within the kernel.

While traditionally used purely for performance, Riptides leverages kTLS in a novel way — using it for record encryption while performing the entire TLS handshake separately in the kernel. This allows the full TLS connection to be established transparently, so applications remain completely unaware of the mTLS process.

A Brief History of kTLS

Historically, the concept and the initial practical exploration of kernel-level TLS offload were first associated with FreeBSD, driven by Netflix. Their research and prototyping in 2015 and onwards demonstrated the significant performance benefits of moving TLS processing into the kernel, especially for high-bandwidth applications.

Inspired by this work on FreeBSD by Netflix, the Linux community then introduced the concept and began its own independent development of kTLS for the Linux kernel. Dave Watson from Facebook was instrumental in initiating this effort in late 2015, leading to its inclusion in Linux kernel 4.13. Since then:

• Receive (RX) support was added.
• TLS 1.3 capabilities have been gradually integrated.
• Major distros and cloud vendors began including kTLS in production-ready kernels by default.
• Hardware vendors like Mellanox/NVIDIA and Intel provide NICs with kTLS offload support.

OpenSSL ships kTLS for end-users

While the major OS distributions eventually shipped kernels with kTLS support, it took significant effort for users to actually establish kTLS sessions in real-world applications. OpenSSL integrated support for kTLS in version 1.1.1, with enhanced functionality in OpenSSL 3.x. This allows applications using OpenSSL to leverage kTLS automatically, assuming proper kernel support and configuration.

Several well-known projects and services have explored or integrated kTLS. For example, nginx supports kTLS when built with OpenSSL and properly configured, enabling zero-copy TLS for improved performance for the sendfile operation. HAProxy has seen experimentation and community proof-of-concepts around kTLS integration. The Apache HTTP Server (httpd) project has also explored support, and although not widely deployed yet, interest continues to grow. curl for example also supports kTLS but as you can see it takes effort to maintain and implement it in applications. This is where Riptides comes into picture.

Why Riptides Embraces kTLS

Riptides, by moving the entire mTLS handshake into the kernel transforms kTLS from a performance optimization into a security boundary, enabling:

• Fully transparent, in-kernel mTLS handshakes.
• SPIFFE-based identity negotiation with no user-space exposure.
• Reduced secret sprawl and fewer context switches.
• Less kernel code to maintain, since we rely on an established, battle-tested kernel TLS implementation rather than building cryptographic primitives or protocol logic ourselves.

By employing the existing kTLS infrastructure, Riptides benefits from the continued evolution, optimization, and security hardening of the kernel’s TLS stack — reducing maintenance burden, increasing confidence in the correctness of the implementation, and enabling compatibility with modern NICs that support TLS hardware offload for even greater performance gains.

Why Not eBPF?

You might ask: “Why is this not an eBPF program?” (Or perhaps even multiple programs?) While eBPF is excellent for observability, packet filtering, traffic shaping, and lightweight decision-making close to the network layer, it is fundamentally unsuited for managing TLS handshakes or cryptographic state machines.

First, eBPF programs are subject to strict verifier constraints — such as limitations on loops, recursion, and stack depth — which make it impractical to implement complex protocols like TLS. Additionally, TLS involves intricate memory management and timing-sensitive operations that are simply not feasible within the eBPF execution model. Even maintaining persistent cryptographic state across connection events is difficult to do safely and efficiently in eBPF.

As a result, Riptides opts for a full kernel module implementation, where cryptographic and policy logic can operate with the necessary performance, safety, and architectural flexibility.

Riptides Architecture: Full Kernel Handshake + SPIFFE

Once Riptides is installed, the system operates transparently and automatically at the kernel level, the steps are the following:

1. The Riptides user-space daemon receives SPIFFE identities, trust bundles, and connection policies from the control plane.
2. These are loaded into the kernel module via device driver communication.
3. When a TCP connection is initiated, the driver:
   • Checks the destination against policy.
   • Initiates a full mTLS handshake (not just record protection) in the kernel using SPIFFE-based certificates.
   • Establishes a kTLS session for record encryption/decryption.

This design has multiple benefits:

• Security: Secrets never leave kernel memory, reducing exposure.
• Transparency: Applications are unaware they’re speaking mTLS - zero code changes.
• Policy enforcement: Fine-grained identity-based access control happens at connection time.

Conclusion

Riptides effectively acts as a programmable, identity-aware TCP stack for your applications - with no impact to application logic, it brings application identity to the kernel. This setup ensures that all outbound connections are policy-compliant, cryptographically secure, and identity-aware, without additional application code or TLS logic in user space. The system runs silently and efficiently underneath, maintaining security guarantees and reducing complexity for developers and operators alike.

If you’re building distributed systems and are seeking robust security without added complexity, Riptides presents an elegant and forward-looking solution worth following closely.

Some interesting reads in the topic:

• https://lwn.net/Articles/666509/
• https://netdevconf.info/0x12/session.html?kernel-tls-handshakes-for-https-ddos-mitigation
• https://freebsdfoundation.org/end-user-stories/netflix-case-study/

‍