Tiltsd le a nyílt szöveget Android-alkalmazásokban VPN nélkül

Két teljesen különböző dolgot neveznek nyílt szöveg blokkolásának Androidon. Az egyik az alkalmazáson belüli szabályzat, amely saját hálózati veremének megtiltja a sima HTTP-t. A másik az eszközszintű elrendezés, amely a telefonon mindent egyszerre próbál védeni, általában VPN-en át vezetve a forgalmat. Különböző problémákat oldanak meg, és a második nem tudja megjavítani az elsőt: az alagút a telefon és a kijárat közötti szakaszt védi, míg a HTTP-t beszélő alkalmazás továbbra is HTTP-t beszél azzal, ami a kijáraton túl van.

Két probléma egy név alatt

Az első probléma a hasznos teher: az alkalmazás hitelesítő adatokat vagy tokeneket ír egy olyan kérésbe, amely nincs végponttól végpontig titkosítva, így minden ugrás, amely látja, olvashatja. A második az útvonal: az alkalmazás lehet teljesen rendben, és te mégis azt akarod, hogy a helyi Wi-Fi-üzemeltető semmit ne tudjon meg arról, hova csatlakozik. A VPN a másodikat kezeli, és csak a másodikat.

Ez a megkülönböztetés dönti el, kié a javítás. A hasznos teher azé, aki szállítja az alkalmazást, mert csak az a kód dönti el, melyik URL-t hívja és ellenőrzi-e a tanúsítványt. Az útvonal az eszközé vagy a hálózaté, mert arról szól, hova utaznak a csomagok, nem arról, mit tartalmaznak.

Első útvonal: az alkalmazás, amelyet te irányítasz

Ha te szállítod az alkalmazást, a javítás egy szállítási döntés és az azt érvényesítő szabályzat. Irányíts minden végpontot HTTPS-re, tartsd bekapcsolva a hosztnév és a tanúsítvány ellenőrzését, és töröld a sima HTTP-s visszaesést ahelyett, hogy egy konfigurációs kapcsoló távolságra hagynád. Az átirányítás itt nem segít: a 301-et kapó HTTP-kérés már nyíltan elküldte a fejléceit és a törzsét, ezért a hitelesítő adatok soha nem utazhatnak abban a feltevésben, hogy az átirányítás megvédi őket.

Android 7.0-tól a Network Security Configuration fejezi ki a szabályzatot. Az alábbi fájl a legkisebb hasznos változat: mindenhol megtagadja a nyílt szöveget, hacsak egy tartomány-specifikus kivétel mást nem mond.

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

Hivatkozz erre az erőforrásra a manifestből, majd olvasd el a már létező kivételeket szállítás előtt. Egy régi hibakeresési tartomány vagy egy fizetési szolgáltató SDK-bejegyzése csendben újra engedélyezheti a nyílt szöveget annak a hosztnak, amelyet védeni próbáltál.

Két verziórészletet érdemes tudni. Az API 28 vagy újabb célzású alkalmazások már alapból megtagadják a nyílt szöveget, tehát egy még mindig sima HTTP-t beszélő alkalmazás vagy régebbi API-szintet céloz, vagy valahol kivétele van. És ha van hálózati biztonsági konfiguráció, a régebbi android:usesCleartextTraffic manifest-attribútum már nem dönti el a kérdést, ezért tűnik úgy néha, hogy a kapcsoló átállítása semmit nem tesz.

Második útvonal: az alkalmazás, amelyet nem irányítasz

Egy telepített harmadik féltől származó alkalmazás biztonsági konfigurációját nem írhatod át felhasználói beállítással. A reális lehetőségek a termék saját biztonságos kapcsolat vezérlői, egy már TLS-t használó karbantartott alternatíva, vagy egy felügyelt eszköz szabályzata, amely korlátozza, mit futtathat az eszköz. Ezek különböző kötelezettségvállalások, és csak a harmadik skálázódik eszközparkra.

A hálózati szabályok gyengébb helyettesítők, mint amilyennek látszanak. A csak 443-as port engedélyezése nem kényszerít ki hitelesített TLS-t, mert sok nyílt szövegű protokoll áttehető arra a portra, a 80-as port blokkolása pedig nem fedi le a nyílt szöveget más portokon. A böngésző csak-HTTPS módja is arra a böngészőre korlátozódik, nem egy külön levél- vagy csevegőalkalmazásra ugyanazon a telefonon.

Egy elfogó tanúsítvány telepítése, hogy a forgalom titkosítottnak tűnjön, bizalmi változás, nem javítás. Lecseréli az alkalmazás kiszolgáló-hitelesítését a tiédre, és egy eleve tanúsítványokat nem ellenőrző alkalmazást ez nem javít meg; csak áthelyezted, ki olvashatja a folyamot.

Hol segít a VPN és hol nem

Az alagút a megfelelő eszköz, ha a követelmény az, hogy a helyi hálózat semmit ne tudjon meg a kapcsolatról, vagy hogy az alkalmazás elérjen egy magánszolgáltatást, amelyet másképp nem ér el. A rossz eszköz ahhoz, hogy egy HTTP-kliens HTTPS-t beszéljen, mert a kérés pontosan úgy hagyja el az alagutat, ahogy belépett.

Az Android egy gyakorlati korlátot ad hozzá: a platform egyszerre csak egy VPN-szolgáltatást futtat. Egy helyi szűrőalkalmazás, amely ezt a helyet elfoglalja, verseng a valóban szükséges távoli alagúttal, és a kettő közötti váltás eszközszintű művelet, nem alkalmazásszintű. Ez az egyetlen hely jó ok arra, hogy a hasznos teher szabályzatát az alkalmazásba tedd, az alagutat pedig az útvonalra tartsd.

Az egyetlen eset, ahol a kettő átfed, egy magánkiszolgáló, amelyet te is üzemeltetsz. Ott az alagút magánná teheti az útvonalat, bár a protokoll még nyílt szöveg, ami csökkenti a kitettséget, de nem változtatja meg, mi a hasznos teher. Kezeld ezt kockázatcsökkentésként, nem az adatok titkosításaként.

Mit tesztelj, mielőtt blokkolt-nak neveznéd

Kezdd azzal az alapértelmezéssel, amely meglepi az embereket: az API 28 vagy újabb célzású alkalmazásnak már meg kellene tagadnia a nyílt szöveget, ezért ellenőrizd a célszintet, mielőtt olyan konfigurációt adsz hozzá, amely megkettőz egy alapértelmezést. Aztán szándékosan teszteld a hibaesetet: egy sima HTTP-hosztra küldött kérésnek meg kell hiúsulnia, nem szabad csendben sikerülnie egy visszaesésen át.

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

A siker esetében erősítsd meg, hogy a HTTPS-hívás valódi tanúsítványláncot ellenőriz, és hogy a nem megbízható tanúsítványú proxy elutasításra kerül, nem eltűrésre. Egy kézfogás, amely bármely tanúsítvánnyal sikerül, semmit nem bizonyított a szállítási biztonságról.

Harmadik féltől származó alkalmazás esetén írd le a határt, amelyet valóban érvényesíteni tudsz, legyen az felügyelt eszköz szabályzata, hálózati szabály vagy semmi, és mondd ki az elfogadási kritériumokban. A Android biztonsági konfigurációs útmutatója felsorolja a platform alapértelmezéseit és azt, mely összetevők tartják be a szabályzatot, és ez az a rész, amely eldönti, hogy a konfiguráció egyáltalán tesz-e valamit.