Blokeeri Androidi rakendustes avatekst ilma VPN-ile lootmata

Androidis nimetatakse avateksti blokeerimiseks kaht täiesti erinevat asja. Üks on rakendusesisene poliitika, mis käsib rakenduse enda võrgupinul keelduda tavalisest HTTP-st. Teine on seadme tasandi korraldus, mis püüab kaitsta kõike telefonis korraga, tavaliselt suunates liikluse VPN-i kaudu. Need lahendavad eri probleeme ja teine ei saa esimest parandada: tunnel kaitseb lõiku telefoni ja väljundi vahel, samas kui HTTP-d rääkiv rakendus räägib endiselt HTTP-d kõigega, mis asub sellest väljundist kaugemal.

Kaks probleemi ühe nime all

Esimene probleem on kandevõime: rakendus kirjutab volitused või märgid päringusse, mis ei ole otsast lõpuni krüpteeritud, nii et iga hüpe, mis seda näeb, saab seda lugeda. Teine on tee: rakendus võib olla täiesti korras ja sa ikka tahad, et kohalik Wi-Fi operaator ei teaks midagi sellest, kuhu see ühendub. VPN tegeleb teisega ja ainult teisega.

See erinevus määrab paranduse omaniku. Kandevõime kuulub sellele, kes rakenduse tarnib, sest ainult see kood otsustab, millist URL-i kutsutakse ja kas sertifikaati valideeritakse. Tee kuulub seadmele või võrgule, sest jutt on sellest, kuhu paketid liiguvad, mitte sellest, mida need sisaldavad.

Tee üks: rakendus, mida sina kontrollid

Kui tarnid rakendust, on parandus transpordiotsus pluss poliitika, mis seda jõustab. Suuna iga lõpp-punkt HTTPS-ile, hoia hostinime ja sertifikaadi valideerimine sees ning kustuta tavaline HTTP varuvariant, selle asemel et jätta see ühe konfiguratsioonilipu kaugusele. Ümbersuunamine siin ei aita: HTTP-päring, mis saab 301, on oma päised ja keha juba avatult saatnud, seega ei tohi volitused kunagi liikuda eeldusel, et ümbersuunamine neid kaitseb.

Androidis 7.0 ja uuemates väljendab poliitikat Network Security Configuration. Allolev fail on väikseim kasulik versioon: see keeldub avatekstist kõikjal, kui domeenipõhine erand ei ütle teisiti.

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

Viita sellele ressursile manifestist ja loe siis enne tarnimist läbi erandid, mis juba olemas on. Vana silumisdomeen või makseteenuse pakkuja SDK kirje võib hosti jaoks, mida sa püüdsid kaitsta, avateksti vaikselt uuesti lubada.

Kaks versiooniüksikasja tasub teada. API 28 või uuemale suunatud rakendused keelduvad avatekstist juba vaikimisi, seega rakendus, mis räägib endiselt tavalist HTTP-d, kas sihib vanemat API taset või on kuskil erand. Ja kui võrgu turvakonfiguratsioon on olemas, ei otsusta vanem manifesti atribuut android:usesCleartextTraffic enam seda küsimust, mistõttu tundub mõnikord, et selle lipu muutmine ei tee midagi.

Tee kaks: rakendus, mida sa ei kontrolli

Paigaldatud kolmanda osapoole rakenduse puhul ei saa sa selle turvakonfiguratsiooni kasutajaseadega ümber kirjutada. Realistlikud valikud on toote enda turvalise ühenduse juhtimine, hooldatud alternatiiv, mis kasutab juba TLS-i, või hallatava seadme poliitika, mis piirab, mida seade tohib käivitada. Need on erinevad kohustused ja ainult kolmas skaleerub seadmepargi peale.

Võrgureeglid on nõrgemad asendajad, kui need paistavad. Ainult pordi 443 lubamine ei jõusta autenditud TLS-i, sest paljusid avateksti protokolle saab sellele pordile viia, ja pordi 80 blokeerimine ei kata avateksti teistel portidel. Brauseri ainult-HTTPS režiim on samuti piiratud selle brauseriga, mitte samas telefonis oleva eraldi e-posti või vestlusrakendusega.

Omanikuvahetussertifikaadi paigaldamine, et liiklus näeks krüpteeritud, on usalduse muutmine, mitte parandus. See asendab rakenduse serveri autentimise sinu omaga ja rakendust, mis sertifikaate algusest peale ei valideerinud, ei paranda see; sa lihtsalt liigutasid seda, kes saab voogu lugeda.

Kus VPN aitab ja kus mitte

Tunnel on õige tööriist, kui nõue on, et kohalik võrk ei teaks ühendusest midagi, või et rakendus jõuaks privaatteenuseni, kuhu see muidu ei jõua. See on vale tööriist HTTP-kliendi HTTPS-i rääkima panemiseks, sest päring lahkub tunnelist täpselt sellisena, nagu sinna sisenes.

Android lisab praktilise piirangu: platvorm käitab korraga ühte VPN-teenust. Selle koha hõivav kohalik filtreerimisrakendus võistleb kaugtunneliga, mida sa tegelikult vajad, ja nende vahel vahetamine on seadme tasandi, mitte rakenduse tasandi toiming. See üks koht on hea põhjus panna kandevõime poliitika rakendusse ja hoida tunnel tee jaoks.

Ainus juhtum, kus need kaks kattuvad, on privaatserver, mida sa ise ka käitad. Seal saab tunnel tee privaatseks teha ka siis, kui protokoll on endiselt avatekst, mis vähendab kokkupuudet, kuid ei muuda seda, mis kandevõime on. Käsitle seda riski vähendamisena, mitte andmete krüpteerimisena.

Mida testida, enne kui nimetada seda blokeerituks

Alusta vaikeväärtusest, mis inimesi üllatab: API 28 või uuemale suunatud rakendus peaks avatekstist juba keelduma, seega kontrolli sihttaset enne, kui lisad konfiguratsiooni, mis vaikeväärtust dubleerib. Seejärel testi nurjumise juhtumit meelega: päring tavalisele HTTP-hostile peab nurjuma, mitte vaikselt varuvariandiga õnnestuma.

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

Õnnestumise korral kinnita, et HTTPS-kutse valideerib tõelise sertifikaadiahela ja et ebausaldusväärse sertifikaadiga puhverserver lükatakse tagasi, mitte ei taluta. Käepigistus, mis õnnestub mis tahes sertifikaadiga, ei ole tõestanud transportturvalisuse kohta midagi.

Kolmanda osapoole rakenduse puhul pane kirja piir, mida sa tõesti jõustada saad, olgu see hallatava seadme poliitika, võrgureegel või mitte midagi, ja ütle seda vastuvõtukriteeriumides. Androidi turbekonfiguratsiooni juhend loetleb platvormi vaikeväärtused ja millised komponendid poliitikat järgivad, ja just see osa otsustab, kas sinu konfiguratsioon üldse midagi teeb.