In October, security researchers discovered a major vulnerability in a Wi-Fi's WPA2 security called "KRACK." This "Key Reinstallation Attack" can disrupt the initial encryption handshake that happens when an access point and a device first connect, allowing an attacker to read information assumed to be securely encrypted. It's possible to totally defeat WPA2 encryption using KRACK, allowing a third party to sniff all the Wi-Fi packets you're sending out. Any device that uses Wi-Fi and WPA2 is most likely vulnerable to the bug, which at this point is basically every wireless gadget on Earth.

Google and the rest of the OEMs are working to clean up Android's KRACK epidemic, and, on Monday, Google addressed the bug in the November Android Security Bulletin. A patch was posted this week to the Android Open Source Project (AOSP) repository, and, at the same time, Google started rolling out a November security update to Google Pixel and Nexus devices. But if you read the bulletin closely, you'll see the November security patch for Google devices does not contain the KRACK fix.

Google's Android security bulletin is not the clearest thing on Earth. The company posted three different general Android security bulletins for November on Monday, labeled " 2017-11-01 ," " 2017-11-05, " and " 2017-11-06. " The Pixel/Nexus specific security page mentions that Google is pushing out only the "11-05" update to devices, leaving OEMs to deal with the rest. However, Google also had language saying the "11-05" release "addresses all issues in the November 2017 Android Security Bulletin," which would suggest a KRACK fix.

After contacting Google, we got word that Pixel and Nexus devices will only get patches covering the November 1 and 5 bulletins this month, and it seems Google has changed the ambiguous language in the security bulletin. We also have a bit of news: the KRACK vulnerability won't be patched on Google-branded devices until December. That's right, Pixel and Nexus owners will have to survive a whole extra month being vulnerable to KRACK. But this isn't as huge of a problem as you might imagine.

How whack is KRACK on Android, really?

The KRACK vulnerability affects nearly all Wi-Fi devices, but the researchers put a big target on Android specifically when they said the attack was "exceptionally devastating against Linux and Android 6.0 or higher." The reasoning the post laid out was that because Android could be tricked via KRACK into installing an all-zero encryption key, the researchers claimed it was "trivial to intercept and manipulate traffic sent by these Linux and Android devices."

KRACK can essentially completely break WPA2 security, but the thing is, while Android does use WPA2 for encryption where available, Android doesn't rely on WPA2 for security. Android is used to running on a variety of networks. It has to deal with hundreds of carrier configurations around the world, that random coffee shop hot spot that you share with a bunch of strangers, and sometime just connecting to an unencrypted, open Wi-Fi connection. Android already assumes the network is hostile, so even if you break WPA2 security, you're only treated to a stream of individually encrypted connections. All the Google apps come with their own encryption, and Google's development documents tell developers to "Send all network traffic from your app over SSL." Connecting to websites with HTTPS (like Ars Technica!) will still be secure, and all of Android's back-end Play Services stuff, like the 24/7 connection to Google, is also encrypted.

KRACK is a big deal for some devices, but it's mainly those that use WPA2 as their primary form of security. A lot of times this is IoT stuff like video cameras or "dumber" devices like a printer. On Android, killing WPA2 security is no different from logging in to an open coffee shop Wi-Fi with 25 other random people. Android is used to this, and the OS and apps generally take the right precautions.

The demonstration video from the KRACK researchers does a good job of conveying the actual threat. After using KRACK to break WPA2 security, they still need some other vulnerability to actually do anything. In the case of the video, after breaking WPA2, they find an improperly configured website—Match.com—and use a tool called "sslstrip" to bypass the HTTPS protections that are normally there on the login page. The victim can see that this is happening—there's no indication that the site is secure—but less technical users might not pick up on the indicators. If the victim logged in over an HTTP connection, the attacker could potentially read their username and password.

Removing the encryption on Match.com is a problem specific to Match.com, though, and the researchers admit that "bypassing https does not work against properly configured websites, but it does work against a significant fraction." It stinks that Android's WPA2 security can be broken, but it was only one portion of Android's defense-in-depth strategy. An attacker will still need to have some other vulnerability at the ready in order to accomplish anything. Any competently written app or website should still be safe.

Android's security bulletin process

We can also shed a little light on Google's crazy triple security bulletin release this month. Releasing three security bulletins all at once might seem a little excessive, but the reason has to do with coordination with the Android ecosystem. Google has to not only patch AOSP itself but coordinate a rollout among device OEMs and hardware component vendors. The three bulletins allow for flexibility in development and release time and cover different areas of responsibility for different companies.

Normally, there are two security bulletins at the beginning of the month. The bulletin dated the first of the month covers bugs in AOSP, which are fixed directly by Google. These are generally going to be easier to implement on devices because only Google and the OEM are involved. Not every security vulnerability happens exclusively in AOSP, though—sometimes a bug exists in the proprietary code controlled by various component vendors that produce the SoCs, Wi-Fi modules, and other components in a device. Since these patches are the responsibility of the vendor (Qualcomm, Broadcom, Nvidia, etc) and require coordination with Google and the OEM, they can take longer to fix. These bugs therefore get filed to a second security bulletin, dated the fifth of the month.

Google notifies OEMs and vendors of everything in the 01 and 05 patches about 30 days before the public release date and shares preview code with the vendors. The 30 days of advanced notice allows everyone to develop an update specifically for their devices. Then, 30 days later, everyone (theoretically) does a coordinated update release, and Google posts the security bulletin for that release. Ideally OEMs ship the "05" patch every month, but if vendor coordination issues crop up, they can still fall back to shipping just the AOSP fixes in the "01" patch. The patch dates are cumulative, so any vendor claiming the "05" date also has covered the bugs in the "01" release.

Anything dated past the 5th (usually the 6th) is an "out of cycle" patch, meaning it is issued outside the usual monthly cadence. OEMs might not have had this code for very long, so it might not make it into the patch released at the beginning of the month. OEMs can rush out an emergency patch if they feel the problem is important enough, or they can just wait and roll it into next month's patch. In this specific case, Google is one of these OEMs and will be rolling the 11-06 patch into the December security patch.

As for the rest of the OEM landscape, a few have already rolled out a KRACK patch, and others should have things patched up this month. Essential and OnePlus both shipped a patch for KRACK last week. To add more confusion to the situation, Essential is shipping with the "11-05" security patch designation this month, not the 11-06 label, despite already fixing KRACK. The company admits it should be using the 11-06 patch label but says it "wasn't worth delaying the roll-out to fix the patch date." Samsung should have a KRACK fix out this month, too: it posted a November Security Maintenance Release bulletin that contains all the KRACK CVEs.

Users can see what patch level they're on via the "Android security patch level" field on the "About Phone" screen. Bulletin releases like "2017-11-06" will be reformatted to "November 6th, 2017," and each release date covers the vulnerabilities in the previous releases. This month, users will get a monthly security patch, but it might be dated November 5 and, therefore, not have the KRACK fix. Unless you see "November 6th, 2017" in your "About Phone" screen, your phone isn't patched for KRACK—but either way you should still be fine.