Blokujte čistý text v aplikacích pro Android bez spoléhání na VPN

Dvě velmi odlišné věci se nazývají blokováním čistého textu v Androidu. Jednou je zásada uvnitř aplikace, která nařizuje jejímu vlastnímu síťovému zásobníku odmítat obyčejné HTTP. Druhou je uspořádání na úrovni zařízení, které se snaží ochránit všechno v telefonu najednou, obvykle směrováním provozu přes VPN. Řeší různé problémy a druhá nemůže opravit první: tunel chrání úsek mezi telefonem a výstupem, zatímco aplikace, která mluví HTTP, mluví HTTP i s tím, co je za tímto výstupem.

Dva problémy pod jedním jménem

První problém je obsah: aplikace zapisuje přihlašovací údaje nebo tokeny do požadavku, který není šifrovaný od konce ke konci, takže každý skok, který ho vidí, ho může přečíst. Druhý je cesta: aplikace může být naprosto bezchybná a vy přesto chcete, aby se místní operátor Wi-Fi nedozvěděl nic o tom, kam se připojuje. VPN řeší druhý a jen druhý.

Toto rozlišení určuje vlastníka opravy. Obsah patří tomu, kdo aplikaci dodává, protože jen ten kód rozhoduje, které URL se volá a zda se ověřuje certifikát. Cesta patří zařízení nebo síti, protože jde o to, kam pakety putují, ne co obsahují.

Cesta první: aplikace, kterou ovládáte

Pokud aplikaci dodáváte, je opravou rozhodnutí o přenosu plus zásada, která ho prosadí. Nasměrujte každý koncový bod na HTTPS, ponechte ověřování názvu hostitele a certifikátu zapnuté a odstraňte záložní variantu s obyčejným HTTP, místo abyste ji nechali na dosah jednoho konfiguračního přepínače. Přesměrování zde nepomůže: požadavek HTTP, který dostane 301, už odeslal hlavičky i tělo otevřeně, takže přihlašovací údaje nikdy nesmějí cestovat s předpokladem, že je přesměrování ochrání.

V Androidu 7.0 a novějším vyjadřuje zásadu Network Security Configuration. Soubor níže je nejmenší užitečná verze: odmítá čistý text všude, pokud výjimka pro konkrétní doménu neříká jinak.

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

Odkazujte na tento prostředek z manifestu a poté si před dodáním přečtěte výjimky, které už existují. Stará ladicí doména nebo záznam SDK poskytovatele plateb může tiše znovu povolit čistý text pro hostitele, kterého jste se snažili ochránit.

Dva detaily k verzi stojí za to znát. Aplikace cílené na API 28 nebo novější už standardně odmítají čistý text, takže aplikace, která stále mluví obyčejným HTTP, buď cílí na starší úroveň API, nebo má někde výjimku. A když je přítomna konfigurace zabezpečení sítě, starší atribut manifestu android:usesCleartextTraffic už otázku nerozhoduje, a proto se někdy zdá, že změna tohoto přepínače nic nedělá.

Cesta druhá: aplikace, kterou neovládáte

U nainstalované aplikace třetí strany nemůžete přepsat její konfiguraci zabezpečení pomocí uživatelského nastavení. Reálné možnosti jsou vlastní ovládací prvky zabezpečeného připojení daného produktu, udržovaná alternativa, která už používá TLS, nebo zásada spravovaného zařízení, která omezuje, co zařízení smí spouštět. To jsou různé závazky a jen třetí se škáluje na celou flotilu.

Síťová pravidla jsou slabší náhradou, než se zdá. Povolení jen portu 443 nevynucuje ověřený TLS, protože na tento port lze přesunout mnoho protokolů s čistým textem, a blokování portu 80 nepokrývá čistý text na jiných portech. Režim pouze HTTPS v prohlížeči je také omezen na ten prohlížeč, ne na samostatnou aplikaci pro poštu nebo chat ve stejném telefonu.

Instalace zachytávacího certifikátu, aby provoz vypadal šifrovaně, je změna důvěry, ne oprava. Nahrazuje ověřování serveru aplikace vaším a aplikaci, která certifikáty od začátku neověřovala, to neopraví; jen jste přesunuli, kdo může číst tok.

Kde VPN pomáhá a kde ne

Tunel je správný nástroj, když je požadavkem, aby se místní síť nedozvěděla nic o spojení, nebo aby aplikace dosáhla na soukromou službu, na kterou se jinak nedostane. Je to špatný nástroj pro to, aby HTTP klient mluvil HTTPS, protože požadavek opouští tunel přesně takový, jaký do něj vstoupil.

Android přidává praktické omezení: platforma spouští vždy jen jednu službu VPN. Místní filtrační aplikace, která toto místo zabere, soutěží se vzdáleným tunelem, který skutečně potřebujete, a přepínání mezi nimi je operace na úrovni zařízení, ne aplikace. To jediné místo je dobrý důvod mít zásadu obsahu v aplikaci a tunel si nechat pro cestu.

Jediný případ, kdy se obojí překrývá, je soukromý server, který také provozujete. Tam může tunel zprivatizovat cestu, i když protokol je stále čistý text, což snižuje expozici, ale nemění to, čím obsah je. Berte to jako snížení rizika, ne jako šifrování dat.

Co otestovat, než to nazvete zablokovaným

Začněte s výchozím stavem, který lidi překvapí: aplikace cílená na API 28 nebo novější by už měla odmítat čistý text, takže zkontrolujte cílovou úroveň, než přidáte konfiguraci, která výchozí stav duplikuje. Pak úmyslně otestujte případ selhání: požadavek na obyčejný HTTP hostitel musí selhat, ne tiše uspět přes záložní variantu.

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

U případu úspěchu ověřte, že volání HTTPS ověřuje skutečný řetězec certifikátů a že proxy s nedůvěryhodným certifikátem je odmítnuta, ne tolerována. Spojení, které uspěje s jakýmkoli certifikátem, o bezpečnosti přenosu nic nedokázalo.

U aplikace třetí strany zapište hranici, kterou skutečně můžete prosadit, ať je to zásada spravovaného zařízení, síťové pravidlo nebo nic, a uveďte to v kritériích přijetí. Průvodce konfigurací zabezpečení v Androidu uvádí výchozí hodnoty platformy a které komponenty zásadu respektují, což je část, která rozhoduje o tom, zda vaše konfigurace vůbec něco dělá.