Virtual Private Networks (VPNs) on Android and iOS are in the news. It’s been discovered that in certain circumstances, some of your traffic is leaked so it ends up outside of the safety cordon created by the VPN.
Mullvad, the discoverers of this Android “feature” say that it has the potential to cause someone to be de-anonymised (but only in rare cases as it requires a fair amount of skill on behalf of the snooper). At least one Google engineer claims that this isn’t a major concern, is intended functionality, and will continue as is for the time being.
MUL22-03
The Android discovery, currently named MUL22-03, is not the VPN’s fault. The transmission of data outside of the VPN is something which happens quite deliberately, to all brands of VPN, and not as the result of some sort of terrible hack or exploit. Although the full audit report has not yet been released, the information available so far may be worrying for some. According to the report, Android sends “connectivity checks” (traffic that determines if a connection has been made successfully) outside of whichever VPN tunnel you happen to have in place.
Perhaps confusingly, this also occurs whether or not you have “Block connections without VPN” or even “Always on VPN” switched on, which is (supposed) to do what you’d expect given the name. It’s quite reasonable to assume a setting which says one thing will not in fact do the opposite of that thing, so what is going on here?
The leakage arises as a result of certain special edge case scenarios, in which case Android will override the various “Do not do this without a VPN” settings. This would happen, for example, with something like a captive portal. A captive portal is something you typically access when joining a network—something like a hotspot sign-in page stored on a gateway.
Why? Because VPNs run on top of whatever Internet-connected network you are on, so you have to join a network before you can establish your VPN connection. Anything that happens before you establish your VPN connection can’t be protected by it.
As per Bleeping Computer, this leakage can include DNS lookups, HTTPs traffic, IP addresses and (perhaps) NTP traffic (Network Time Protocol, a protocol for synchronising net-connected clocks).
Mullvad VPN first reported this a documentation issue, and then asked for a way to “…disable connectivity checks while ‘Block connections without VPN’ (from now on lockdown) is enabled for a VPN app.”
Google’s response, via its issue tracker was “We do not think such an option would be understandable by most users, so we don’t think there is a strong case for offering this.”
According to Google, disabling connectivity checks is a non-starter for four reasons: VPNs might actually be relying on them; “split channel” traffic that doesn’t ever use the VPN might be relying on them; it isn’t just connectivity checks that bypass the VPN anyway; and the data revealed by the connectivity checks is available elsewhere.
The rest is a back and forth debate on the pros and cons of this stance, which is still ongoing. At this point, Google is not budging.
iOS has entered the chat
It seems this isn’t something only confined to Android. There are similar things happening on iOS 16, with multiple Apple services claimed to be leaking outside of the VPN tunnel including maps, health, and wallet.
We confirm that iOS 16 does communicate with Apple services outside an active VPN tunnel. Worse, it leaks DNS requests. #Apple services that escape the VPN connection include Health, Maps, Wallet.
We used @ProtonVPN and #Wireshark. Details in the video:#CyberSecurity #Privacy pic.twitter.com/ReUmfa67ln— Mysk 🇨🇦🇩🇪 (@mysk_co) October 12, 2022
According to Mysk, the traffic being sent to Apple isn’t insecure, it’s just going against what users expect.
All of the traffic that appeared in the video is either encrypted or double encrypted. The issue here is about wrong assumptions. The user assumes that when the VPN is on, ALL traffic is tunneled through the VPN. But iOS doesn’t tunnel everything. Android doesn’t either.
They suggest that one way forward to stop this from happening would be to treat VPN apps as browsers and “require a special approval and entitlement from Apple”.
There probably won’t be much movement on this issue until the release of the full report on MUL22-03, but for now the opinion from those involved in testing seems to be that the risk is small.