[g-clef]

Not quite: The attacker watches for the initial client->AP encryption negotiation (or forces it by forcing a disassociate), records one step of that negotiation and replays it to the client. That has the side-effect of causing the client->AP traffic to re-use encryption keys. Since WPA2 encryption is a stream cipher, re-using keys opens it up to a known-traffic analysis attack, which allows a listener to decrypt the traffic. So, the user is still connected to their existing AP, but since they're re-using keys, attackers can decrypt the client->AP communication.

There's no need for a second AP in all this, just someone in range of the client who can replay packets to the clients.

(Good TLDR here: https://blog.cryptographyengineering.com/2017/10/16/falling-... )

[CapacitorSet]

>There's no need for a second AP in all this, just someone in range of the client who can replay packets to the clients.

How would you drop packet 3 without a new AP?

[g-clef]

You don't. You record it and replay it. You want the client to get the same packet 3 over and over.

[NemosDemos]

Are you sure about that? From the paper (section 3.3):

> Note that the adversary cannot replay an old message 3, because its EAPOL replay counter is no longer fresh.

And a related update from the TLDR post you originally referenced (which I believe is causing confusion):

> Update: An early version of this post suggested that the attacker would replay the message. Actually, the paper describes forcing the AP to resend it by blocking it from being received at the client. Thanks to Nikita Borisov for the fix.