• Off Topic

  • Android leaks connectivity check traffic - Mullvad Blog

  • [deleted]

  • Post #1
  • Edited

An ongoing security audit of our app identified that Android leaks certain traffic, which VPN services cannot prevent. The audit report will go public soon. This post aims to dive into the finding, called MUL22-03.

We researched the reported leak, and concluded that Android sends connectivity checks outside the VPN tunnel. It does this every time the device connects to a WiFi network, even when the Block connections without VPN setting is enabled.

We understand why the Android system wants to send this traffic by default. If for instance there is a captive portal on the network, the connection will be unusable until the user has logged in to it. So most users will want the captive portal check to happen and allow them to display and use the portal. However, this can be a privacy concern for some users with certain threat models. As there seems to be no way to stop Android from leaking this traffic, we have reported it on the Android issue tracker.

Even if you are fine with some traffic going outside the VPN tunnel, we think the name of the setting (“Block connections without VPN”) and Android’s documentation around it is misleading. The impression a user gets is that no traffic will leave the phone except through the VPN. Due to this, we have reported another issue, where we suggest improving the Android documentation.

Steps to reproduce

Ensure Always-on VPN and Block connections without VPN is enabled in system settings.
Disconnect from your WiFi.
Start monitoring network traffic from and to the Android device, e.g. by running tcpdump on your router.
Connect to your WiFi.
Observe that the traffic isn't limited to VPN traffic, but also consists of DNS lookups, HTTP(S) traffic and potentially also NTP traffic.
As a comparison, the privacy and security focused Android based distribution GrapheneOS provides users with the option to disable connectivity checks. If that option is enabled, the above leaks could not be observed by us.

Privacy concerns

The connection check traffic can be observed and analyzed by the party controlling the connectivity check server and any entity observing the network traffic. Even if the content of the message does not reveal anything more than "some Android device connected", the metadata (which includes the source IP) can be used to derive further information, especially if combined with data such as WiFi access point locations. However, as such an de-anonymization attempt would require a quite sophisticated actor, most of our users are probably unlikely consider it a significant risk.

Conclusions and recommendations

There is nothing we can do in the app to fix the leaks. We can however inform our users that they exist, and be transparent about the limitations of the Android operating system. This allows everyone can make an informed decision.

As a closing note, we would like to recommend Google to adopt the ability to disable the connectivity checks, like on GrapheneOS, into stock Android.

Mullvad Blog

Thoughts? What happens if you disable internet connectivity checks on grapheneOS?

    [deleted]

    GrapheneOS Project Twitter Response:

    Connectivity checks are one of the 4 Google services used by AOSP. We replace these 4 services with GrapheneOS services by default with toggles to disable them or use the standard Google servers. Connectivity checks are low level and are run on each network to check if it works.

    Connectivity checks are a special case since they still need to detect whether each underlying network has internet access when you're using a VPN.

    If you're using a VPN and want to hide that you use GrapheneOS, you should switch connectivity check toggle to Standard (Google).

    We also provide a 3rd 'Disabled' option for connectivity checks. This loses support for automatically switching to a working network, handling captive portals from the OS and delaying internet-dependent scheduled jobs until the network has internet connectivity. It's your choice.

    If you're using a VPN and want to appear as a regular Android device, the Standard (Google) option is the best fit. Connectivity checks simply make HTTPS and HTTP GET requests with Android's Java standard library with a standard frozen user agent to look for a 204 response code.

    A full list of default connections made by GrapheneOS is available at https://grapheneos.org/faq#default-connections

    If you have Private DNS set to automatic, it tests resolving a randomized subdomain via DoT with the network-provided DNS. We may add a note about it to the page but it's part of DNS.

    You should also read our section on app link verification: https://grapheneos.org/usage#app-link-verification

    App link verification allows a domain to delegate handling links to an app by default. For example, piped.mha.fi/.well-known/asse… authorizes YouTube app. For NewPipe, users need to manually enable it.

    Other than replacing insecure network time, we don't consider replacing these services important. It's outside our core focus of making substantial privacy and security improvements. See https://www.grapheneos.org/features for an overview of most of the improvements we offer over Android 13.

    Source: https://nitter.it/GrapheneOS/status/1579616922450395136#m