Summary: after WEP was found to be fatally insecure, the 802.11i amendment introduced a new key negotiation protocol, the "4-way handshake". It was mathematically proven to be secure. Two encryption algorithms were defined, TKIP and CCMP, the former being a compatibility wedge that allowed the new security system to function with pre-802.11i wireless cards supporting only RC4. CCMP was the preferred algorithm, based on AES. In the following 14 years, TKIP was found to have certain vulnerabilities, but fully exploiting them required a combination of other protocol weaknesses like ICMP 3:3 responses. CCMP was thought to be secure, although recent revelations of a flawed random number generator in the 802.11i spec were raising concerns.

Today a paper was released that shows the 4-way handshake is (universally) implemented in an insecure way. Specifically, client software chokes when the 3rd packet is received more than once, resetting its nonce or worse: Android 6.0 sets the packet encryption key to zero. This means an attacker can both decrypt network traffic, and inject forged packets, the most serious vulnerability found in WPA to date. All encryption algorithms and modes ("Personal" and "Enterprise") of WPA/WPA2 are affected.

It will be interesting to see which operating systems are patched. Older systems without source access are going to become dangerous on wireless networks. OpenBSD was already patched a few months ago.

robespierre wrote:It will be interesting to see which operating systems are patched. Older systems without source access are going to become dangerous on wireless networks. OpenBSD was already patched a few months ago.

In addition to client-side issues, I expect that an enormous percentage of wireless routers and access points never will be patched, either because vendors won't offer patches for older devices or because device owners, for any number of reasons, won't install available patches.

I've been avoiding going "all devices, all VPN, all the time," but maybe the time for that has arrived.

josehill wrote:In addition to client-side issues, I expect that an enormous percentage of wireless routers and access points never will be patched

If I understand correctly, this is a man-in-the-middle attack against the client. Unless you run your router as a wireless repeater, it isn't a client.

Correct, but as I understand it, the issue can be mitigated on the router side by patching the router to send the "one-time" handshake key once, and only once, rather than allowing a key to be re-sent multiple times in the absence of client acknowledgment. Obviously, all clients should be patched, but thee are things that can be done on the router side to reduce risk. (That doesn't mean that there won't be connectivity issues introduced by limiting key transmission to single occurrences, but those are separate issues.)

josehill wrote:Correct, but as I understand it, the issue can be mitigated on the router side by patching the router to send the "one-time" handshake key once, and only once, rather than allowing a key to be re-sent multiple times in the absence of client acknowledgment.

Yes, that would be a good idea. The other thing that can be patched on the AP side is to change it to only accept handshake frames from the client with the replay counter equal to the expected value (instead of any value not yet received).