Ref to the CVEs that will make a lot of network admins hate Monday: https://twitter.com/nick_lowe/status/919527451570638848
And some background: https://eprint.iacr.org/2016/475.pdf
I guess this implies not "only" passive eavesdropping but also network access in environments without a MAC address filter (not that these can't be spoofed regardless)?
Source: https://www.krackattacks.com/
"We also publish the system uptime in an unencrypted broadcast message to save you the effort of even bruteforcing it".
Does nobody do security reviews on this stuff, or are these weaknesses there deliberately?
The line between incompetence and malice really is thin here...
If an attacker had recorded encrypted WiFi traffic in the past and then performed one of these attacks could they see the traffic? (I know TLS is used for a lot of traffic, but in time that will be broken too.)
It seems to me that a patient attacker could gain a lot of sensitive info given enough time. Is this assumption flawed? I would love to hear why/why not. (Nonces make decryption of large amounts of TLS traffic impractical?) What about the impact of just knowing DNS lookups? (Real world info on DNS caching? Does DNSSEC stop this? Is it widely implemented?) What if a data broker recorded a lot of encrypted WiFi traffic at a public place like a mall? (Could they learn MAC addresses? mDNS device names? DNS lookups? I bet a lot of tracking cookies and other advertiser tokens don’t bother with TLS which could get them emails and more.)
Someone recording encrypted WiFi traffic from a sensitive network may have enough motive to do something this long-term and the attack would be (electronically) undetectable. Most people rarely change their passwords and at a minimum this would give an attacker knowledge of the internal network, intranet sites, and services used by targets.
But WPA2 never offered much anyway. If you're on mall wifi, you can already see unencrypted traffic for everyone else, because the client keys are derivable from the shared passphrase (which presumably everyone at the mall has been told) and overhearing the four-way handshake when someone joins. And! You can even fake a disconnect message that forces the four-way handshake to happen again, if you weren't around when the client originally joined.
All of which is to say, WPA2 in passphrase (PSK) mode never actually provided meaningful encryption against other people on the network. :( Someone forgot to tell the protocol designers that Diffie-Hellman exists. Using Diffie-Hellman would achieve both removing the exploit where you observe the four-way handshake, and providing for forward secrecy too.
Without contradicting your observation, I want to mention that virtually anything important you do on the Internet these days--from online banking to Google searches to reading Hacker News--is protected by a second independent layer of encryption: HTTPS. I'm not excusing the WPA2 flaws, but I do think that your bank info, web searches, and Hacker News comments are secure even at the mall.
If someone can offer a credible explanation of why online banking or other HTTPS activity is insecure on public wifi, I'd like to hear it please.
Update 2: Apparently anything captured along with the device handshake can be decrypted after the fact if the attacker learns the password used at that time. (Source: https://www.google.com/amp/s/mrncciew.com/2014/08/16/decrypt...) So to decrypt all traffic an attacker would only need to compromise any machine which has the password saved. (Assuming they see the handshake for the device connection.) This indicates that regularly rotating the password (To something unpredictable) has some limited value.
Where did WEP and WPA2 come from, anyway? What's the historical reason we aren't all using TLS to connect to our APs?
Because it’s insanely impractical for home use? Hey, here’s your new WiFi router. Just install this new root CA on all your devices, create a device cert for each machine and install that very as well, and don’t forget you need to re-do this every year...
https://www.tedunangst.com/flak/post/moving-to-https
"So how does one verify that the downloaded cert is the original? The same way the CAs do. Perform a DNS lookup, make a web request, trust the result. The addition of HPKP would indicate that people find the CA model untrustworthy, solving the problem with trust on first use key continuity. Why not cut out the middle man? Protesting the CAs is admittedly pretty futile, but if I can’t do it, who can?"
It's just not practical for consumer and small-business setups.
The problem with TLS is that it’s client authentication kinda sucks and isn’t easy to manage.
