A client reconnects to a service it visited recently and sends an HTTP request before the new TLS handshake has finished. The request can reach application processing sooner than traffic sent after handshake completion. That small latency gain is attractive at scale, but it changes a property applications often take for granted: a protected request is not automatically a fresh request.
TLS 1.3 calls this feature early data, commonly described as 0-RTT data. It is available only in suitable resumed sessions, not on an initial connection with no prior session state. The client uses information associated with a previous connection to protect data sent immediately. The server can accept that data before the new handshake completes.
The cryptography still protects early data against passive observation under the protocol’s assumptions. The difficult part is replay. An attacker able to capture valid early data can potentially cause another server-side processing attempt. TLS cannot infer whether repeating a particular application request is harmless, expensive, or financially significant. That judgment sits above the record layer.
Resumption creates a different security moment
A full TLS 1.3 handshake establishes fresh traffic keys before application data is exchanged. Session resumption can shorten that exchange by using a pre-shared key derived from an earlier session. Early data goes further: the client can derive early traffic keys and transmit application bytes without waiting for the server’s handshake messages.
That timing is the source of both the performance benefit and the security distinction. At the moment early data is sent, the client does not yet have the same freshness guarantees associated with application data transmitted after the handshake. The server is evaluating data tied to resumption state that may be accepted more than once under some deployment conditions.
TLS 1.3 explicitly treats 0-RTT data as having weaker security properties than ordinary 1-RTT application data. In particular, the protocol does not provide inherent replay protection for early data across all possible server deployments. A service that enables it therefore accepts an obligation that does not exist in the same form for post-handshake traffic.
This distinction is easy to lose behind an HTTPS endpoint. Application code may see an ordinary GET or POST, even though the transport path that delivered it carried different replay properties. If the TLS terminator does not preserve that context for downstream policy, the application can make a high-impact decision without knowing that the request arrived as early data.
Replay resistance is a distributed systems problem
A single TLS server can maintain state intended to detect reuse of resumption material, but production services rarely consist of one process with one durable memory space. Traffic may terminate at many edge nodes, regions, load balancers, or independent clusters. Session tickets may be accepted by multiple machines so clients can resume connections regardless of which node receives the next request.
That distribution complicates strict replay detection. A ticket or early-data attempt seen at one node may not be known immediately at another. Sharing replay state across a fleet adds coordination, storage, expiry, and availability concerns. Keeping acceptance local reduces coordination but can leave replay opportunities when equivalent resumption credentials work at several endpoints.
Key rotation also matters. Servers often encrypt or authenticate session tickets with keys shared across a group of terminators. The scope of those keys influences the scope in which a ticket may be accepted. A broad scope can improve resumption rates while making anti-replay state harder to keep authoritative. A narrow scope can reduce that exposure while lowering the chance that a reconnecting client reaches a compatible terminator.
No universal server-side cache turns early data into ordinary post-handshake traffic. Anti-replay mechanisms can reduce practical exposure, but application design still has to account for duplication. This is especially important during failover, partial outages, rolling deployments, and regional traffic shifts, when assumptions about shared state are most likely to be stressed.
Idempotence is useful but narrower than it sounds
The usual operational rule is to restrict early data to requests that are safe to replay. HTTP method semantics provide a useful starting point, but method names alone are not enough.
A GET request is defined as safe in HTTP semantics, yet real systems sometimes attach side effects to reads: incrementing counters, issuing temporary resources, recording billable activity, advancing a workflow, or triggering asynchronous work. Some of those effects may tolerate duplication; others may not. A nominally safe method does not repair an application that violates its own interface semantics.
Idempotence also needs careful interpretation. An operation can produce the same final resource state when repeated while still causing duplicate external effects. Setting a preference to a fixed value may be idempotent at the database row, but a handler that sends a notification on every accepted request can still emit the notification twice. A request that launches work identified by a fresh server-generated job ID can create two jobs even if the visible HTTP operation appears simple.
The relevant question is therefore not just whether the endpoint uses a conventional read method. It is whether another processing attempt with the same authenticated request can create unacceptable additional effects anywhere in the transaction’s reach.
Authentication does not remove duplication
Early data can be authenticated through the resumed TLS context, but authentication and freshness are separate properties. A replayed request may still be a cryptographically valid request associated with the original client session. The attacker does not need to forge the protected bytes if repeating those bytes is enough to trigger an effect.
This matters for systems that treat a valid secure channel as evidence that a command is both authentic and current. TLS establishes important channel properties, but early data weakens the assumption that acceptance corresponds to one unique application event.
Application-level mechanisms can provide stronger semantics for sensitive operations. An idempotency key bound to the operation can allow a service to recognize repeated submissions and return the result of the original operation instead of performing it again. A nonce tracked as consumed can serve a similar role where a strict single-use command is required. Transaction identifiers can also help, provided their uniqueness and retention rules match the period in which replay matters.
These controls are not interchangeable with TLS anti-replay handling. They protect application effects according to application identity and storage boundaries, which may extend beyond the lifetime or topology of a TLS session. For a payment, credential change, purchase, message send, or infrastructure mutation, that semantic layer is often the more meaningful place to enforce uniqueness.
Edge infrastructure has to carry the policy
Many applications never terminate public TLS themselves. A content delivery network, reverse proxy, ingress controller, or managed load balancer handles the handshake and forwards an ordinary request to the origin. In that architecture, early-data policy belongs partly to infrastructure configuration and partly to application design.
A robust deployment needs an explicit answer for what happens when early data arrives. One option is to disable 0-RTT entirely. Another is to accept it only for a constrained set of routes whose effects tolerate replay. A terminator can also reject early data and require the client to retry after handshake completion, preserving resumption benefits without processing the application request in the early-data phase.
The important property is that the decision remains visible and consistent across layers. If an edge accepts early data broadly while the origin assumes every HTTPS request has ordinary freshness properties, the architecture contains a silent mismatch. The same issue appears when one region enables early data and another does not, or when a proxy upgrade changes defaults without an application review.
Observability should preserve enough context to distinguish early-data traffic from normal post-handshake traffic. That does not require logging secrets or session tickets. It does require operators to be able to identify which routes accepted early data, how often clients used it, and whether replay controls rejected or deduplicated requests. Without that signal, a replay-related incident can resemble an ordinary duplicate submission.
Performance gains should match the endpoint
The value of early data is workload-specific. Removing a round trip can matter for latency-sensitive services, especially when clients reconnect frequently over networks with significant round-trip time. It is less compelling for endpoints dominated by server computation, database work, large transfers, or interactions that already require additional application exchanges.
That makes blanket enablement a poor fit. A static asset request and a funds transfer do not have the same replay cost. Neither do a public document fetch and an administrative mutation. Treating every HTTPS route as equivalent discards information the application already has about consequence and reversibility.
A narrow policy also limits operational complexity. Services can reserve early data for requests whose duplicate execution is harmless, keep sensitive mutations behind completed handshakes, and use application-level deduplication where retries are already part of normal distributed operation. This aligns the optimization with semantics rather than asking cryptographic transport machinery to infer business impact.
TLS 1.3 early data is a useful example of a broader security pattern: faster protocol paths can move decisions across boundaries that used to be implicit. The feature does not make TLS weak. It makes freshness conditional. Systems that preserve that distinction can take the latency benefit where it fits without turning a resumed connection into permission to repeat an irreversible action.