2026-09-18 · 6 min read · Rahul Chitturi
- http
- tls
- replay-safety
TLS 1.3 early data can reduce latency by letting a returning client send application bytes before a fresh handshake completes. Those bytes do not have the same replay protection as ordinary post-handshake traffic.
A server can return 425 Too Early when it refuses to process a replay-sensitive request received as early data. The useful fallback is to complete the handshake and retry under the endpoint's normal retry contract.
Prove whether early data was involved
Record the client, TLS terminator, connection reuse state, protocol version, early-data indicator, request method, route, and final retry. An ordinary request that receives 425 may expose a gateway policy or forwarding bug.
- Compare fresh and resumed TLS connections.
- Trace whether the edge forwards an early-data marker.
- Confirm which component generated the 425 response.
- Keep transport retries distinct from application retries.
Classify operations by replay impact
Method names alone do not prove replay safety. A nominally safe route can trigger analytics or signed-link consumption, while a write can sometimes be protected by a scoped idempotency key and atomic deduplication.
Disable early data for operations whose duplicate execution can spend money, consume a one-time credential, create a resource, or cross an authorization boundary unless the full path has a tested replay defense.
Test one automatic fallback
Use the URL tool for route inspection, timestamp converter for handshake and retry timing, UUID generator for synthetic idempotency keys, and diff for edge policy changes.
Test session resumption, fresh handshakes, 425 fallback, duplicate early requests, redirected requests, concurrent retries, expired deduplication records, multiple edge regions, and non-replay-safe endpoints without production credentials.