Using OpenSSL TLS 1.3 0‑RTT to Cut Latency – What You Need to Know

Micro‑services and APIs often open many short‑lived TLS connections. Each new connection forces a full handshake, adding one or more round‑trips that can dominate latency budgets. OpenSSL’s implementation of TLS 1.3 zero‑round‑trip‑time (0‑RTT) resumption lets a client send application data immediately after the ClientHello, shaving off that round‑trip. The feature is useful, but the early data lacks forward secrecy and can be replayed, so you must treat it carefully.

How TLS 1.3 0‑RTT Works in OpenSSL

When a client and server have previously completed a TLS 1.3 handshake, the server can issue a session ticket that encrypts the secret state. On a subsequent connection, the client includes that ticket in the ClientHello and may also send early application data (the 0‑RTT data) before the server finishes processing the ticket. The server decrypts the ticket, recovers the secret, and can immediately process the early data. However, because the early data is encrypted with a key derived only from the ticket, it does not enjoy the forward secrecy of a full handshake, and an attacker who captures the ticket can replay the early data.

Configuring Server and Client for 0‑RTT

Both ends need OpenSSL 1.1.1 or newer (openssl version should show OpenSSL 1.1.1 or higher). To enable 0‑RTT you must:

1. Generate a certificate and key for testing (or use your production credentials).
2. Start the server with the -early_data flag so it advertises support for early data and stores tickets.
3. On the client side, also specify -early_data to indicate willingness to send early data.

OpenSSL does not install a replay‑check callback by default; the application must provide one if it wants to detect duplicated early data. The callback receives the early data and can return a non‑zero value to reject it.

Worked Example with s_server and s_client

In one terminal, launch a test server:

openssl s_server -accept 4433 -tls1_3 -early_data -cert server.pem -key key.pem

In a second terminal, connect the client and type a short line before the handshake finishes:

openssl s_client -connect localhost:4433 -tls1_3 -early_data -msg

If the client sends data early enough, the output will include a line similar to:

Early data was sent

Note: This description reflects the expected behavior; you should verify the output in your own environment.

Trade‑offs, Replay Safety and Best Practices

The latency gain comes with two important limitations:

• No forward secrecy for early data – avoid sending passwords, session tokens, or any sensitive payload in the 0‑RTT buffer.
• Replay vulnerability** – an attacker who captures a ticket can resend the same early data. OpenSSL will not reject it unless your application supplies a replay‑check callback that tracks used tickets or employs an anti‑replay window.

To use 0‑RTT safely:

• Restrict early data to idempotent operations (e.g., HTTP GET, cache updates, metrics).
• Rotate session tickets frequently (short ticket lifetimes) to limit the replay window.
• Monitor logs for replay‑warning messages from your callback and alert on spikes.
• Fall back to a full handshake when the request requires strong secrecy or non‑idempotent effects.

When these guidelines are followed, 0‑RTT can shave tens of milliseconds off connection setup for latency‑sensitive services without exposing critical data to replay or secrecy attacks.