Does a VPN Protect Against KRACK? What the Patch Fixes

If you are buying a VPN because a headline said KRACK breaks Wi-Fi encryption, you are fixing the wrong layer. That 2017 disclosure described a family of key reinstallation attacks against the WPA2 four-way handshake, and the repair arrived as operating system updates, wireless driver patches, and router firmware. A tunnel can hide your traffic from the local network, but it cannot repair a handshake that finishes below it. So the first question is not which VPN to buy; it is which of your devices still runs an unpatched wireless stack.

The same distinction answers the budget worry. Someone who cannot afford a subscription was never shut out of the real remedy, because the remedy was a free update. What costs money is replacing hardware that no longer receives one.

What the attack actually manipulated

WPA2 derives a fresh pairwise key at association time through a four-way handshake. The access point sends a nonce, the client answers with its own, both sides compute the pairwise transient key, and the access point confirms with a message the client acknowledges. A key reinstallation attack interferes with that sequence instead of guessing the passphrase, forcing a client to install a key it has already installed. Each reinstallation can reset the transmit nonce and the receive replay counter tied to that key.

Once those counters move backwards, some traffic that should have been rejected becomes acceptable again. Depending on the variant and the implementation, an attacker in radio range could replay frames, decrypt frames, or inject them. The group-key handshake and the fast-transition handshake had their own variants, which is why the advisory listed several attack names rather than one.

Android 6.0 and later was the worst case. Its wpa_supplicant versions could be pushed into installing an all-zero key, which made decryption far easier than on platforms where reinstallation only reset counters. That detail separated a theoretical weakness from a practical one on the most common phone platform of the time.

The fix lives in the wireless stack

The upstream correction told supplicants and access points to ignore a retransmitted handshake message once the key was already installed. Patched builds of wpa_supplicant and hostapd carried it, and distributions backported it into older branches, so the string printed by wpa_supplicant -v is a starting point rather than a verdict. Read the distribution's security advisory and confirm the specific patch, not only the version number. A build that reports an old version can still be fixed, and a build that reports a new one can still be missing a vendor backport.

Both ends of the link need attention. A repaired router does not patch the laptop that associates with it, and a repaired laptop does not patch the router. Vendors published per-product advisories, and router fixes commonly trailed phone updates because each model needs its own firmware build. If a device's last release predates the advisory, treat it as unpatched until the vendor says otherwise.

For equipment you cannot update, the options are narrow and unglamorous. Retire it, keep it off networks that carry sensitive traffic, or confine it to a segment where its only peers are equally expendable. None of those options involve a subscription, and none of them are improved by choosing a different tunnel provider.

What a tunnel does cover

A VPN moves the boundary. Your device encrypts each packet and sends it to a VPN server, which decrypts it and forwards it onward. A person who manipulates the Wi-Fi link sees outer tunnel packets, not the payload inside them, so a reinstallation attack that exposes link-layer frames does not automatically expose the content of the tunneled connection. That protection holds even while the wireless stack underneath remains vulnerable, which is exactly why the two controls get confused.

The qualifier is "tunneled." Split tunneling, a bypass list, or a captive-portal exception sends some traffic outside the tunnel, and that traffic gets no benefit from it. So does traffic from other devices on the same network that never installed the client. A tunnel is a per-device, per-route decision, not a property of the room, and a router-level VPN only covers what actually routes through the router.

What the tunnel cannot do is repair the driver, stop a deauthentication flood, or keep an attacker from jamming the channel. It also cannot protect a connection that never enters it. Those are availability and link-layer problems, and they stay with the wireless stack no matter how strong the cipher suite on the tunnel is.

HTTPS and the tunnel protect different hops

A single page load can involve three separate protections: the Wi-Fi link, the tunnel to the VPN server, and the TLS session to the website. Each one is negotiated independently. TLS with a valid certificate and a modern protocol version gives you authenticated encryption between browser and site even when the first hop is hostile, because the certificate check is what stops an impostor from substituting its own key.

That check has weak points at the edges. A redirect from HTTPS to HTTP, a page that loads scripts over plain HTTP, or a user who clicks through a certificate warning all move traffic outside the protected session. HSTS and browser interstitials exist because those mistakes are common, not because TLS is fragile.

Keeping HTTPS and a tunnel does not make the wireless implementation stop being vulnerable. The frames still get decrypted by a buggy driver; the difference is what the attacker finds inside them, and whether that content was already protected by something else.

Repair order for a mixed network

Start with the access point, because it is the device you control and the one every client depends on. Then work through client operating systems, oldest first, since platforms that stopped receiving updates are the ones that will never be patched. Only after that inventory is done does a VPN decision make sense, and it is a decision about exposure, not about repair. Doing it in the other order, tunnel first and firmware later, leaves the actual defect in place for as long as the subscription lasts.

Write down what you verified, including the firmware version and the date. "Updated" is not a state anyone can audit later.

Three checks cover most of the work, and they go in this order. Do not skip the third one just because the first two came back clean.

• Router firmware: compare the installed version with the vendor's advisory page, not with the update button.
• Client OS: confirm the patch level that includes the wireless fix for each phone, laptop, and tablet.
• Leftovers: list devices with no patch path and decide retire, isolate, or accept.

If the leftover list is long, a guest network with client isolation buys time while hardware is replaced. Then test one known client on each band, record the result, and recheck after the next firmware release. The hardware inventory is what makes the next advisory fast; the tunnel is what covers the gap in the meantime.