This is a 2016 paper. Tomorrow's details are apparently about forcing nonce reuse in most WPA2 implementations. Don't let the date fool you into thinking it's old news being discussed!
Predicting, Decrypting, and Abusing WPA2/802.11 Group Keys [pdf]
11–20 of 53 posts
Re: Predicting, Decrypting, and Abusing WPA2/802.11 Group Keys [pdf]
#12Re: Predicting, Decrypting, and Abusing WPA2/802.11 Group Keys [pdf]
#13WPA2 is toast. 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
Re: Predicting, Decrypting, and Abusing WPA2/802.11 Group Keys [pdf]
#14Where did WEP and WPA2 come from, anyway? What's the historical reason we aren't all using TLS to connect to our APs?
Re: Predicting, Decrypting, and Abusing WPA2/802.11 Group Keys [pdf]
#15The article says that only WPA2-TKIP is vulnerable to the downgrade, therefore running WPA2 with only AES should be fine.
Re: Predicting, Decrypting, and Abusing WPA2/802.11 Group Keys [pdf]
#16Well, if there's one piece of (somewhat) good news around this and https://www.krackattacks.com/ , it's that TLS and VPNs will become even more common. Where did WEP and WPA2 come from, anyway? What's the historical reason we aren't all using TLS to connect to our APs?
Re: Predicting, Decrypting, and Abusing WPA2/802.11 Group Keys [pdf]
#17Well, if there's one piece of (somewhat) good news around this and https://www.krackattacks.com/ , it's that TLS and VPNs will become even more common. Where did WEP and WPA2 come from, anyway? What's the historical reason we aren't all using TLS to connect to our APs?
Re: Predicting, Decrypting, and Abusing WPA2/802.11 Group Keys [pdf]
#18Earlier quoted context omitted.
Also worth nothing that the attack in the OP is on TKIP, but the KRACK attack that will be revealed tomorrow is based upon problems with the RNG (the example RNG, which apparently everyone used, is trivial to break and the protocol is also kind enough to provide you with a huge chunk of the entropy used in seeding the RNG. D'oh!)
This comment should be made the top comment. Thanks for the information. 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)?
Re: Predicting, Decrypting, and Abusing WPA2/802.11 Group Keys [pdf]
#19Well, if there's one piece of (somewhat) good news around this and https://www.krackattacks.com/ , it's that TLS and VPNs will become even more common. Where did WEP and WPA2 come from, anyway? What's the historical reason we aren't all using TLS to connect to our APs?
The only reason TLS works is because of CAs. What could be the CAs for APs?
It's just not practical for consumer and small-business setups.
Re: Predicting, Decrypting, and Abusing WPA2/802.11 Group Keys [pdf]
#20If 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.