Android Leaks Some Traffic Even When 'Always-On VPN' Is Enabled (bleepingcomputer.com) 30
Mullvad VPN has discovered that Android leaks traffic every time the device connects to a WiFi network, even if the "Block connections without VPN," or "Always-on VPN," features is enabled. BleepingComputer reports: The data being leaked outside VPN tunnels includes source IP addresses, DNS lookups, HTTPS traffic, and likely also NTP traffic. This behavior is built into the Android operating system and is a design choice. However, Android users likely didn't know this until now due to the inaccurate description of the "VPN Lockdown" features in Android's documentation. Mullvad discovered the issue during a security audit that hasn't been published yet, issuing a warning yesterday to raise awareness on the matter and apply additional pressure on Google.
Android offers a setting under "Network & Internet" to block network connections unless you're using a VPN. This feature is designed to prevent accidental leaks of the user's actual IP address if the VPN connection is interrupted or drops suddenly. Unfortunately, this feature is undercut by the need to accommodate special cases like identifying captive portals (like hotel WiFi) that must be checked before the user can log in or when using split-tunnel features. This is why Android is configured to leak some data upon connecting to a new WiFi network, regardless of whether you enabled the "Block connections without VPN" setting.
Mullvad reported the issue to Google, requesting the addition of an option to disable connectivity checks. "This is a feature request for adding the option to disable connectivity checks while "Block connections without VPN" (from now on lockdown) is enabled for a VPN app," explains Mullvad in a feature request on Google's Issue Tracker. "This option should be added as the current VPN lockdown behavior is to leaks connectivity check traffic (see this issue for incorrect documentation) which is not expected and might impact user privacy." In response to Mullvad's request, a Google engineer said this is the intended functionality and that it would not be fixed for the following reasons:
- Many VPNs actually rely on the results of these connectivity checks to function,
- The checks are neither the only nor the riskiest exemptions from VPN connections,
- The privacy impact is minimal, if not insignificant, because the leaked information is already available from the L2 connection.
Mullvad countered these points and the case remains open.
Android offers a setting under "Network & Internet" to block network connections unless you're using a VPN. This feature is designed to prevent accidental leaks of the user's actual IP address if the VPN connection is interrupted or drops suddenly. Unfortunately, this feature is undercut by the need to accommodate special cases like identifying captive portals (like hotel WiFi) that must be checked before the user can log in or when using split-tunnel features. This is why Android is configured to leak some data upon connecting to a new WiFi network, regardless of whether you enabled the "Block connections without VPN" setting.
Mullvad reported the issue to Google, requesting the addition of an option to disable connectivity checks. "This is a feature request for adding the option to disable connectivity checks while "Block connections without VPN" (from now on lockdown) is enabled for a VPN app," explains Mullvad in a feature request on Google's Issue Tracker. "This option should be added as the current VPN lockdown behavior is to leaks connectivity check traffic (see this issue for incorrect documentation) which is not expected and might impact user privacy." In response to Mullvad's request, a Google engineer said this is the intended functionality and that it would not be fixed for the following reasons:
- Many VPNs actually rely on the results of these connectivity checks to function,
- The checks are neither the only nor the riskiest exemptions from VPN connections,
- The privacy impact is minimal, if not insignificant, because the leaked information is already available from the L2 connection.
Mullvad countered these points and the case remains open.
Open Source (Score:1)
Re:Open Source (Score:4, Informative)
When you connect to a wifi network, devices (not just Android) try to detect if you're on a "captive portal" network, like lots of public wifis, where going to any web page transparently sends you to the network's login page. Because these are done with DNS tricks and/or transparent network proxies, the only real way to detect them is to try a few DNS lookups that the device knows will not result in a local IP, then trying to load a known web page and see that you don't get an invalid SSL cert.
And then, to connect to most VPNs, you're going to need to do one or more DNS lookups to find the VPN endpoint.
So I'm not sure how you can ever reliably connect to a VPN without sending a little non-VPN traffic first, to gauge the state of the connection and find the VPN server.
re: leaked VPN connect (Score:2)
So I'm not sure how you can ever reliably connect to a VPN without sending a little non-VPN traffic first, to gauge the state of the connection and find the VPN server.
If you already know the server IP addresses there is no need for a DNS leak, er request, prior to establishing the VPN.
Why do you "need to gauge the state of the connection" with unsecured packets to "reliably connect"? I don't understand what you are getting at. Latency? Packet loss? Server response?
Re: (Score:3)
Most VPNs use DNS for endpoints, because otherwise you have a big management PITA for any change.
You have to check the connection to see if you are "live" on the Internet yet. Many public wifs use a "captive portal", where when you connect, you aren't really on the Internet. You get an IP and DNS servers and such from DHCP, but no matter what site you try to go to, you actually get sent to a portal web page, where you have to accept terms, enter some info (like room number for hotels), possibly pay fees, et
Re: (Score:3, Interesting)
You have to check the connection to see if you are "live" on the Internet yet.
Simply connecting to a network that advertises a router is sufficient. If the VPN connection fails it can share the reason with you. It is redundant, unnecessary and dangerous to check a Google server to decide whether or not you are "live". This is nothing more than an excuse to collect data.
Many public wifs use a "captive portal", where when you connect, you aren't really on the Internet. You get an IP and DNS servers and such from DHCP, but no matter what site you try to go to, you actually get sent to a portal web page, where you have to accept terms, enter some info (like room number for hotels), possibly pay fees, etc. Usually you cannot go anywhere else (no other websites, no other types of traffic) until you manually click something on the portal page.
In the days of HTTP, this could be done with a transparent proxy, but now that browsers default to HTTPS, that can't work (because all you'd get is an SSL certificate mismatch error).
If they didn't do this, users would connect to hotel/airport/coffee-shop wifi and not get anywhere, with the vast majority not knowing or understanding why.
Captive portals can be signaled via DHCP. Not necessary to communicate with Google servers to find out.
Re: leaked VPN connect (Score:2)
> If the VPN connection fails it can share the reason with you.
Would it be able to tell you anything other than the connection failed? That wouldn't be helpful for most users (though arguably the ones using a VPN are likely to figure it out). The request for a second setting to do what you're describing seems appropriate.
Re: (Score:3)
Re: (Score:2)
There will always be a non-zero amount of non-VPN traffic before the VPN connection can be established.
Sure, but Android continues to send traffic outside the tunnel after the connection is made. Other than a DNS lookup to find the server ip, and even that is not strictly necessary, no internet traffic other than UDP to the VPN server is required.
There will always be ARP traffic and other local chatter but there should be nothing that boinks the WAN after the VPN is established if that is what has been configured.
Problem is that Android continues to send internet traffic outside the set up tunnel contrary
Re: (Score:2)
On Android you need an app to set up a VPN connection. There are generic ones for Wireguard and OpenSSL, but Mullvad supplies their own that has a few extra features like an optional DNS server with ad and malware blocking.
On Windows when you use their app, Windows often thinks your network connection is broken because the initial attempt to contact Microsoft's server set up just to check if your internet connection works fails. This usually happens when the machine wakes up from sleep and the VPN is reconn
Re: (Score:2)
FYI: Android natively supports three variations of IPSec without the use of an app. Settings --> Network & Internet --> VPN --> +
IKEv2/IPSec MSCHAPv2
IKEv2/IPSEC PSK
IKEv2/IPSec RSA
Re: (Score:2)
Thanks, that's interesting. I find Wireguard is a lot more stable on mobile devices though.
Re: (Score:2)
> So I'm not sure how you can ever reliably connect to a VPN without sending a little non-VPN traffic first, to gauge the state of the connection and find the VPN server.
You just do. Send IP packets. My Debian laptop doesn't talk to Google to get on my VPN.
Android considers that in some cases that may not work so it leaks data in all cases.
Everybody would be happy with a little 'paranoid mode' switch.
Re: (Score:2)
Yes and in particular with Wireguard (which is pushed by Mullvad too, for good reasons) there isn't really a state of "vpn open", I mean sure the VPN app can show you something if some traffic is going and the OS will bring up some interface as an abstraction on that level but for the protocol itself each peer just knows where's the IP(:port?) from where the other one spoke last time and when was the last time it got a pa
Re: (Score:2)
FYI: RFC 7710: Captive-Portal Identification Using DHCP or Router Advertisements (RAs) [ietf.org]
I suspect it is not widely accepted or implemented yet.
Re: (Score:1)
Summary fail (Score:1)
The summary fails to mention that another reason given by Google is that "the VPN may be a split tunnel, letting part of the traffic over the underlying network, or only affect a given set of apps. In both these cases, the connectivity checks are still necessary for smooth operation of all the legitimate traffic that doesn't go over the VPN." This matters, and the summary is misleading by missing it out. The other reasons offered by Google look very reasonable too. Don't want anyone to know you use an An
Only surprise is how few are surprised (Score:2)
After a certain point, one has grown numb to such vagaries.
They say ... (Score:2)
So no captive portal functionality? (Score:2)
Does the VPN company figure it's better to have the connection fail instead, requiring the user to turn off their VPN on a public wifi network, open a browser, and click the link on the random website they've been forcibly redirected to?
Sounds so much better.
Re: (Score:2)
You are ignoring the specific feature that's discussed here. Normal VPN connections work just as you'd like and expect them to, basically going around the VPN to propose you a login to the captive portal and doing other similar things. We aren't discussing that here, they work perfectly well (I mean as designed and expected).
The discussion here is about the "Block connections without VPN" option that is supposed to block EVERYTHING (except what goes over the VPN). You don't get to connect around the VPN to
Re: (Score:2)
Isn't the "Block connections without VPN" option supposed to block existing connections that were made before the VPN was enabled?
Like what iOS doesn't do?
These connectivity checks do things like allow automatic switchover to cellular data when your internet connection goes down but your WiFi router is still up, and automatically switching back when WiFi comes good again.
The type of data being leaked is along the lines of "someone has an android device on this network". Kinda useless information, since the
Re: (Score:2)
This is supposed to be "always-on" VPN. Even if the machine reboots the traffic should go entirely over VPN. There should be no "existing connections that were made before the VPN was enabled", if there are this thing already failed. If there is another transient failure when just enabling this VPN for the very first time (which can be years in the past) this might be another issue, but more of a corner case than the one discussed here.
They are addressing the L2 thing in TFA - the attacker might not be the
Chrome, Other Product, Same Evil Google (Score:2)
I have a screenshot of Little Snitch somewhere, which shows that Google Chrome is directly trying to access Google DNS (8.8.8.8 and 8.8.4.4) in spite of my LAN DHCP configuration which gives another DNS IP (a pi-hole in my case).
Google products wouldn't try to evade protections, would they ?
Does this fall under the DRM circumvention laws ?
Re: (Score:2)
> Google products wouldn't try to evade protections, would they ?
It's a cat-and-mouse game but you can subscribe to known public DNS server lists and try to block them at the firewall. IMO this is especially important on an IoT network.
Had to Shut of Wifi On Phone (Score:2)
We need no network access by default (Score:1)