On Wed, Oct 18, 2017 at 02:29:56PM -0400, Keith Wright wrote:

This is very embarrassing for the authors of the standard, but is it really a big problem? Several meetings ago, somebody brought a device to the WLUG meeting that, as I understood it, pretends to be a wireless router and interposes itself into any nearby connection. If things like that exist, why care about encryption vulnerability?

Because with properly configured wireless and patched clients, you can be sure you are connecting to the trusted network, not a Man-in-the-Middle. It requires mutual authentication, which happens for example on the WPI wireless network by using EAP-TLS certificates. The client is supposed to verify the server's certificate and the server of course verifies the client's certificate. Unfortunately, most networks don't use EAP but rather use Pre-Shared Keys (WPA2-PSK).

If you need to patch both sides to be secure, then you are not secure in the coffee shop no matter what you do. In any case, if you are using the wireless to connect to a web site or "cloud" server, then the wireless connection is the least of your insecurities.

In the strictest sense this is true, but as far as the KRACK attack goes, the wireless AP side is much less likely to be a problem, because the vulnerabilities are in parts of the standards that are not often used (802.11r "Fast Roaming" for example). The client-side vulnerabilities, especially in Linux/Android, are much more serious. On Linux, the client can be tricked into using a null session key. However, in a coffee shop KRACK is moot because most coffee shops don't use encryption at all to begin with. In any case, WPI's recommendation to use the VPN if you are not sure of your device's or the network's immunity to KRACK is sound, because even if there was a M-i-t-M, they still would not be able to decrypt the VPN traffic. Security is helpful in layers. Belt-and-suspenders.