8

The specifications for TLS 1.3 0-RTT mention the following threat which an attacker might realize:

Network attackers who take advantage of client retry behavior to arrange for the server to receive multiple copies of an application message. This threat already exists to some extent because clients that value robustness respond to network errors by attempting to retry requests. However, 0-RTT adds an additional dimension for any server system which does not maintain globally consistent server state. Specifically, if a server system has multiple zones where tickets from zone A will not be accepted in zone B, then an attacker can duplicate a ClientHello and early data intended for A to both A and B. At A, the data will be accepted in 0-RTT, but at B the server will reject 0-RTT data and instead force a full handshake. If the attacker blocks the ServerHello from A, then the client will complete the handshake with B and probably retry the request, leading to duplication on the server system as a whole.

My question is: Where is the attack? At the end of the day, the attacker could as well just have passed his copy of the ClientHello to Zone B and get the same outcome (a full handshake). What am I missing?

2

You aren't missing that much. I think this cloudflare article near the end outlines possible attack vectors and scenarios quite nicely. Depending on the security of the networks and web apps, 0-RTT may not be responded to pending what kind of parameters or certain types of headers. If an attacker has already figured out how to insert himself and gain visibility to what he would want to replay on a vulnerable host, there are worse risks elsewhere to look out for first. Something like a 0-RTT replay that has parameters and an authenticated session cookie and a HTTP downgrade could be plausible. But in the pentester's world, that's alot of work.

1

Okay the answer is that this itself is a classical replay attack. Assuming that A and B are servers which do not accept tickets intended for the other, the attack looks like this:

  1. Client sends 0-RTT message which is intercepted by the attacker
  2. The attacker relays the message to both A and B
  3. A will accept the message and process it
  4. B will decline the ticket and force a full handshake with the client
  5. As part of the fallback full handshake, the client will then resend the message to B, leading to a duplication on the server cluster where the original message is processed twice - a replay attack

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.