TLS 1.3 0-RTT lets a returning client send application data in its first flight, before the handshake finishes. It saves a round trip, but RFC 8446 says there is no guarantee of non-replay between connections and the data is not forward secret. Leave it off unless you can show the requests are safe to repeat.
What 0-RTT is
When a client resumes a session using a pre-shared key, it can encrypt some data under keys derived from that key and send it along with its first message. The server can act on it immediately. For a latency sensitive site this saves one round trip on repeat visits.
The price is stated plainly in the RFC. Its list of major changes says 0-RTT was added "at the cost of certain security properties."
The two weaknesses
From RFC 8446 section 2.3:
- Replay. "There are no guarantees of non-replay between connections." Protection for normal 1-RTT data comes from the server's random value, but 0-RTT data does not depend on the ServerHello, so its guarantees are weaker. An attacker who captured a 0-RTT message can send it again to the server.
- No forward secrecy. The data is encrypted solely under keys derived from the offered PSK, so a later key compromise exposes it.
Within a single connection, the RFC says 0-RTT data cannot be duplicated and cannot be made to look like normal data, because different keys protect it. The risk is replays across connections.
Why replay matters to an application
If a replayed request is a harmless read, little happens. If it is a money transfer, an order submission or a one time token redemption, the server might do it twice. The danger is highest for requests that change state.
RFC 9325 says applications must avoid 0-RTT unless a specification for the application protocol says when it is appropriate and secure, and points to RFC 8470 for HTTP. I did not retrieve RFC 8470 text for this post, so read it before enabling early data on HTTP.
Decision guide
- Do you need the speed? Measure first. Many sites gain little.
- Can every request that might arrive as early data be repeated with no harm? If not, leave 0-RTT off.
- Does your CDN or proxy enable it by default? Check its settings, since a front end that accepts early data may pass it to your origin.
- If you enable it, restrict it to safe reads and make state changing endpoints reject early data.
- Log which requests arrive as early data so you can audit them.
Quick check
Is 0-RTT enabled by default in TLS 1.3?
It is a mode the server must opt into by issuing tickets that allow early data. Whether your stack or CDN does that depends on its configuration, so verify it.
Does turning off 0-RTT break TLS 1.3?
No. Normal 1-RTT handshakes and ordinary resumption still work.
Sources
Last reviewed: 19 October 2026.
