Bloķējiet atklātu tekstu Android lietotnēs, nepaļaujoties uz VPN

Divi pilnīgi atšķirīgi jēdzieni tiek saukti par atklāta teksta bloķēšanu Android. Viens ir politika lietotnes iekšienē, kas liek tās pašas tīkla stekam atteikties no vienkārša HTTP. Otrs ir ierīces līmeņa kārtojums, kas cenšas pasargāt visu telefonā uzreiz, parasti novadot datu plūsmu caur VPN. Tie risina dažādas problēmas, un otrais nevar izlabot pirmo: tunelis aizsargā posmu starp telefonu un izeju, bet lietotne, kas runā HTTP, joprojām runā HTTP ar visu, kas atrodas aiz šīs izejas.

Divas problēmas vienā nosaukumā

Pirmā problēma ir lietderīgā slodze: lietotne ieraksta akreditācijas datus vai marķierus pieprasījumā, kas nav šifrēts no gala līdz galam, tāpēc ikviens lēciens, kas to redz, var to izlasīt. Otrā ir ceļš: lietotne var būt pilnīgi korekta, un jūs joprojām vēlaties, lai vietējais Wi-Fi operators neuzzinātu neko par to, kur tā pieslēdzas. VPN risina otro un tikai otro.

Šī atšķirība nosaka, kam pieder labojums. Lietderīgā slodze pieder tam, kas piegādā lietotni, jo tikai šis kods izlemj, kurš URL tiek izsaukts un vai sertifikāts tiek validēts. Ceļš pieder ierīcei vai tīklam, jo runa ir par to, kur pārvietojas paketes, nevis ko tās satur.

Pirmais ceļš: lietotne, kuru kontrolējat

Ja piegādājat lietotni, labojums ir transporta lēmums un politika, kas to īsteno. Novirziet katru galapunktu uz HTTPS, atstājiet ieslēgtu resursdatora nosaukuma un sertifikāta validāciju un izdzēsiet atkāpšanos uz vienkāršu HTTP, nevis atstājiet to vienas konfigurācijas karodziņas attālumā. Pāradresācija šeit nepalīdz: HTTP pieprasījums, kas saņem 301, jau ir nosūtījis galvenes un pamattekstu atklātā veidā, tāpēc akreditācijas datiem nekad nevajadzētu ceļot ar pieņēmumu, ka pāradresācija tos aizsargās.

No Android 7.0 politiku izsaka Network Security Configuration. Tālāk esošā datne ir mazākā lietderīgā versija: tā atsakās no atklāta teksta visur, ja vien domēnam raksturīgs izņēmums nav teicis citādi.

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

Atsaucieties uz šo resursu manifestā, pēc tam pirms piegādes izlasiet jau esošos izņēmumus. Vecs atkļūdošanas domēns vai maksājumu sniedzēja SDK ieraksts var klusi atkal atļaut atklātu tekstu resursdatoram, kuru mēģinājāt aizsargāt.

Ir vērts zināt divas versijas detaļas. Lietotnes, kas mērķē uz API 28 vai jaunāku, jau pēc noklusējuma atsakās no atklāta teksta, tāpēc lietotne, kas joprojām runā vienkāršu HTTP, vai nu mērķē uz vecāku API līmeni, vai kaut kur ir izņēmums. Un, ja ir tīkla drošības konfigurācija, vecākais android:usesCleartextTraffic manifesta atribūts vairs šo jautājumu neizlemj, tāpēc dažkārt šķiet, ka šī karodziņa maiņa neko nedara.

Otrais ceļš: lietotne, kuru nekontrolējat

Uzstādītas trešās puses lietotnes drošības konfigurāciju nevarat pārrakstīt ar lietotāja iestatījumu. Reālās iespējas ir paša produkta drošas savienojuma vadīklas, uzturēta alternatīva, kas jau izmanto TLS, vai pārvaldītas ierīces politika, kas ierobežo, ko ierīce drīkst izpildīt. Tie ir atšķirīgi saistību līmeņi, un tikai trešais mērogojas uz ierīču parku.

Tīkla noteikumi ir vājāki aizstājēji, nekā šķiet. Atļaušana tikai 443. portam neuzspiež autentificētu TLS, jo daudzus atklāta teksta protokolus var pārvietot uz šo portu, un 80. porta bloķēšana neaptver atklātu tekstu citos portos. Arī pārlūka režīms tikai-HTTPS ir ierobežots ar šo pārlūku, nevis ar atsevišķu pasta vai tērzēšanas lietotni tajā pašā telefonā.

Pārtveršanas sertifikāta instalēšana, lai plūsma izskatītos šifrēta, ir uzticības maiņa, nevis labojums. Tā aizstāj lietotnes servera autentifikāciju ar jūsējo, un lietotne, kas jau sākotnēji nevalidēja sertifikātus, ar to netiek salabota; jūs tikai pārvietojāt to, kas var lasīt plūsmu.

Kur VPN palīdz un kur ne

Tunelis ir pareizais rīks, kad prasība ir, lai vietējais tīkls neuzzinātu neko par savienojumu, vai lai lietotne sasniegtu privātu servisu, kuru citādi nevar sasniegt. Tas ir nepareizais rīks, lai liktu HTTP klientam runāt HTTPS, jo pieprasījums atstāj tuneli tieši tādu, kāds tajā iegāja.

Android pievieno praktisku ierobežojumu: platforma vienlaikus darbojas tikai ar vienu VPN pakalpojumu. Vietēja filtrēšanas lietotne, kas aizņem šo vietu, konkurē ar attālo tuneli, kas jums tiešām nepieciešams, un pārslēgšanās starp tiem ir ierīces, nevis lietotnes līmeņa darbība. Šī vienīgā vieta ir labs iemesls turēt slodzes politiku lietotnē un paturēt tuneli ceļam.

Vienīgais gadījums, kad abi pārklājas, ir privāts serveris, kuru arī pārvaldāt. Tur tunelis var padarīt ceļu privātu, lai gan protokols joprojām ir atklāts teksts, kas samazina ietekmi, bet nemaina to, kas ir slodze. Uztveriet to kā riska samazināšanu, nevis datu šifrēšanu.

Kas jāpārbauda, pirms to sauc par bloķētu

Sāciet ar noklusējumu, kas pārsteidz cilvēkus: lietotnei, kas mērķē uz API 28 vai jaunāku, jau vajadzētu atteikties no atklāta teksta, tāpēc pārbaudiet mērķa līmeni pirms konfigurācijas pievienošanas, kas dublē noklusējumu. Pēc tam apzināti pārbaudiet neveiksmes gadījumu: pieprasījumam uz vienkāršu HTTP resursdatoru ir jācieš neveiksme, nevis klusi jāizdodas ar atkāpšanos.

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

Veiksmes gadījumā pārliecinieties, ka HTTPS izsaukums validē īstu sertifikātu ķēdi un ka starpnieks ar neuzticamu sertifikātu tiek noraidīts, nevis pieļauts. Rokasspiediens, kas izdodas ar jebkuru sertifikātu, nav pierādījis neko par transporta drošību.

Trešās puses lietotnei pierakstiet robežu, ko tiešām varat īstenot, vai tā būtu pārvaldītas ierīces politika, tīkla noteikums vai nekas, un pasakiet to pieņemšanas kritērijos. Android drošības konfigurācijas rokasgrāmatā ir uzskaitīti platformas noklusējumi un tas, kuras komponentes ievēro politiku, un tieši šī daļa nosaka, vai jūsu konfigurācija vispār kaut ko dara.