Harangin ang plaintext sa mga Android app nang hindi umaasa sa VPN

Dalawang lubos na magkaibang bagay ang tinatawag na pagharang sa plaintext sa Android. Ang isa ay patakaran sa loob ng app na nag-uutos sa sarili nitong network stack na tanggihan ang karaniwang HTTP. Ang isa pa ay kaayusan sa antas ng device na sinusubukang protektahan ang lahat sa telepono nang sabay, karaniwang sa pagruruta ng trapiko sa VPN. Iba ang problema nilang nilulutas, at hindi kayang ayusin ng pangalawa ang una: pinoprotektahan ng tunnel ang bahagi sa pagitan ng telepono at labasan, samantalang ang app na nagbabanggit ng HTTP ay nagpapatuloy pa ring magbanggit ng HTTP sa lahat ng nasa likod ng labasang iyon.

Dalawang problema sa ilalim ng isang pangalan

Ang unang problema ay ang payload: isinusulat ng app ang mga kredensyal o token sa isang kahilingan na hindi naka-encrypt mula simula hanggang dulo, kaya nakakabasa ang bawat hop na nakakakita nito. Ang pangalawa ay ang landas: maaaring perpektong tama ang app, at gusto mo pa ring walang malaman ang lokal na Wi-Fi operator tungkol sa kinakabitan nito. Ang VPN ay humaharap sa pangalawa at sa pangalawa lamang.

Ang pagkakaibang iyon ang nagtatakda kung kanino ang pagwawasto. Ang payload ay pag-aari ng nagpapadala ng app, dahil ang code na iyon lang ang nagtatakda kung aling URL ang tinatawagan at kung may sinusuri na sertipiko. Ang landas ay pag-aari ng device o ng network, dahil tungkol ito sa kung saan naglalakbay ang mga packet, hindi sa kung ano ang nilalaman nila.

Landas isa: ang app na kontrolado mo

Kung ikaw ang nagpapadala ng app, ang pagwawasto ay desisyon sa transport at patakarang nagpapatupad nito. Ituro ang bawat endpoint sa HTTPS, panatilihing bukas ang pagpapatunay ng hostname at sertipiko, at burahin ang pagbabalik sa karaniwang HTTP sa halip na iwanan ito isang configuration flag ang layo. Hindi nakakatulong ang redirect dito: ang kahilingang HTTP na tumatanggap ng 301 ay naipadala na ang mga header at katawan nito nang hayagan, kaya hindi dapat kailanman bumiyahe ang mga kredensyal sa pag-aakalang ipoprotektahan sila ng redirect.

Mula sa Android 7.0, ipinapahayag ng Network Security Configuration ang patakaran. Ang file sa ibaba ay ang pinakamaliit na kapaki-pakinabang na bersyon: tinatanggihan nito ang plaintext sa lahat ng dako maliban kung may domain-specific na pagbubukod na nagsasabi ng iba.

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

Banggitin ang resource na iyon mula sa manifest, pagkatapos ay basahin ang mga pagbubukod na mayroon na bago ipadala. Maaaring tahimik na muling payagan ng lumang debug domain o ng SDK entry ng payment provider ang plaintext para sa host na sinusubukan mong protektahan.

Dalawang detalye ng bersyon ang dapat malaman. Ang mga app na naglalayon sa API 28 o mas bago ay tinatanggihan na ang plaintext bilang default, kaya ang app na nagsasalita pa rin ng karaniwang HTTP ay alinman sa naglalayon sa mas lumang antas ng API o may pagbubukod sa isang lugar. At kapag may configuration ng seguridad ng network, hindi na nagpapasya ang mas lumang android:usesCleartextTraffic manifest attribute sa usaping iyon, kaya kung minsan ay parang walang ginagawa ang pagbabago ng flag na iyon.

Landas dalawa: ang app na hindi mo kontrolado

Para sa naka-install na third-party app, hindi mo maisusulat muli ang configuration ng seguridad nito sa pamamagitan ng setting ng user. Ang mga makatotohanang opsyon ay ang sariling mga kontrol ng produkto para sa secure na koneksyon, isang maintained na alternatibo na gumagamit na ng TLS, o patakaran ng managed device na naglilimita sa maaaring patakbuhin ng device. Iba-iba ang mga pangakong ito, at ang pangatlo lamang ang umaabot sa isang fleet.

Ang mga panuntunan ng network ay mas mahinang kapalit kaysa sa tila. Ang pagpayag lamang sa port 443 ay hindi nagpapatupad ng authenticated TLS, dahil maraming plaintext protocol ang maaaring ilipat sa port na iyon, at ang pagharang sa port 80 ay hindi sumasaklaw sa plaintext sa ibang port. Ang mode na HTTPS-only ng browser ay limitado rin sa browser na iyon, hindi sa hiwalay na mail o chat app sa parehong telepono.

Ang pag-install ng interception certificate upang magmukhang naka-encrypt ang trapiko ay pagbabago ng tiwala, hindi pagwawasto. Pinapalitan nito ang server authentication ng app ng sa iyo, at ang app na hindi nagpapatunay ng mga sertipiko mula pa sa simula ay hindi naaayos nito; inilipat mo lamang kung sino ang makakabasa ng stream.

Saan nakakatulong ang VPN at saan hindi

Ang tunnel ay tamang kasangkapan kapag ang pangangailangan ay walang matutunan ang lokal na network tungkol sa koneksyon, o maabot ng app ang isang pribadong serbisyo na hindi nito maabot sa ibang paraan. Mali itong kasangkapan para mapagsalita ng HTTPS ang isang HTTP client, dahil lumalabas ang kahilingan sa tunnel nang eksaktong tulad ng pagpasok nito.

May idinadagdag ang Android na praktikal na paghihigpit: isang serbisyo ng VPN lamang ang pinapatakbo ng platform nang sabay. Ang lokal na filtering app na kumukuha ng puwang na iyon ay nakikipagkumpitensya sa remote tunnel na talagang kailangan mo, at ang paglipat sa pagitan ng dalawa ay operasyon sa antas ng device hindi sa antas ng app. Ang nag-iisang puwang na iyon ay magandang dahilan upang ilagay ang patakaran ng payload sa app at itago ang tunnel para sa landas.

Ang tanging kaso kung saan nagsasapawan ang dalawa ay isang pribadong server na pinapatakbo mo rin. Doon maaaring gawing pribado ng tunnel ang landas kahit plaintext pa rin ang protocol, na nagpapababa ng pagkakalantad ngunit hindi nagbabago kung ano ang payload. Ituring ito bilang pagbabawas ng panganib, hindi bilang encryption ng data.

Ano ang dapat subukan bago tawagin itong naka-harang

Magsimula sa default na nagugulat sa mga tao: ang app na naglalayon sa API 28 o mas bago ay dapat na tinatanggihan ang plaintext, kaya tingnan ang target na antas bago magdagdag ng configuration na nagdoble sa isang default. Pagkatapos ay sadyang subukan ang kaso ng pagpalya: ang kahilingan sa karaniwang HTTP host ay dapat mabigo, hindi tahimik na magtagumpay sa pamamagitan ng pagbabalik.

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

Para sa kaso ng tagumpay, kumpirmahin na ang tawag sa HTTPS ay nagpapatunay ng tunay na chain ng sertipiko at ang proxy na may hindi pinagkakatiwalaang sertipiko ay tinatanggihan sa halip na pinahihintulutan. Ang handshake na nagtatagumpay laban sa anumang sertipiko ay walang napatunayan tungkol sa seguridad ng transport.

Para sa third-party app, isulat ang hangganan na talagang maipatutupad mo, maging patakaran ng managed device, panuntunan ng network o wala, at sabihin ito sa mga pamantayan ng pagtanggap. gabay sa configuration ng seguridad ng Android ay naglilista ng mga default ng platform at kung aling mga bahagi ang gumagalang sa patakaran, at iyon ang bahaging nagtatakda kung may ginagawa man ang configuration mo.