Bloki klarTekston en Android-aplikoj sen dependi de VPN

Du tute malsamaj aferoj nomiĝas blokado de klarTeksto en Android. Unu estas politiko ene de aplikaĵo, kiu ordonas al ĝia propra reta stako rifuzi ordinaran HTTP. La alia estas aranĝo je aparata nivelo, kiu provas protekti ĉion en la telefono samtempe, kutime per direktado de trafiko tra VPN. Ili solvas malsamajn problemojn, kaj la dua ne povas ripari la unuan: tunelo protektas la segmenton inter la telefono kaj la eliro, dum aplikaĵo, kiu parolas HTTP, plu parolas HTTP kun ĉio, kio troviĝas preter tiu eliro.

Du problemoj sub unu nomo

La unua problemo estas la ŝarĝo: la aplikaĵo skribas akreditaĵojn aŭ ĵetonojn en peton, kiu ne estas ĉifrita de unu fino ĝis la alia, do ĉiu salto, kiu povas ĝin vidi, povas ĝin legi. La dua estas la vojo: la aplikaĵo povas esti tute bonorda, kaj vi tamen volas, ke la loka Wi-Fi-operatoro lernu nenion pri tio, kien ĝi konektiĝas. VPN traktas la duan kaj nur la duan.

Tiu distingo decidas, al kiu apartenas la riparo. La ŝarĝo apartenas al tiu, kiu liveras la aplikaĵon, ĉar nur tiu kodo decidas, kiun URL-on ĝi vokas kaj ĉu ĝi validigas atestilon. La vojo apartenas al la aparato aŭ la reto, ĉar temas pri tio, kien pakaĵoj vojaĝas, ne pri tio, kion ili enhavas.

Vojo unu: la aplikaĵo, kiun vi kontrolas

Se vi liveras la aplikaĵon, la riparo estas transporta decido plus politiko, kiu devigas ĝin. Direktu ĉiun finpunkton al HTTPS, tenu validigadon de gastigantnomo kaj atestilo ŝaltita, kaj forigu la rezervan vojon per ordinara HTTP anstataŭ lasi ĝin unu agordan flagon for. Alidirektado ne helpas ĉi tie: HTTP-peto, kiu ricevas 301, jam sendis siajn kapliniojn kaj korpon malkaŝe, do akreditaĵoj neniam rajtas vojaĝi kun la supozo, ke la alidirektado protektos ilin.

En Android 7.0 kaj poste, Network Security Configuration esprimas la politikon. La dosiero sube estas la plej malgranda utila versio: ĝi rifuzas klarTekston ĉie, krom se domajna escepto diras alie.

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

Referencu tiun rimedon el la manifestaĵo, poste legu la esceptojn, kiuj jam ekzistas, antaŭ ol liveri. Malnova sencimiga domajno aŭ SDK-enskribo de paga provizanto povas silente re-permesi klarTekston por la gastiganto, kiun vi provis protekti.

Du versiaj detaloj indas scii. Aplikaĵoj celantaj API 28 aŭ pli novan jam defaŭlte rifuzas klarTekston, do aplikaĵo, kiu ankoraŭ parolas ordinaran HTTP, aŭ celas pli malnovan API-nivelon aŭ havas escepton ie. Kaj kiam reta sekureca agordo ĉeestas, la pli malnova manifesta atributo android:usesCleartextTraffic ne plu decidas la demandon, kaj tial ŝanĝi tiun flagon foje ŝajnas fari nenion.

Vojo du: la aplikaĵo, kiun vi ne kontrolas

Por instalita triaparta aplikaĵo, vi ne povas reverki ĝian sekurecan agordon per uzanta agordo. La realismaj ebloj estas la propraj regiloj de la produkto por sekura konekto, prizorgata alternativo, kiu jam uzas TLS, aŭ politiko por administrata aparato, kiu limigas, kion la aparato rajtas ruli. Tiuj estas malsamaj devontigoj, kaj nur la tria skaliĝas al aparataro.

Retaj reguloj estas pli malfortaj anstataŭaĵoj ol ili ŝajnas. Permesi nur pordon 443 ne devigas aŭtentikigitan TLS, ĉar multaj klarTekstaj protokoloj povas esti movitaj al tiu pordo, kaj bloki pordon 80 ne kovras klarTekston sur aliaj pordoj. La reĝimo nur-HTTPS de retumilo ankaŭ limiĝas al tiu retumilo, ne al aparta poŝta aŭ babila aplikaĵo en la sama telefono.

Instali interceptan atestilon por igi trafikon aspekti ĉifrita estas ŝanĝo de fido, ne riparo. Ĝi anstataŭas la servilan aŭtentikigon de la aplikaĵo per la via, kaj aplikaĵo, kiu dekomence ne validigis atestilojn, ne ripariĝas per tio; vi nur movis, kiu povas legi la fluon.

Kie VPN helpas kaj kie ĝi ne helpas

Tunelo estas la ĝusta ilo, kiam la postulo estas, ke la loka reto lernu nenion pri la konekto, aŭ ke la aplikaĵo atingu privatan servon, kiun ĝi alie ne povas atingi. Ĝi estas la malĝusta ilo por igi HTTP-klienton paroli HTTPS, ĉar la peto forlasas la tunelon ĝuste tia, kia ĝi eniris.

Android aldonas praktikan limigon: la platformo funkciigas unu VPN-servon samtempe. Loka filtra aplikaĵo, kiu okupas tiun lokon, konkurencas kun la fora tunelo, kiun vi vere bezonas, kaj ŝalti inter ili estas operacio je aparata nivelo, ne je aplikaĵa. Tiu unu loko estas bona kialo meti la ŝarĝan politikon en la aplikaĵon kaj konservi la tunelon por la vojo.

La sola kazo, kie la du interkovriĝas, estas privata servilo, kiun vi ankaŭ administras. Tie tunelo povas igi la vojon privata, kvankam la protokolo ankoraŭ estas klarTeksto, kio malpligrandigas elmetiĝon sed ne ŝanĝas, kio estas la ŝarĝo. Traktu tion kiel malpligrandigon de risko, ne kiel ĉifradon de la datumoj.

Kion testi antaŭ ol nomi ĝin blokita

Komencu per la defaŭlto, kiu surprizas homojn: aplikaĵo celanta API 28 aŭ pli novan jam devus rifuzi klarTekston, do kontrolu la celan nivelon antaŭ ol aldoni agordon, kiu duobligas defaŭlton. Poste testu la malsukcesan kazon intence: peto al ordinara HTTP-gastiganto devas malsukcesi, ne silente sukcesi per rezerva vojo.

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

Por la sukcesa kazo, konfirmu, ke la HTTPS-voko validigas realan atestilan ĉenon kaj ke prokurilo kun nefidinda atestilo estas rifuzata, ne tolerata. Manpremo, kiu sukcesas kontraŭ ajna atestilo, pruvis nenion pri transporta sekureco.

Por triaparta aplikaĵo, skribu la limon, kiun vi vere povas devigi, ĉu ĝi estas politiko por administrata aparato, reta regulo aŭ nenio, kaj diru tion en la akceptaj kriterioj. La gvidilo pri sekureca agordo de Android listigas la platformajn defaŭltojn kaj kiuj komponantoj respektas la politikon, kaj tio estas la parto, kiu decidas, ĉu via agordo entute faras ion.