By Anurag Vishwakarma in Linux — Aug 28, 2025

What is Kernel TLS (kTLS) and Why Offload TLS to the Kernel or NIC?

Kernel TLS (KTLS) moves TLS encryption from user space into the Linux kernel or even the NIC. Offloading reduces CPU overhead, enables zero-copy I/O, and boosts performance for high-throughput applications.

Photo by Plufow Le Studio / Unsplash

Most applications today handle TLS encryption in userspace, which creates performance bottlenecks that many developers don't realize exist. When your web server processes HTTPS requests or your API handles secure connections, every byte of encrypted data requires CPU-intensive cryptographic operations performed by your application process.

This approach works, but it leaves performance on the table. Linux Kernel TLS (kTLS) offers a better way by moving TLS operations closer to the hardware, potentially freeing up significant CPU resources for your actual application logic.

What’s the Difference Between Kernel Space and User Space in Linux?

Linux User Space vs Kernel Space — Image Source : Redhat

In Linux, the kernel is the core of the operating system. It manages hardware like the CPU, memory, and network devices, and provides the low-level services everything else relies on. User space is where normal applications run something like web servers, browsers, databases but they can’t touch hardware directly. Instead, they must go through the kernel using system calls.

How TLS Currently Works in Most Applications ?

Before we start with understanding kernel TLS, let's understand the traditional TLS handshake flow. When your application handles a secure connection:

TCP connection establishes normally
Your application performs the TLS handshake using libraries like OpenSSL
For every request/response, your application encrypts outgoing data and decrypts incoming data
Data gets copied between kernel space and userspace multiple times

This creates two main performance issues:

CPU overhead: Your application spends cycles on cryptography instead of business logic
Memory copies: Data moves between kernel and user space multiple times

Understanding Kernel TLS Options

Linux Kernel TLS provides three different approaches to handle TLS operations more efficiently. Each mode addresses different performance requirements and hardware capabilities.

1. Software Crypto Mode (TLS_SW)

In software mode, the kernel takes over TLS encryption and decryption instead of your application doing it, but still uses the host CPU for cryptographic operations.

How it works:

Your application performs the TLS handshake (for certificate validation and key exchange)
Once established, you provide the encryption keys to the kernel
The kernel handles all subsequent encryption/decryption automatically
All crypto operations happen in kernel space using the host CPU

What changes for your application ?

write() calls: You write plain text, kernel encrypts it
read() calls: Kernel decrypts data before giving it to you
Performance impact: You still use CPU for crypto, but kernel-level operations are more efficient than userspace libraries

2. Packet-based NIC Offload Mode (TLS_HW)

Hardware mode moves TLS operations to your network interface card (NIC). Modern enterprise NICs include processors specifically designed for cryptographic operations.

Benefits:

CPU freedom: Your main CPU never touches cryptographic operations
Faster reads: Data arrives already decrypted
Better scaling: Handle more connections with the same CPU resources

Requirements:

NIC must support TLS offload capabilities
Hardware checksum offload must be enabled
Packets must arrive in order for proper crypto state management

3. Full TCP NIC Offload Mode (TLS_HW_RECORD)

The most aggressive option lets your NIC handle both TCP connection management and TLS operations entirely. The NIC firmware completely replaces the kernel networking stack for offloaded connections.

Benefits: Maximum throughput for pure data transfer scenarios
Limitations: You lose Linux networking features like iptables, traffic shaping, and packet filtering

This mode works best for dedicated high-throughput applications where you don't need advanced networking features. It's essentially creating a hardware-accelerated bypass of the entire Linux networking stack.

Zero-Copy Operations: A Practical Example

One of the most significant advantages of kernel TLS is enabling zero-copy operations, which can dramatically improve performance for data-intensive applications.

To understand the impact, let's examine a real-world scenario: a file upload service handling large files.

The Problem with Traditional TLS

In traditional userspace TLS implementations, every byte of data must pass through multiple layers and memory copies. When a client uploads a 1GB file to your server:

Network Reception: Encrypted data arrives at your network interface
Kernel Copy: Data gets copied from network buffers to socket buffers
Userspace Copy #1: Your application reads the encrypted data (copy from kernel to userspace)
CPU Decryption: Your application's TLS library decrypts the data using CPU cycles
Userspace Copy #2: Your application writes the decrypted data back to kernel for file operations
File Write: Kernel writes the data to disk

This process results in:

2+ memory copies between kernel and userspace
High CPU utilization for cryptographic operations
Memory bandwidth waste (processing ~2GB of data to store 1GB)
Context switching overhead between kernel and userspace

The kTLS Zero-Copy Advantage

With kernel TLS hardware offload, the entire data flow changes fundamentally:

Hardware Decryption: Your NIC's crypto processor decrypts data as it arrives
Direct DMA: Decrypted data goes directly to kernel memory via DMA
Zero-Copy Transfer: Application uses sendfile() or splice() system calls
Direct File Write: Kernel writes directly from socket buffer to disk

The result: Your application never touches the actual file data, and your CPU never performs cryptographic operations.

Some Real-World Performance Impact

1. Web Servers

Before kTLS: Each HTTPS connection consumes CPU cycles for every encrypted byte processed
With kTLS: CPU focuses entirely on application logic, handling more concurrent connections

2. File Transfer Services

Before kTLS: Large file uploads bottlenecked by encryption overhead and memory copies
With kTLS: Near-native file transfer speeds with full encryption

3. API Gateways

Before kTLS: TLS termination creates CPU hotspots under heavy load
With kTLS: Linear scaling with hardware-accelerated crypto operations

Checking if Hardware/NIC Support kTLS

You need to verify that your network interface card (NIC) has the necessary hardware capabilities for TLS offload. Not all network cards support hardware TLS acceleration, and the level of support varies significantly between vendors and models.

NIC TLS Offload Capabilities

Modern enterprise network cards include dedicated processors and crypto engines that can handle TLS operations independently of your host CPU. However, support varies across three levels:

No TLS Support: Basic NICs without any TLS acceleration
Partial TLS Support: NICs that support some TLS operations (TX only, or specific cipher suites)
Full TLS Support: Enterprise NICs with complete hardware TLS offload capabilities

Step 1: Identify Your Network Hardware

Start by identifying your network interface hardware and current capabilities:

# List all network interfaces
ip link show

# Get detailed information about your ethernet controller
lspci | grep -i ethernet
# Example output: 02:00.0 Ethernet controller: Intel Corporation X710 for 10GbE SFP+ (rev 02)

# Get comprehensive PCI device information
lspci -vv | grep -A 25 "Ethernet controller"

# Check current driver information
ethtool -i eth0
# Look for driver name, version, and firmware version

Step 2: Check Current TLS Offload Status

Verify what TLS features your NIC currently supports and their status:

# Check TLS-specific offload features
ethtool -k eth0 | grep tls
# Expected output shows three key features:
# tls-hw-tx-offload: off [fixed] or on/off
# tls-hw-rx-offload: off [fixed] or on/off  
# tls-hw-record: off [fixed] or on/off

# View all available offload features
ethtool --show-offload eth0

# Check hardware features in detail
ethtool --show-features eth0 | grep -E "(tls|csum|gso|gro)"

Understanding the output:

on: Feature is enabled and working
off: Feature is disabled but can be enabled
[fixed]: Feature cannot be changed (usually means not supported by hardware)
[requested on]: Feature was requested but couldn't be enabled

Step 3: Hardware Compatibility Database

Check if your specific NIC model supports TLS offload:

# Get exact NIC model and vendor information
lspci -nn | grep -i ethernet
# Example: 02:00.0 Ethernet controller [0200]: Intel Corporation X710 for 10GbE SFP+ [8086:1572]

# Check driver module information for TLS support
modinfo $(ethtool -i eth0 | grep driver | awk '{print $2}') | grep -i tls

# Verify driver version supports TLS features
ethtool -i eth0 | grep -E "(driver|version|firmware)"

Known TLS-Capable Hardware

Intel Network Cards:

# Intel X700 series (X710, X722) - i40e driver
# Check for Intel X710/X722 support:
lspci | grep -E "(X710|X722|82599)"

# Intel E800 series (E810) - ice driver  
# Check for Intel E810 support:
lspci | grep E810

Mellanox/NVIDIA ConnectX Series:

# ConnectX-5, ConnectX-6 series - mlx5_core driver
# Check for Mellanox cards:
lspci | grep -i mellanox

# Verify ConnectX model:
lspci -vv | grep -A 10 -i mellanox | grep "Part number"

Broadcom NetXtreme Series:

# NetXtreme-E series - bnxt_en driver
# Check for Broadcom cards:
lspci | grep -i broadcom

Step 4: Test Hardware TLS Capabilities

Attempt to enable TLS offload features to verify hardware support:

# Test if TLS TX offload can be enabled
sudo ethtool -K eth0 tls-hw-tx-offload on
echo "TX Offload test: $?"

# Test if TLS RX offload can be enabled  
sudo ethtool -K eth0 tls-hw-rx-offload on
echo "RX Offload test: $?"

# Check the results
ethtool -k eth0 | grep tls

# Look for any error messages
dmesg | tail -5

Interpreting results:

Success (return code 0): Hardware supports the feature
Failure (return code ≠ 0): Hardware doesn't support this feature
No change in status: Feature may be already enabled or hardware doesn't support it

Step 5: Verify Prerequisites

Some NICs require specific prerequisites before TLS offload can work:

# Check if checksum offload is enabled (required for TLS offload)
ethtool -k eth0 | grep -E "(rx-checksumming|tx-checksumming)"

# Enable checksum offload if disabled
sudo ethtool -K eth0 rx-checksumming on tx-checksumming on

# Check for other required features
ethtool -k eth0 | grep -E "(scatter-gather|tcp-segmentation-offload)"

# Some drivers require specific firmware versions
ethtool -i eth0 | grep firmware

Step 6: Advanced Hardware Detection

For more detailed hardware analysis:

# Check NIC's crypto capabilities at kernel level
cat /sys/class/net/eth0/device/vendor
cat /sys/class/net/eth0/device/device

# Look for hardware crypto engines
lspci -vv | grep -A 50 "Ethernet controller" | grep -i crypto

# Check interrupt vectors (more vectors often indicate more features)
cat /proc/interrupts | grep eth0

# Examine network device features at kernel level
cat /sys/class/net/eth0/features

Step 7: Validate with Kernel TLS Support

Verify that your kernel can work with your hardware:

# Ensure kernel TLS module is available
lsmod | grep tls || sudo modprobe tls

# Check kernel version compatibility
uname -r
# Minimum versions:
# - 4.13+ for basic kTLS
# - 4.17+ for RX offload  
# - 5.2+ for improved hardware support

# Test TLS ULP availability
cat /proc/sys/net/ipv4/tcp_available_ulp | grep tls

Once you've verified hardware support, you can proceed with confidence that your system can take full advantage of kernel TLS performance benefits. If your hardware doesn't support TLS offload, you can still benefit from kTLS software mode, which provides kernel-level TLS processing advantages over userspace implementations.

kTLS makes TLS faster and simpler by moving encryption into the kernel and hardware instead of relying on complex userspace libraries. It reduces CPU load, streamlines operations, and gives high-performance secure apps a clear advantage.

References:

Kernel TLS offload — The Linux Kernel documentation

The Linux Kernel

Kernel Transport Layer Security (kTLS) Offloads - NVIDIA Docs

NVIDIA Docs

Kernel TLS — The Linux Kernel documentation

The Linux Kernel