Consequences of the WPA2 KRACK attack
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, and not in individual products or implementations. Therefore, any correct implementation of WPA2 is likely affected. [...] the attack works against personal and enterprise Wi-Fi networks, against the older WPA and the latest WPA2 standard, and even against networks that only use AES.
What is the impact?
adversaries can use this attack to decrypt packets sent by clients, allowing them to intercept sensitive information such as passwords or cookies.
The ability to decrypt packets can be used to decrypt TCP SYN packets. This allows an adversary to [...] hijack TCP connections. [An adversary can thus inject] malicious data into unencrypted HTTP connections.
If the victim uses either the WPA-TKIP or GCMP encryption protocol, instead of AES-CCMP, the impact is especially catastrophic. Against these encryption protocols, nonce reuse enables an adversary to not only decrypt, but also to forge and inject packets.
our attacks do not recover the password of the Wi-Fi network
(Emphases mine.)
Can we patch it (and will we have incompatible APs/clients)?
There is a fix for both APs and clients, it doesn't matter which one you patch first.
implementations can be patched in a backwards-compatible manner [...] To prevent the attack, users must update affected products as soon as security updates become available. [...] a patched client can still communicate with an unpatched access point, and vice versa.
However, both client and router must be patched (or confirmed secure):
both the client and AP must be patched to defend against all attacks [...] it might be that your router does not require security updates. We strongly advise you to contact your vendor for more details [...] For ordinary home users, your priority should be updating clients such as laptops and smartphones.
How does it work?
When a client joins a network, it [...] will install this key after receiving message 3 of the 4-way handshake. Once the key is installed, it will be used to encrypt normal data frames using an encryption protocol. However, because messages may be lost or dropped, the Access Point (AP) will retransmit message 3 if it did not receive an appropriate response as acknowledgment. [...] Each time it receives this message, it will reinstall the same encryption key, and thereby reset the incremental transmit packet number (nonce) and receive replay counter used by the encryption protocol. We show that an attacker can force these nonce resets by collecting and replaying retransmissions of message 3 of the 4-way handshake. By forcing nonce reuse in this manner, the encryption protocol can be attacked, e.g., packets can be replayed, decrypted, and/or forged.
Is there anything a wireless network owner can do apart from contact their vendor for a patch?
As mentioned, WPA-TKIP or GCMP are slightly worse, so make sure you use AES-CCMP for the lowest impact -- if your router allows you to choose that (many don't). Other than that, you can't truly mitigate it on a protocol level yourself. Just update as soon as possible.
Generally, use HTTPS for anything that needs to be secure (you should do this anyway, also over ethernet, but especially over Wi-Fi now), use a VPN as an extra layer, etc.
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 vulnerability, while very serious, will have very little impact on the day to day of most users and I don't expect to see this exploit much "in the wild." Frankly, there are far too many open networks that are much easier to exploit for an attacker to gather personal information.
The attack vector using KRACK is simply too small (and will continue to decrease) to make these attacks widespread. There are 10 CVEs associated to this vulnerability, 9 client related and 1 infrastructure related. Patching the infrastructure mitigates 8 of the CVEs (including the most serious) mainly leaving client-to-client connections vulnerable (when was the last time you used and ad-hoc or Wi-Fi Direct 802.11 connection?). Patching the client mitigates all but the infrastructure CVE. Don't want to patch the OS? Patching even the network driver on the client will mitigate at least 2 of the CVEs.
Two of the biggest target operating systems, Windows (7+) and iOS (10.3.1+), were not vulnerable on day 0 unless on a network with 802.11r (fast roaming/transition) enabled. Of those two, Windows already had a patch released over a week ago. Patches are also out for most of the common flavors of Linux and in beta for all Apple OSes. You can expect most of the current mainstream operating systems (and nearly all the Linux variants) to have a patch released within a couple weeks. All in an age where OS upgrades are easier and more automated than ever.
This leaves the legacy operating systems and IoT to consider. Fifteen to twenty years ago, legacy devices would have been much more of a concern but today with commodity electronics that are much cheaper and often replaced every couple years (if they last that long), we have a much lower percentage of "old" devices hanging around. For the IoT? If you really want to watch my lights (or whatever) turn off and on, please feel free. Yes there is potential for more meat on the IoT bone, but mainly only in very limited corner cases and not to the average user.
When it comes to 802.11r, most consumer access points (aka "routers" by many) simply do not support 802.11r. Vendors tend to see little value in adding support for it when the majority of their equipment is deployed to environments where it is the only wireless AP. Single AP means no roaming which certainly precludes the need for fast roaming and also means no patch needed. Of the ones that I have seen that support it, most have 802.11r disabled by default (primarily due to issues some clients who don't support 802.11r have with it).
802.11r is much more widespread in multi-AP deployments and most of the common vendors for such environments (Cisco, Aruba, Ubiquiti, Ruckus, Aerohive, etc) have patches out already for some or all of their devices. These are also the environments that are more likely to have paid staff or support consultants that are aware of this exploit.
Many "high value" targets are also out as they enforce the use of multiple layers of encryption when using wireless. Yes, you can break the 802.11 encryption, but not the VPN encryption in use on the connection or the HTTPS traffic within the VPN tunnel. Targets that depend on keeping their data secure aren't trusting to encryption that only covers from the client to the AP.
Even targets that aren't high value are often using other encryption without any change in behavior. Most "big" websites already push all their traffic to HTTPS as do most sites handling any sort of financial or personal information.
To perform many types of MitM attacks (which really require bidirectional control), an attacker needs to have targets that are either using GCMP or have both using 802.11r and clients with the 4-way handshake vulnerability. GCMP isn't common yet and we have already hit on 802.11r and client patching. So while the MitM demonstration shown as a proof of concept is impressive, the real world implications are fairly limited.
If you understand this vulnerability enough to exploit it successfully, you will quickly realize what I already mentioned above....it is much easier to exploit the many open wireless networks that exist all around us.
anything a wireless network owner can do ...?
If the devices themselves form a sort of unknown "man-in-middle" potential attack, a network owner can caution clients to consider using VPNs, Tor proxies, https, ssh, and various other encrypted software-based networking methods that prevent a potential WPA2 middleman/eavesdropper from being able to derive much advantage it.