Hacker News Reader

Comment by spsful | Hacker News Reader

You should be good if you’re up to date as of November 6th (I think, it may be November 8th) Swiftonsecurity tweeted this out, it’s a description of KRACK and various devices affected by it. Apparently google already fixed it on android? Also it says that iOS is rumored to be protected against this since iOS 11 but it’s not confirmed. Nobody has put out an official statement yet. What’s weird is that commercial vendors like Ubiquiti UniFi (I use them myself) have already released fixes for their APs but the paper says that clients should be the priority and get fixed from KRACK ASAP. And it’s weird because I don’t know of any client-side fix released in the wake of KRACK being public. https://char.gd/blog/2017/wifi-has-been-broken-heres-the-com...

View on HN

October 6th/8th, you mean?

I found it interesting that, in his article, he said: "With our novel attack technique, it is now trivial to exploit implementations that only accept encrypted retransmissions of message 3 of the 4-way handshake. In particular this means that attacking macOS and OpenBSD is significantly easier than discussed in the paper"

but elsewhere it said recent versions of OS X and iOS are not impacted. I wonder if the "safe" OSes are only vulnerable to the blocking/replay but not the decryption of data?

My UniFi AP-PROs show up today so I'll make sure to update them first thing.

Also, I'm having a bit of a hard time understanding the attack. It sounds like he forces them to connect to his AP, performs the attack, then allows them to connect to the intended network with the zeroed key, THEN is able to sniff that client's traffic because he knows their key? If I understand correctly, this means he cannot sniff the whole network's traffic, only the traffic between the attacked client and the AP? This makes me wonder about the meaning of a pre-shared key, but I'm guessing the PSK is only used to setup the relationship between client and AP, and then after the initial connection/pairing the pre-shared key is no longer used...

This blog post explains it a bit:

https://blog.cryptographyengineering.com/2017/10/16/falling-...

> Also, I'm having a bit of a hard time understanding the attack.

He forces them to connect to his own AP and forwards all traffic to the destination so that the client is unaware it has been redirected.

He then forces the client to re-install the key which (on anything that is derived from wpa_supplicant e.g. Linux, Android, etc) the client has blanked out after first use, so the key it reinstalls is now all zero bytes.

He can continue to forward the traffic to the destination so that the client gets responses, but now he can decrypt all of the traffic too.

For clients that re-install the correct key (which the account does not recover in any way) the attacker has to rely on snooping enough encrypted data in order to perform a birthday attack as the key re-installation also resets the frame counters which leads to nonce-reuse which is a problem in ciphers like AES-GCM.

Reply on news.ycombinator.com