The 802.11 specification that describes WPA2 (802.11i) is behind a paywall, and was designed by a few key individuals at the IEEE. The standard was reviewed by engineers, not by cryptographers. The details of the functionality (e.g. retransmission) were not widely known about or studied by security professionals.
Cryptographer Matthew D Green wrote a blog ...
Citing the relevant parts from https://www.krackattacks.com:
Who is vulnerable?
Both clients and access points are listed in the paper as being vulnerable. See the tables 1 and 2 on pages 5 and 8 for examples of vulnerable systems, and table 3 on page 12 for an overview of which packets can be decrypted.
The weaknesses are in the Wi-Fi standard itself, ...
Does KRACK mean that wifi cafes will never be safe again?
This is based on the false assumption that Wi-Fi cafes were ever safe. That is simply a false assumption.
So if the client is patched, what if you don't know whether the WAP is or isn't? Doesn't this mean that one can never trust anonymous wifi cafes again, since there's no way to know whether ...
To fully protect your network, both the device and the access point will need to be patched:
Finally, although an unpatched client can still connect to a patched
AP, and vice versa, both the client and AP must be patched to defend
against all attacks!
In some sense, it feels like this should have been obvious.
Remember Heartbleed, Shellshock, POODLE, TLS Triple Handshake attack, "goto fail", ... ?
In hindsight, most of these problems seem to be obvious and could have been prevented if the right people just had a closer look at the right time at the right place. But, there is only a limited amount of ...
TL;DR: It is often (but not always) enough to properly patch the WiFi client.
You need to also patch the router it it works as WiFi client too (e.g., a repeater) or has fast roaming (802.11r) enabled.
The essential part of the attacks is that the client accepts message 3 of the 4-way handshake again which causes the client to re-install the same encryption ...
KRACK is on the Network layer of the OSI model, while TLS is on the Session layer. So no, they do not influence each other, provided that the client can not be tricked into using a non-TLS connection (SSLstrip).
The basic threat from KRACK is that it allows an attacker to decrypt all packages on the network layer that the victim sends / receives. This ...
The paper describing KRACK discusses this very issue in section 6.6.
A couple of points: There were ambiguities in the specification. Also formal proofs of specification are based on a model of the specification, and there are times when that model does not match the actual specification, much less matching the implementations based on that specification.
According to this IBM XForce post:
[...] Attacks must be within range of the access point and client. Both the client and access point have to be patched in order to be protected from these attacks. If the access point is patched, but not the client, exploitation is still possible.
Prior to Tuesday @ 2017-10-17 10:42a CDT: IBM said:
[...] if even only ...
Using a secure connection such as HTTPS helps against the attack. HTTPS Everywhere can help you ensure that HTTPS is used as much as possible:
Install the browser addon HTTPS Everywhere from the Electronic Frontier Foundation's official website: https://EFF.org/https-everywhere
Once done, click on the blue "S" icon of HTTPS Everywhere and tick on the box ...
This is because of being able to figure out the keystream for a given key and nonce when you can get both to be reused and the stream contains predictable information.
In many ciphers, a key is used to produce a series of ones and zeros that are xor'd with the data to produce an encrypted value. This string of ones and zeros is known as the keystream. ...
A (properly configured, secured protocol) VPN connection will not protect you from being "forced" to join the malicious access point, but it will prevent your communications from being eavesdropped on. The same is true for properly configured SSL / TLS.
The attacker in the KRACK attack sets up a malicious access point, which your device connects to as part ...
What are the real-world consequences of these attacks for users and owners of wireless networks
Already a great answer here, but thought I would add my viewpoint to a part of it. There have been a lot of "sensationalist" headlines and misinformation in recent days that portray this vulnerability as much more serious than it really is.
Ultimately, this ...
No, it doesn't affect TLS. In fact, using TLS encrypted sites (HTTPS) is helpful if you're worried about KRACK - an attacker would only be able to see which site is being accessed, but not which pages within the site, or any data which you send to the site.
There are some other recently announced attacks which may affect TLS, and which it's possible that ...
Yes it is exploitable. WPA Enterprise still relies on a 4-way handshake. The main difference between enterprise and non enterprise is how the client is authenticated, which is not the same as how the connection is finally encrypted-- although there is a slight difference at the start of the process, it doesn't prevent the vulnerability. The main exploit has ...
If either endpoint is patched you should view the connection as *secure. None of the traffic can be seen if the router is patched. The router will refuse to use the reset Nonce and the connection will fail. If the router is also unpatched then any unpatched devices connecting to it such as the camera may have their traffic viewed.
Krack forces nonce reuse ...
I hear things both ways, it's hard to tell. The paper mentioning both clients and APs sounds like there is at least something to be done on both sides. This comment makes sense to me: "most access points will be fine, but those performing client functions (eg repeaters) will need updating."
Sorry that I cannot give a definitive answer, I'll update if I find ...
Test scripts will indeed be published by the original author but are not available yet.
As stated by the author:
We have made scripts to detect whether an implementation of the 4-way
handshake, group key handshake, or Fast BSS Transition (FT) handshake
is vulnerable to key reinstallation attacks. These scripts will be
released once we have had the ...
If you can't afford VPN then make your own, if it is possible. It is relatively easy to set up, especially if have experience from before.
Here is a nice script for beginners which will make the whole process easier.
In general, MAC filters (both whitelisting and blacklisting) are completely ineffective against a determined attacker, as MAC addresses can be easily changed and forged using standard system networking utilities.
Additionally, MAC filters do not apply here since this vulnerability allows exploitation from an attacker who is not associated with the network (...
The question is not whether there will be an exploit but what will be the range of upcoming exploits.
This vulnerability receives so much attention precisely because of its impacts.
Would it be a theoretical weakness reserved to potential state agency or a thing easily fixable as part of automatic update processes, nearly no one would have ever heard of it ...
The direct vulnerability of KRACK doesn't affect TLS/SSL encryption, however once the MITM is established SSLstrip can be used to strip HTTPS down to HTTP. This is shown in the official video demonstration where login credentials for match.com are sniffed from an Android device.
The Linux kernel itself is not affected. The part responsible for WPA is wpasupplicant. From the Changelog:
Version: 2.1-0ubuntu1.5 2017-10-16 17:06:43 UTC
wpa (2.1-0ubuntu1.5) trusty-security; urgency=medium
SECURITY UPDATE: Multiple issues in WPA protocol
debian/patches/2017-1/*.patch: Add patches from Debian jessie
Yes, install the TOR browser as it is a free VPN, and the traffic is encrypted until an exit node.
Any .onion websites are end-to-end encrypted, and HTTPS websites are also end-to-end encrypted. However, the contents of any HTTP websites will still be visible to exit node operators, as anyone can run such a node.
TL;TR: It is often (but not always) enough to properly patch the WiFi client. You need to patch the AP to if it provides client functionality (i.e. router) or has fast roaming (802.11r) enabled.
From my understanding it is essential for all the attacks that the client accepts message 3 of the 4-way handshake again and then reinstalls the same encryption key ...
You should be fine to download new apps from the App Store.
Let me start by saying that there are no known instances of KRACK being used in any exploit outside of research environments so far. Even if it is and your connection has been compromised, you should be safe using the App Store.
Logging into and accessing the App Store has been using HTTPS since ...
This information and more can be found right on the KRACK website: https://www.krackattacks.com/
Our main attack is against the 4-way handshake of the WPA2 protocol. This handshake is executed when a client wants to join a protected Wi-Fi network, and is used to confirm that both the client and access point possess the correct credentials (e.g. the pre-...
KRACK does not affect SSL/TLS.
WPA2 works on the data link layer while SSL/TLS works on the session layer. The example on https://www.krackattacks.com/ uses SSL strip to bypass SSL. However this only works on websites which are not configured to use HSTS, which a fair number of websites don't use: https://www.ssllabs.com/ssl-pulse/
For mobile devices, use Opera VPN. For your laptop, see: VPN integrated in Opera for better online privacy.
I doubt it changes route to a dedicated VPN interface on the browser ‘vpn’, but it’s better than nothing. You’ll need something like OpenVPN to set up a real tunnel, though.
The speed is adequate, and there are options for compression. It’s free, of ...
It seems, that you were spot on with your questions. Several news sites report the same, for instance ArsTechnica mentions:
Update: As Ars readers have pointed out, Apple's support documentation states that the iOS KRACK fix is available for iPhone 7 and later, and for the early 2016, 9.7-inch iPad Pro and later. It is unclear whether this means previous ...