Mögliches VPN-Leak unter Android

Allgemein
1

Mir ist die Problematik der Captive Portal Checks bekannt, über die Android prüft, ob eine Internetverbindung besteht: Falls ein VPN benutzt wird, gehen diese Verbindungen daran vorbei und sind daher für Firewalls wie RethinkDNS oder Netguard unsichtbar. Zweitens kontaktieren die meisten Androiden Googleserver für diese Verbindungschecks.

Ich habe daher für alle Androiden bei mir im Haushalt, sowohl Custom- als auch Stock-ROMs Mikes Empfehlungsstrecke zu diesem Thema befolgt und seinen Server für diese Verbindungschecks eingestellt, sowie die App Capive Portal Controller aus F-Droid installiert:

https://www.kuketz-blog.de/empfehlungsecke/#captive-portal

Umso erstaunter war ich, als ich bei einer Aufzeichnung des Datenverkehrs kürzlich an der Fritzbox diesen Zufallsfund machte:

Connectivity Check 2
Connectivity Check 2941×356 29.6 KB

Neben den erwarteten Captive Portal Checks zu captiveportal.kuketz.de treten ungefähr gleich häufig Verbindungen zu www.google.com auf. Zu den Zeitstempeln bei Sekunden 28, 39, 48 hatte ich den Flugmodus zuerst ein- und dann wieder ausgeschaltet. Jedes Ausschalten des Flugmodus triggert also eine Verbindung sowohl zum Kuketzserver als auch zu Google.

Bei dem Gerät handelt es sich um ein Samsung-Tablet mit Android 14 Stock-ROM. Es gibt kein Custom-ROM dafür. Das Gerät ist aber entgoogelt, d.h. die Apps für die Googledienste, -Nutzerapps wurden per adb deinstalliert, bis auf essentielle, die für Android unentbehrlich sind (z.B. permissioncontroller). Weiterhin läuft darauf RethinkDNS, das ein VPN aufbaut, durch das alle Verbindungen laufen sollten. Wie bekannt sind Captive Portal Checks zum Kuketzserver unter RethinkDNS nicht sichtbar, da sie am VPN vorbei gehen. Dasselbe trifft jedoch auch für die Verbindungen zu www.google.com zu. Bei diesen Verbindungen handelt es sich also um ein weiteres VPN-Leak. Aller Wahrscheinlichkeit dienen auch sie zur Überprüfung, ob das Gerät online ist.

Ich habe dann versucht, die Verbindungen zu www.google.com zu beeinflussen und zwar mit den adb-Befehlen für Captive Portals, wie unter dem Link oben auf Mikes Empfehlungsstrecke beschrieben. Keiner dieser Befehle beeinflusst diese Verbindungen, d.h. sie lassen sich damit nicht abschalten und auch nicht auf einen anderen Server umleiten. Auch die App Captive Portal Controller zeigt nur den eingestellten Kuketzserver, nicht aber Google an:

Captive Portal Controller
Captive Portal Controller800×462 45.3 KB

Ich habe die Systemapp com.google.android.captiveportallogin (Anmeldung über Captive Portal) als Quelle der Verbindungen in Verdacht. Sie ist die einzige Systemapp mit einem Datenvolumen für Verbindungen ins Netz unter Einstellungen / Verbindungen / Datennutzung / WLAN-Datennutzung. Für sie wird aber kein Datenvolumen in RethinkDNS angezeigt, wie es bei VPN-Leaks zu erwarten ist. Ich habe versucht, sie zu deaktivieren auch mit der adb, was aber nicht funktionierte. Sie per adb zu deinstallieren ist mir zu riskant, da sie fürs WLAN essentiell sein könnte. Ich hatte die Verbindungen und VPN-Leaks zu www.google.com in früheren Aufzeichnungen des Netzverkehrs nicht gefunden und vermute daher, dass sie erst nachträglich, z.B. mit einem Update aktiviert wurden.

Das Samsung Stock-ROM hat in den Einstellungen keinen Schalter, wie einige Custom-ROMs, um Verbindungschecks abzuschalten. Schließlich habe ich dennoch einen Weg gefunden, die Anfragen zu www.google.com zu unterbinden. Unter Einstellungen gibt es in den VPN-Einstellungen des jeweiligen VPNs den Schalter „Verbindungen ohne VPN sperren“.

Verbindungen ohne VPN sperren
Verbindungen ohne VPN sperren800×420 42.7 KB

Damit kommen die Anfragen bei Google nicht mehr am VPN vorbei. Diese Einstellung bringt allerdings Probleme mit sich. Das Gerät lässt sich nicht mehr per FTP erreichen. Die eigentlichen Captive Portal Checks zum Kuketzserver gehen damit trotzdem weiter am VPN vorbei.

Es bleiben dennoch ein paar Fragen zu diesen Verbindungen zu www.google.com, am VPN vorbei:

Registriert Google etwa, wenn der Server für Captive Portal Checks geändert wurde und startet dann seine Fallbackvariante?

Gibt es weitere Möglichkeiten, diese Verbindungen auf dem Gerät zu beeinflussen, außer den genannten?

Bei welchen Androidvarianten treten sie auf? Mein Gerät dürfte kaum das einzige sein, dennoch habe ich im Internet nichts zu dem Thema gefunden.

Gibt es noch mehr VPN-Leaks unter Android?

3 „Gefällt mir“
2

Dein Screenshot zeigt leider nur DNS-Anfragen. www.google.com ist eine der Domains die unter AOSP für Verbindungsschecks benutzt wird.

3

@Chief

Ja, ich habe nach Port 53, DNS-Protokoll gefiltert, weil der komplette Mitschnitt seitenlang ist, also zu groß um ihn hier zu posten. Welcher Teil davon würde Dich interessieren?

Ja, wenn Stock-Androids mit Voreinstellungen betrieben werden, sind meist Googleserver für Verbindungsanfragen voreingestellt und eine der kontaktierten Domains, unter ein paar anderen ist www.google.com. Nachdem allerdings, wie in diesem Fall entweder mit dem Captive Portal Controller oder mit den adb-Befehlen gemäß Mikes Empfehlungsstrecke ein anderer Server hinterlegt wurde, wäre meine Erwartung gewesen, dass keine Verbindungschecks mehr zu Googleservern stattfinden. Ansonsten wären ja der Captive Portal Controller und Mikes Empfehlungsstrecke zu dem Thema den Aufwand nicht wert und für die Katz.

4

Hast du dir die App-Beschreibung durchgelesen?

NOTE: In many OEM provided ROMs, it is NOT a privacy feature because these ROMs are able to bypass captive portal settings..

Es gibt schon einen Grund, warum immer zu Custom-OS geraten wird, statt zu versuchen irgend ein OEM-OS datenschutzfreundlich einzustellen.

Zudem gab es 2022 das letzte offizielle Release der App, also unklar ob das noch funktioniert.

Sollte es sich - wie ich vermute - um Verbindungsschecks handeln, wäre es kein VPN-Leak.

1 „Gefällt mir“
5

Wie ich inzwischen herausgefunden habe, hat ein anderes Team kürzlich bereits vergleichbare Analysen mit Netzwerkprotokollen an einem Router gemacht. Sie testeten mehrere Smartphones zum Vergleich (Pixel und auch Samsung, Android 12 bis 14), haben also repräsentativere Daten:
https://www.pcwrt.com/2025/01/observing-android-vpn-leaks-with-the-pcwrt-router/

Sie resümieren:

If the VPN on the Android phone is working properly, the router should
not see any DNS lookup at all. In other words, any DNS lookup the router
sees is a DNS leak.

Sie unterscheiden auch zwischen Captive Portal Connectivity Checks und Verbindungen zu www.google.com, die sie als „DNS-Leaks“ anstatt „VPN-Leaks“ bezeichnen, kommen insgesamt aber zu dem Schluss:

All we can say is Android VPN leaks.

Weiterhin haben sie festgestellt, dass Android WLAN-Telefonate am VPN vorbeileitet.

@Chief

Custom ROMs sind zumindest zum Teil auch von diesem Problem betroffen. Siehe hierzu die Übersicht von Eylenburg:
https://eylenburg.github.io/android_comparison.htm

Für die Captive Portal Connectivity Checks sind bei CalyxOS und Lineage Googleserver voreingestellt, wie auch schon Mike in seinem CustomROM Vergleich 2023 kritisiert hatte.

Eylenburg nennt zusätzlich einen DNS connectivity check. Das ist vermutlich die Verbindung, die ich zusätzlich zu den Captive Portal Checks zu www.google.com registriert habe und die das zitierte pcwrt-Team als „DNS-Leak“ bezeichnet. Laut Eylenburg haben ALLE Custom ROMs außer GOS dafür Google eingestellt und zwar ohne den Kommentar „can be changed“!

Zum Captive Portal Controller:

Alle Captive Portal Einstellungen habe ich nicht mit der App, sondern adb-Befehlen vorgenommen. Die App nutze ich nur zur Visualisierung und Kontrolle der Einstellungen. Auch die adb zeigt, dass auf meinem Gerät der Kuketz- und nicht ein Googleserver für Captive Portal Verbindungsanfragen eingestellt ist:

C:\adb>adb shell "settings get global captive_portal_https_url"
https://captiveportal.kuketz.de

Das ist die Sicht von Google. Dass es sich um Verbindugschecks handelt, hatte ich ja selbst vermutet. Die an Sicherheit- und Datenschutz interessierte Community sieht diesen Datenverkehr jedoch überwiegend als Leak, sei es nun ein „DNS-“ oder „VPN-Leak“ (Mullvad, oben zitiertes pcwrt-Team). Siehe hierzu auch die Diskussion von Mike anlässlich seines Test von CalyxOS 2023 (Abschnitt 4.3 Aktivierung Netzwerkschnittstelle):
https://www.kuketz-blog.de/calyxos-de-googled-geht-anders-custom-roms-teil2/

Nun, dann ist das jetzt hier und in der Analyse des pcwrt-Teams nicht nur allgemein festgestellt, sondern im Detail dokumentiert.

Mein Resumée:
Es gibt neben den Captive Portal Verbindungschecks unter Android eine zweite Klasse von regelmäßigen Verbindungen zu Google-Servern, vermutlich Verbindungsschecks bzw. „DNS-Connectivity Checks“, die am VPN vorbeigeleitet werden. Diese lassen sich mit den adb-Befehlen für das Captive Portal NICHT beeinflussen (abschalten, alternativer Server).
Mit dem Schalter „Verbindungen ohne VPN sperren“ und „VPN immer eingeschaltet“ können diese Verbindungen bei manchen Androidgeräten, darunter auch meinem Tablet blockiert werden. Das zitierte pcwrt-Team berichtet jedoch auch von Geräten, bei denen die Verbindungen selbst mit diesen Einstellungen noch am VPN vorbeigehen. Custom-ROMs, wohl außer GOS könnten auch betroffen sein.
Wer diese Verbindungen zu www.google.com also nicht haben will, sollte sich den Datenverkehr seines Androiden genauer anschauen. Der muss dazu jenseits des Geräts, am Router, Pihole, bei einem DNS-Service aufgezeichnet werden.

3 „Gefällt mir“
6

Als Gegenbeispiel, mein GrapheneOS hing direkt nach der Installation in meinem völlig abgeschirmten Netzwerk ohne Freigaben, alle sechs Stunden hat es mal piep gemacht und wollte entweder Uhrzeit abgleichen oder connectivity testen, ohne VPN ohne weitere Apps installiert.
Heute sieht das etwas anders aus, aber mein Router gibt nur bestimmte Ports für das Gerät nach draußen frei, so kann ich Verbindungen die am RethinkDNS + VPN vorbei wollen, an der Firewall blocken, aber nichts. Das nenne ich Kontrolle über die aufgebauten Verbindungen.

7

Lies dir doch zunächst mal https://grapheneos.org/faq#default-connections durch, bevor irgendwelche Behauptungen aufgestellt werden. Da sind die Verbindungschecks unter AOSP dokumentiert und wie man sehen kann gehört www.google.com auch dazu.

2 „Gefällt mir“
8

Es sind vier aufgezählt, einmal die Systemzeit, einmal die Zeitabfrage der CPU SoC, die Verbindungstest laufen bei AOSP default auch zu google, nur GrapheneOS bietet Alternativen und DNS-over-TLS wird als letztes genannt. Teilweise aber nicht am VPN vorbei.

9

Ich habe nirgends bestritten, dass www.google.com einer der Default URL für AOSP Verbindungschecks ist, noch kritisiert, dass dies so ist. Hier ist daher noch eine vergleichbare Doku von Samsung, die hier relevanter ist, da u.a. Samsunggeräte getestet wurden:
https://docs.samsungknox.com/admin/fundamentals/kbas/kba-1202-how-to-disable-the-internet-connectivity-check/

In diesen Dokumentationen und weiteren zum Thema steht dass:

  • Verbindungsanfragen per adb abschaltbar sind.
  • Per adb eine andere URL, eine anderer Server als Google hinterlegt werden kann.

Der Punkt dieses Beitrages ist, dass dies für die beobachtete Verbindung zu www.google.com NICHT möglich ist.

Es gibt also zwei Klassen von Verbindungschecks, die zwar unter AOSP dieselben URLs als Voreinstellung benutzen, sich aber trotzdem unterschiedlich verhalten.

Ein weiterer Punkt ist, dass diese Verbindugschecks am VPN vorbeigehen. Das war lange Zeit undokumentiert, wurde vor ein paar Jahren für die Captive Portal Verbindungsschecks von Mullvad dokumentiert und ist hier nun auch für die bisher wenig dokumentierte 2. Klasse von Verbindungschecks nachgewiesen.

10

Das ist doch ein alter Hut und Standardverhalten von Android. Für die allermeisten Nutzer ist das sinnvoll.

Nur weil etwas auf deinem Gerät mit der Umstellung per ADB nicht funktioniert muss es nicht allgemein unter Android eine 2. Klasse von Verbindungsschecks geben.

11

Danke für deinen detaillierten Artikel. Kurze Frage: Lässt sich das Problem mit GrapheneOS auf einem Google Pixel beheben, tritt es dort gar nicht auf? Ich nutze GrapheneOS seit vier Jahren.

12

Das kann ich Dir nicht sagen, da ich aktuell kein Pixel mit Graphene zur Hand habe. Ich vermute aber, dass Graphene das Verhalten nicht zeigt. Laut der oben verlinkten Übersicht von Eylenburg ist Graphene das einzige Android, das ALLE dort gelisteten Connectivity Checks konsequent auf nicht-Googleserver umgestellt hat, in dem Fall auf einen eigenen, voreingestellten Grapheneserver. Googleserver werden als Alternative angeboten, für Nutzer, die im großen „Strom schwimmen“ wollen.
Interessierten (es sind nicht alle hier auf dem Forum) würde ich aber empfehlen, das selbst zu überprüfen. Den Setup hatte ich ja beschrieben.

1 „Gefällt mir“
13

https://grapheneos.org/faq#default-connections

1 „Gefällt mir“
14

Die Frage habe ich mir auch schon länger gestellt (im Zusammenhang mit diesem Thema: Mobile Telefonie vs WiFi Calling)

Somewhat unexpected but apparently by design, Wi-Fi Calling is always outside the VPN tunnel. Once WiFi Calling is turned on, there’s a persistent IPsec connection to the carrier, in parallel to the VPN connection.

Bin gerade noch nicht sicher, ob ich das gut oder schlecht finde…

Ist halt die Frage, welche Informationen der Provider per WiFi-Calling erhält… es kann vielleicht auch von Vorteil sein, wenn er durch das „Leak“ eine andere IP sieht als die, mit der man im Netz ist :thinking: