Klartext in Android-Apps blockieren, ohne sich auf ein VPN zu verlassen

Zwei sehr verschiedene Dinge werden als Blockieren von Klartext unter Android bezeichnet. Das eine ist eine Richtlinie innerhalb einer App, die ihren eigenen Netzwerk-Stack anweist, einfaches HTTP abzulehnen. Das andere ist eine Regelung auf Geräteebene, die alles auf dem Telefon auf einmal schützen will, meist indem sie den Verkehr durch ein VPN leitet. Sie lösen unterschiedliche Probleme, und das zweite kann das erste nicht reparieren: Ein Tunnel schützt die Strecke zwischen Telefon und Ausgang, während eine App, die HTTP spricht, weiterhin HTTP mit allem spricht, was hinter diesem Ausgang liegt.

Zwei Probleme unter einem Namen

Das erste Problem ist die Nutzlast: Die App schreibt Anmeldedaten oder Token in eine Anfrage, die nicht durchgehend verschlüsselt ist, sodass jeder Hop, der sie sehen kann, sie lesen kann. Das zweite ist der Pfad: Die App kann völlig korrekt sein, und Sie möchten trotzdem, dass der lokale WLAN-Betreiber nichts darüber erfährt, wohin sie sich verbindet. Ein VPN adressiert das zweite und nur das zweite.

Diese Unterscheidung entscheidet, wer die Behebung besitzt. Die Nutzlast gehört dem, der die App ausliefert, denn nur dieser Code entscheidet, welche URL aufgerufen wird und ob ein Zertifikat geprüft wird. Der Pfad gehört dem Gerät oder dem Netzwerk, denn es geht darum, wohin Pakete reisen, nicht was sie enthalten.

Pfad eins: die App, die Sie kontrollieren

Wenn Sie die App ausliefern, ist die Behebung eine Transportentscheidung plus eine Richtlinie, die sie durchsetzt. Richten Sie jeden Endpunkt auf HTTPS, lassen Sie die Prüfung von Hostname und Zertifikat eingeschaltet und löschen Sie den Rückfall auf einfaches HTTP, statt ihn ein Konfigurationsflag entfernt liegen zu lassen. Eine Weiterleitung hilft hier nicht: Eine HTTP-Anfrage, die eine 301 erhält, hat ihre Header und ihren Rumpf bereits im Klartext gesendet, also dürfen Anmeldedaten niemals in der Annahme reisen, die Weiterleitung schütze sie.

Ab Android 7.0 drückt Network Security Configuration die Richtlinie aus. Die folgende Datei ist die kleinste sinnvolle Version: Sie lehnt Klartext überall ab, sofern keine domänenspezifische Ausnahme etwas anderes sagt.

<network-security-config>
    <base-config cleartextTrafficPermitted="false" />
</network-security-config>

Verweisen Sie aus dem Manifest auf diese Ressource und lesen Sie dann die bereits vorhandenen Ausnahmen, bevor Sie ausliefern. Eine alte Debug-Domain oder ein SDK-Eintrag eines Zahlungsanbieters kann Klartext für den Host, den Sie schützen wollten, stillschweigend wieder erlauben.

Zwei Versionsdetails sind wissenswert. Apps, die auf API 28 oder höher abzielen, lehnen Klartext bereits standardmäßig ab, eine App, die noch einfaches HTTP spricht, zielt also entweder auf eine ältere API-Ebene oder hat irgendwo eine Ausnahme. Und wenn eine Netzwerksicherheitskonfiguration vorhanden ist, entscheidet das ältere Manifest-Attribut android:usesCleartextTraffic die Frage nicht mehr, weshalb das Ändern dieses Flags manchmal nichts zu bewirken scheint.

Pfad zwei: die App, die Sie nicht kontrollieren

Bei einer installierten App eines Drittanbieters können Sie deren Sicherheitskonfiguration nicht über eine Nutzereinstellung umschreiben. Realistische Optionen sind die eigenen Steuerungen des Produkts für sichere Verbindungen, eine gepflegte Alternative, die bereits TLS nutzt, oder eine Richtlinie für verwaltete Geräte, die begrenzt, was das Gerät ausführen darf. Das sind unterschiedliche Zusagen, und nur die dritte skaliert auf einen Gerätepark.

Netzwerkregeln sind schwächere Ersatzlösungen, als sie scheinen. Nur Port 443 zuzulassen erzwingt kein authentifiziertes TLS, da sich viele Klartextprotokolle auf diesen Port verlegen lassen, und das Blockieren von Port 80 deckt keinen Klartext auf anderen Ports ab. Der Nur-HTTPS-Modus eines Browsers ist zudem auf diesen Browser beschränkt, nicht auf eine separate Mail- oder Chat-App auf demselben Telefon.

Ein Abfangzertifikat zu installieren, damit Verkehr verschlüsselt aussieht, ist eine Vertrauensänderung, keine Behebung. Es ersetzt die Serverauthentifizierung der App durch Ihre, und eine App, die Zertifikate von vornherein nicht prüfte, wird dadurch nicht repariert; Sie haben nur verschoben, wer den Datenstrom lesen kann.

Wo ein VPN hilft und wo nicht

Ein Tunnel ist das richtige Werkzeug, wenn die Anforderung ist, dass das lokale Netz nichts über die Verbindung erfährt, oder dass die App einen privaten Dienst erreicht, den sie sonst nicht erreichen kann. Er ist das falsche Werkzeug, um einen HTTP-Client HTTPS sprechen zu lassen, weil die Anfrage den Tunnel genau so verlässt, wie sie ihn betreten hat.

Android fügt eine praktische Einschränkung hinzu: die Plattform betreibt immer nur einen VPN-Dienst. Eine lokale Filter-App, die diesen Platz belegt, konkurriert mit dem entfernten Tunnel, den Sie tatsächlich brauchen, und zwischen beiden zu wechseln ist ein Vorgang auf Geräteebene, nicht auf App-Ebene. Dieser eine Platz ist ein guter Grund, die Nutzlast-Richtlinie in die App zu legen und den Tunnel für den Pfad zu behalten.

Der einzige Fall, in dem sich beides überschneidet, ist ein privater Server, den Sie selbst betreiben. Dort kann ein Tunnel den Pfad privat machen, obwohl das Protokoll noch Klartext ist, was die Exposition verringert, aber nicht ändert, was die Nutzlast ist. Behandeln Sie das als Risikominderung, nicht als Verschlüsselung der Daten.

Was zu testen ist, bevor Sie es als blockiert bezeichnen

Beginnen Sie mit der Voreinstellung, die Leute überrascht: Eine App, die auf API 28 oder höher abzielt, sollte Klartext bereits ablehnen, prüfen Sie also die Zielebene, bevor Sie eine Konfiguration hinzufügen, die eine Voreinstellung dupliziert. Testen Sie dann den Fehlerfall bewusst: Eine Anfrage an einen einfachen HTTP-Host muss fehlschlagen und nicht still über einen Rückfall gelingen.

adb shell dumpsys package com.example.app | grep -E 'targetSdk|versionName'
adb logcat | grep -i cleartext

Bestätigen Sie für den Erfolgsfall, dass der HTTPS-Aufruf eine echte Zertifikatskette prüft und dass ein Proxy mit nicht vertrauenswürdigem Zertifikat abgelehnt statt geduldet wird. Ein Handshake, der gegen jedes Zertifikat gelingt, hat nichts über Transportsicherheit bewiesen.

Notieren Sie für eine Drittanbieter-App die Grenze, die Sie tatsächlich durchsetzen können, sei es eine Richtlinie für verwaltete Geräte, eine Netzwerkregel oder nichts, und sagen Sie es in den Abnahmekriterien. Die Android-Anleitung zur Sicherheitskonfiguration listet die Plattformvorgaben und welche Komponenten die Richtlinie beachten, und das ist der Teil, der entscheidet, ob Ihre Konfiguration überhaupt etwas bewirkt.