Lokaðu fyrir ódulkóðaðan texta í Android-forritum án þess að treysta á VPN

Tveir gjörólíkir hlutir eru kallaðir að loka fyrir ódulkóðaðan texta á Android. Annar er stefna inni í forriti sem skipar eigin netstakka að hafna venjulegu HTTP. Hinn er fyrirkomulag á tækjastigi sem reynir að vernda allt í símanum í einu, venjulega með því að beina umferð í gegnum VPN. Þeir leysa ólík vandamál, og sá síðari getur ekki lagað þann fyrri: göng vernda kaflann milli símans og útgangsins, en forrit sem talar HTTP talar áfram HTTP við allt sem er handan þess útgangs.

Tvö vandamál undir einu nafni

Fyrra vandamálið er farmurinn: forritið skrifar auðkenni eða tákn í beiðni sem er ekki dulkóðuð enda til enda, svo hvert stökk sem sér hana getur lesið hana. Seinna er leiðin: forritið getur verið fullkomlega rétt, og þú vilt samt að staðbundinn Wi-Fi-rekstraraðili læri ekkert um hvert það tengist. VPN tekur á því seinna og aðeins því seinna.

Sú aðgreining ákvarðar hver á lagfæringuna. Farmurinn tilheyrir þeim sem sendir forritið, því aðeins sá kóði ákveður hvaða slóð er kölluð og hvort skírteini er staðfest. Leiðin tilheyrir tækinu eða netinu, því um það er rætt hvert pakkar ferðast, ekki hvað þeir geyma.

Leið eitt: forritið sem þú stjórnar

Ef þú sendir forritið er lagfæringin flutningsákvörðun ásamt stefnu sem framfylgir henni. Beindu hverjum endapunkti á HTTPS, hafðu staðfestingu hýsilnafns og skírteinis kveikta, og eyddu varaleiðinni með venjulegu HTTP í stað þess að skilja hana eftir eitt stillingarflagg í burtu. Endurbeining hjálpar ekki hér: HTTP-beiðni sem fær 301 hefur þegar sent hausana og líkamann opinskátt, svo auðkenni mega aldrei ferðast í þeirri trú að endurbeiningin verndi þau.

Á Android 7.0 og nýrri tjáir Network Security Configuration stefnuna. Skráin hér að neðan er minnsta gagnlega útgáfan: hún hafnar ódulkóðuðum texta alls staðar nema undantekning fyrir tiltekið lén segi annað.

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

Vísaðu í þessa auðlind úr manifestinu og lestu síðan undantekningarnar sem þegar eru til áður en þú sendir. Gamalt villuleitar-lén eða SDK-færsla greiðsluveitanda getur hljóðlega leyft ódulkóðaðan texta aftur fyrir hýsilinn sem þú reyndir að vernda.

Tveir útgáfuatriðir eru þekkingarverðir. Forrit sem miða á API 28 eða nýrra hafna nú þegar ódulkóðuðum texta sjálfgefið, svo forrit sem talar enn venjulegt HTTP miðar annaðhvort á eldra API-stig eða hefur undantekningu einhvers staðar. Og þegar netöryggisstilling er til staðar ákveður eldri manifesteiginleikinn android:usesCleartextTraffic ekki lengur spurninguna, og þess vegna virðist breyting á því flaggi stundum gera ekkert.

Leið tvö: forritið sem þú stjórnar ekki

Fyrir uppsett forrit frá þriðja aðila geturðu ekki endurskrifað öryggisstillingu þess með notendastillingu. Raunhæfir valkostir eru eigin stýringar vörunnar fyrir örugga tengingu, viðhaldið val sem notar þegar TLS, eða stefna fyrir stýrt tæki sem takmarkar hvað tækið má keyra. Þetta eru mismunandi skuldbindingar, og aðeins sú þriðja stækkar yfir flota.

Netreglur eru veikari staðgenglar en þær virðast. Að leyfa aðeins gátt 443 framfylgir ekki auðkenndu TLS, því margvísleg ódulkóðuð samskiptareglur er hægt að færa á þá gátt, og að loka gátt 80 nær ekki yfir ódulkóðaðan texta á öðrum gáttum. Eingöngu-HTTPS stilling vafra er líka bundin við þann vafra, ekki við sér póst- eða spjallforrit í sama síma.

Að setja upp afhlöðunarskírteini svo umferð líti dulkóðuð út er breyting á trausti, ekki lagfæring. Það kemur í stað netþjónsauðkenningar forritsins fyrir þína, og forrit sem staðfesti ekki skírteini frá upphafi er ekki lagað af því; þú færðir bara til hver getur lesið strauminn.

Hvar VPN hjálpar og hvar ekki

Göng eru rétta verkfærið þegar krafan er að staðbundið net læri ekkert um tenginguna, eða að forritið nái einkanlegri þjónustu sem það nær ekki annars. Þau eru röng verkfæri til að láta HTTP-biðlara tala HTTPS, því beiðnin yfirgefur göngin nákvæmlega eins og hún fór inn.

Android bætir við hagnýtri takmörkun: kerfið keyrir aðeins eina VPN-þjónustu í einu. Staðbundið síuforrit sem tekur það pláss keppir við fjartengdu göngin sem þú þarft í raun, og að skipta milli þeirra er aðgerð á tækjastigi, ekki forritsstigi. Þetta eina pláss er góð ástæða til að hafa farmstefnuna í forritinu og halda göngunum fyrir leiðina.

Eina tilvikið þar sem þau skarast er einkanlegur netþjónn sem þú rekur líka. Þar geta göng gert leiðina einkalega þótt samskiptareglurnar séu enn ódulkóðaður texti, sem dregur úr áhættu en breytir ekki því hvað farmurinn er. Meðhöndlaðu það sem áhættuminnkun, ekki sem dulkóðun gagnanna.

Hvað á að prófa áður en þetta er kallað lokað

Byrjaðu á sjálfgefnu stillingunni sem kemur fólki á óvart: forrit sem miðar á API 28 eða nýrra ætti þegar að hafna ódulkóðuðum texta, svo athugaðu markstigið áður en þú bætir við stillingu sem tvöfaldar sjálfgefið gildi. Prófaðu svo bilanatilvikið viljandi: beiðni til venjulegs HTTP-hýsils verður að mistakast, ekki takast hljóðlega í gegnum varaleið.

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

Fyrir árangurstilvikið skaltu staðfesta að HTTPS-kallið staðfesti raunverulega skírteinakeðju og að milliþjónn með ótraustu skírteini sé hafnað en ekki liðinn. Handaband sem tekst gegn hvaða skírteini sem er hefur ekkert sannað um flutningsöryggi.

Fyrir forrit frá þriðja aðila skaltu skrifa niður mörkin sem þú getur í raun framfylgt, hvort sem það er stefna fyrir stýrt tæki, netregla eða ekkert, og segðu það í samþykkisskilyrðunum. Leiðarvísirinn um öryggisstillingar Android telur upp sjálfgefnar stillingar kerfisins og hvaða einingar virða stefnuna, og það er sá hluti sem ákveður hvort stillingin þín gerir nokkuð yfirleitt.