Blokirajte čisto besedilo v aplikacijah Android brez zanašanja na VPN
Čisto besedilo v tovoru in čisto besedilo na poti sta dve različni težavi. Prvo odpravite v aplikaciji, drugo s tunelom ali pravilnikom naprave.
Dve povsem različni stvari imenujemo blokiranje čistega besedila v Androidu. Prva je pravilnik znotraj aplikacije, ki njenemu lastnemu omrežnemu skladu ukaže, da zavrača navaden HTTP. Druga je ureditev na ravni naprave, ki skuša zaščititi vse v telefonu hkrati, običajno s speljevanjem prometa skozi VPN. Rešujeta različne težave in druga ne more popraviti prve: tunel ščiti odsek med telefonom in izhodom, medtem ko aplikacija, ki govori HTTP, še naprej govori HTTP z vsem, kar je za tem izhodom.
Dve težavi pod enim imenom
Prva težava je tovor: aplikacija zapiše poverilnice ali žetone v zahtevo, ki ni šifrirana od začetka do konca, zato jo lahko prebere vsak skok, ki jo vidi. Druga je pot: aplikacija je lahko povsem brezhibna, vi pa še vedno želite, da se lokalni operater Wi-Fi ne nauči ničesar o tem, kam se povezuje. VPN naslavlja drugo in samo drugo.
Ta razlika določa, kdo je lastnik popravka. Tovor pripada tistemu, ki aplikacijo dostavlja, ker le ta koda odloča, kateri URL se kliče in ali se potrdilo preverja. Pot pripada napravi ali omrežju, ker gre za to, kam potujejo paketi, ne za to, kaj vsebujejo.
Pot prva: aplikacija, ki jo nadzorujete
Če aplikacijo dostavljate vi, je popravek odločitev o prenosu plus pravilnik, ki jo uveljavlja. Usmerite vsako končno točko na HTTPS, pustite preverjanje imena gostitelja in potrdila vključeno ter izbrišite rezervno pot z navadnim HTTP, namesto da bi jo pustili eno konfiguracijsko zastavico stran. Preusmeritev tukaj ne pomaga: zahteva HTTP, ki prejme 301, je glave in telo že poslala odkrito, zato poverilnice nikoli ne smejo potovati s predpostavko, da jih bo preusmeritev zaščitila.
Od Androida 7.0 pravilnik izraža Network Security Configuration. Datoteka spodaj je najmanjša uporabna različica: zavrača čisto besedilo povsod, razen če izjema za določeno domeno ne pravi drugače.
<network-security-config>
<base-config cleartextTrafficPermitted="false" />
</network-security-config>Sklicevali se na ta vir iz manifesta, nato pa pred dostavo preberite izjeme, ki že obstajajo. Stara domena za razhroščevanje ali vnos SDK ponudnika plačil lahko tiho znova dovoli čisto besedilo za gostitelja, ki ste ga skušali zaščititi.
Dve podrobnosti različice velja vedeti. Aplikacije, usmerjene na API 28 ali novejši, čisto besedilo že privzeto zavračajo, zato aplikacija, ki še vedno govori navaden HTTP, bodisi cilja na starejšo raven API bodisi ima nekje izjemo. In ko je prisotna konfiguracija omrežne varnosti, starejši atribut manifesta android:usesCleartextTraffic o vprašanju ne odloča več, zato se včasih zdi, da spreminjanje te zastavice ne naredi ničesar.
Pot druga: aplikacija, ki je ne nadzorujete
Za nameščeno aplikacijo tretje strani ne morete prepisati njene varnostne konfiguracije z uporabniško nastavitvijo. Realne možnosti so lastni nadzori varne povezave izdelka, vzdrževana alternativa, ki že uporablja TLS, ali pravilnik upravljane naprave, ki omejuje, kaj naprava sme izvajati. To so različne obveznosti in le tretja se razširi na celo floto.
Omrežna pravila so šibkejši nadomestki, kot se zdijo. Dovoljenje samo vrat 443 ne uveljavlja overjenega TLS, ker je mogoče veliko protokolov s čistim besedilom premakniti na ta vrata, blokiranje vrat 80 pa ne pokriva čistega besedila na drugih vratih. Tudi način samo-HTTPS v brskalniku je omejen na ta brskalnik, ne na ločeno aplikacijo za pošto ali klepet v istem telefonu.
Namestitev prestreznega potrdila, da je promet videti šifriran, je sprememba zaupanja, ne popravek. Zamenja preverjanje strežnika aplikacije z vašim in aplikacije, ki potrdil od začetka ni preverjala, s tem ne popravi; le premaknili ste, kdo lahko bere tok.
Kje VPN pomaga in kje ne
Tunel je pravo orodje, ko je zahteva, da se lokalno omrežje ne nauči ničesar o povezavi, ali da aplikacija doseže zasebno storitev, do katere drugače ne pride. Je napačno orodje za to, da bi odjemalec HTTP govoril HTTPS, ker zahteva zapusti tunel natanko taka, kakršna je vanj vstopila.
Android doda praktično omejitev: platforma izvaja samo eno storitev VPN naenkrat. Lokalna aplikacija za filtriranje, ki zavzame to mesto, tekmuje z oddaljenim tunelom, ki ga resnično potrebujete, preklapljanje med njima pa je dejanje na ravni naprave, ne aplikacije. To eno mesto je dober razlog, da pravilnik tovora ostane v aplikaciji, tunel pa si pridržite za pot.
Edini primer, ko se oba prekrivata, je zasebni strežnik, ki ga tudi sami upravljate. Tam lahko tunel naredi pot zasebno, čeprav je protokol še čisto besedilo, kar zmanjša izpostavljenost, ne spremeni pa tega, kaj tovor je. Obravnavajte to kot zmanjšanje tveganja, ne kot šifriranje podatkov.
Kaj preizkusiti, preden to imenujete blokirano
Začnite s privzeto nastavitvijo, ki ljudi preseneti: aplikacija, usmerjena na API 28 ali novejši, bi morala čisto besedilo že zavračati, zato preverite ciljno raven, preden dodate konfiguracijo, ki podvaja privzeto. Nato namerno preizkusite primer neuspeha: zahteva na navadnega gostitelja HTTP mora spodleteti, ne pa tiho uspeti prek rezervne poti.
adb shell dumpsys package com.example.app | grep -E 'targetSdk|versionName'
adb logcat | grep -i cleartextZa primer uspeha potrdite, da klic HTTPS preverja resnično verigo potrdil in da je posrednik z nezaupljivim potrdilom zavrnjen, ne toleriran. Roka, ki uspe s katerim koli potrdilom, ni dokazala ničesar o varnosti prenosa.
Za aplikacijo tretje strani zapišite mejo, ki jo resnično lahko uveljavite, naj bo to pravilnik upravljane naprave, omrežno pravilo ali nič, in to povejte v merilih za sprejem. Vodnik po varnostni konfiguraciji Android navaja privzete vrednosti platforme in katere komponente spoštujejo pravilnik, in prav ta del določa, ali vaša konfiguracija sploh kaj naredi.