firewall-bad | 8 years ago | on: Key Reinstallation Attacks – Breaking WPA2 by Forcing Nonce Reuse
firewall-bad's comments
firewall-bad | 8 years ago | on: Key Reinstallation Attacks – Breaking WPA2 by Forcing Nonce Reuse
I'm not sure how that compares to the fact that WPA2 is completely insecure and trivial to decrypt on Android as "no, that is bad". Except maybe in a "well who trusts Wi-Fi security anyway?" to which I'd reply: "Actually, a lot of people. Including people on this thread".
I actually buy the argument that the RSA issue that affects YubiKey, that was announced today, is perhaps more important since it's harder to mitigate than using a VPN, but I don't know how bringing up silence in the wire makes this any less important.
Again, I haven't fully or detailedly read the book, so I could be wrong about that I guess.
firewall-bad | 8 years ago | on: Key Reinstallation Attacks – Breaking WPA2 by Forcing Nonce Reuse
Using a VPN is the best way to mitigate this until your device is patched, assuming you trust your VPN provider or run your own VPN.
Edit: Actually, even if you don't trust your VPN provider, you'll be protected against this attack (KRACK), given their client is implemented properly.
firewall-bad | 8 years ago | on: Key Reinstallation Attacks – Breaking WPA2 by Forcing Nonce Reuse
The attack is the fact that someone couldn't do this you're describing on any WPA-2 protected Wi-Fi network before, and now they can.
firewall-bad | 8 years ago | on: Key Reinstallation Attacks – Breaking WPA2 by Forcing Nonce Reuse
I don't think it's a lot of consolation saying something along the lines of "Wi-Fi security is broken, but it's not so bad because it's Wi-Fi"
firewall-bad | 8 years ago | on: Key Reinstallation Attacks – Breaking WPA2 by Forcing Nonce Reuse
1) The paper claims confidentiality compromise allows the attacker to hijack a tcp connection: "allow an adversary to decrypt a TCP packet, learn the sequence number, and hijack the TCP stream to inject arbitrary data", this on all cases, even in the cases where it doesn't allow forgery (CCMP)
2) There's no such claim on the paper and according to the researcher, exploiting this on Android and Linux is trivial. Apparently also macOS. Did you see the video on their website?
3) There's no way for you to control this (apps, https stripping, for instance). Most importantly, there's no way for the average user to control this, short than using a VPN.
Again, as far as Wi-Fi security goes, seems pretty end-of-the-world to me. I don't think the huge attention this is getting is unwarranted.
I'm sure, given the size of that list, that they tested some of the biggest players on the VPN space. I think it'd be good to know which apps were tested and didn't show any issues, especially in light of Krack and the Android bug on wpa_supplicant.