If you own a Google Pixel and have updated to the latest December 2020 security update, you may have found that you are unable to connect to certain enterprise WiFi networks. If this is the case, then know that you are not alone. This is not a bug but is rather an intentional change that Google made to Android 11 that just so happens to be present in the build pushed to Pixel phones in December. All Android phones that will receive an update to Android 11 are expected to eventually have this change*, meaning we’re going to see a lot of angry complaints in the near future from users who can’t add their enterprise WiFi network. Here’s what you need to know about why Google made the change and what you can do about it.
Why can’t I add my enterprise WiFi network in Android 11?
The problem that many users will come across after they update to Android 11* is that the “Do Not Validate” option under the “CA certificate” dropdown has been removed. This option previously appeared when adding a new WiFi network with WPA2-Enterprise security.
Why was this option removed? According to Google, having users select the “do not validate” option is a security risk as it opens up the possibility of leaking user credentials. For example, if a user wants to do online banking, they point their browser to the known domain name owned by their bank (e.g. www.bankofamerica.com). If the user notices that they clicked a link and their browser has loaded a webpage from the wrong domain, then they’ll of course be hesitant to give their banking account information. But on top of that, how does the user know that the server their browser is connecting to is the same one that everyone else connects to? In other words, how does one know that the banking website they’re seeing isn’t just a fake version injected by a malicious third-party that has gained access to the network? Web browsers make sure this doesn’t happen by verifying the server certificate, but when the user toggles the “do not validate” option when connecting to their enterprise WiFi network, they’re preventing the device from doing any certificate validation. If an attacker performs a man-in-the-middle attack and takes control of the network, then they can point client devices to illegitimate servers owned by the attacker.
Network admins have been warned about this potential security risk for years, but there are still many enterprises, universities, schools, governmental organizations, and other institutions that have configured their network profiles insecurely. Going forward, the security requirements adopted by the WiFi Alliance for the WPA3 specification has mandated this change, but as we all know, many organizations and governments are slow at upgrading things and tend to be lax when it comes to security. Some organizations — even knowing the risks involved — still recommend users disable certificate validation when connecting to their WiFi network.
A screenshot showing instructions from a neighborhood school board on how to connect to their WiFi network. Notice the 4th step where this insecure practice is told to users.
It could take years before devices and routers supporting WPA3 become widespread, so Google is taking a big step right now to ensure that users can no longer subject themselves to the risks of skipping server certificate validation. With this change, they’re putting network admins who continue to have users insecurely connect to their enterprise WiFi on notice. Hopefully, enough users will complain to their network admin that they can’t add their enterprise WiFi network as instructed, prompting them to make changes.
*Because of the way Android software updates work, it’s possible that the initial release of Android 11 for your particular device won’t be affected by this change. This change was only introduced to Pixel phones with the December 2020 update, which carries build number RQ1A/D depending on the model. However, since this is a platform-level change merged to the Android Open Source Project (AOSP) as part of the “R QPR1” build (as it’s known internally), we expect other Android phones to eventually feature this change.
What are some solutions to this problem?
The first step in this situation is to realize that there isn’t a whole lot the user can do on their device. This change cannot be avoided unless the user chooses not to update their device — but that potentially opens up a whole host of other issues, so it’s not recommended. Thus, it’s imperative to communicate this issue to the network admin of the affected WiFi network.
Google recommends that network admins instruct users on how to install a root CA certificate or use a system trust store like a browser, and in addition, instruct them on how to configure the server domain name. Doing so will allow the OS to securely authenticate the server, but it does require the user to do a few more steps when adding a WiFi network. Alternatively, Google says that network admins can create an app that uses Android’s WiFi suggestion API to automatically configure the network for the user. To make things even easier for users, a network admin can use Passpoint — a WiFi protocol that is supported on all devices running Android 11 — and guide the user to provision their device, allowing for that to automatically reconnect whenever it is near the network. Since none of these solutions require the user to update any software or hardware, they can continue using the same device they already have.
Practically speaking, though, it’ll take some time for enterprises and other institutions to adopt these solutions. That’s because they need to be made aware of this change in the first place, which admittedly has not really been communicated to users that well. Many network admins have been eyeing these changes for months, but there are also many who may be unaware. If you are a network admin seeking more information on what’s changing, you can learn more in this article from SecureW2.
The post PSA: Android 11 will no longer let you connect to some enterprise WiFi networks appeared first on xda-developers.
from xda-developers https://ift.tt/2Lh30cE
via IFTTT
No comments:
Post a Comment