en English
X

Select Language

Powered by Google TranslateTranslate

We hope you will find the Google translation service helpful, but we don’t promise that Google’s translation will be accurate or complete. You should not rely on Google’s translation. English is the official language of our site.

en English
X

Select Language

Powered by Google TranslateTranslate

We hope you will find the Google translation service helpful, but we don’t promise that Google’s translation will be accurate or complete. You should not rely on Google’s translation. English is the official language of our site.

What are the security concerns with TLS 1.3’s 0-RTT mode?

TLS 1.3 offers a feature called 0-RTT (zero round trip time) Resumption mode, in an effort to enhance performance.

When a browser successfully completes a TLS handshake with a server for the first time, both the client and the server can store a pre-shared encryption key locally. This is known as the resumption master secret.

If the browser establishes a connection with the server again at a later time, it can use this resumption key to send encrypted application data in its first message to the server, without having to perform the handshake a second time.

However, 0-RTT resumption has a caveat; resumption data require no interaction from the server, which means that an attacker can capture encrypted 0-RTT data and re-send them to the server, or replay them.

In the case the server is misconfigured, it can potentially accept replayed requests as valid; essentially, allowing the attackers to perform unsanctioned actions.

The solution to this issue is ensuring that all 0-RTT requests are idempotent.

Idempotent requests can be safely used as 0-RTT requests, since replaying them will have no effect. A quick rule of thumb would be to only use GET requests with 0-RTT resumption.

Subscribe to SSL.com’s Newsletter

Don’t miss new articles and updates from SSL.com