Estä selkokielinen liikenne Android-sovelluksissa nojaamatta VPN:ään

Kahta täysin eri asiaa kutsutaan selkokielen estämiseksi Androidissa. Toinen on sovelluksen sisäinen käytäntö, joka käskee sovelluksen oman verkkopinon kieltäytyä tavallisesta HTTP:stä. Toinen on laitetason järjestely, joka yrittää suojata kaiken puhelimessa kerralla, yleensä ohjaamalla liikenne VPN:n kautta. Ne ratkaisevat eri ongelmia, eikä jälkimmäinen voi korjata ensimmäistä: tunneli suojaa puhelimen ja ulostulon välisen osuuden, kun taas HTTP:tä puhuva sovellus puhuu HTTP:tä edelleen kaiken kanssa, mikä on tuon ulostulon takana.

Kaksi ongelmaa yhdellä nimellä

Ensimmäinen ongelma on hyötykuorma: sovellus kirjoittaa tunnukset tai tokenit pyyntöön, jota ei salata päästä päähän, joten jokainen hyppy, joka näkee sen, voi lukea sen. Toinen on polku: sovellus voi olla täysin moitteeton ja silti haluat, ettei paikallinen Wi-Fi-operaattori opi mitään siitä, mihin se yhdistää. VPN käsittelee jälkimmäistä ja vain jälkimmäistä.

Tuo ero ratkaisee, kenelle korjaus kuuluu. Hyötykuorma kuuluu sille, joka toimittaa sovelluksen, koska vain se koodi päättää, mitä URL-osoitetta kutsutaan ja vahvistetaanko varmenne. Polku kuuluu laitteelle tai verkolle, koska kyse on siitä, minne paketit matkustavat, ei siitä, mitä ne sisältävät.

Polku yksi: sovellus, jota hallitset

Jos toimitat sovelluksen, korjaus on kuljetusratkaisu ja se käytäntö, joka panee sen täytäntöön. Ohjaa jokainen päätepiste HTTPS:ään, pidä isäntänimen ja varmenteen vahvistus päällä ja poista tavallisen HTTP:n varareitti sen sijaan, että jättäisit sen yhden asetuslipun päähän. Uudelleenohjaus ei auta tässä: HTTP-pyyntö, joka saa 301:n, on jo lähettänyt otsikkonsa ja runkonsa avoimena, joten tunnusten ei koskaan pidä matkustaa olettaen, että uudelleenohjaus suojaa ne.

Android 7.0:ssa ja uudemmissa Network Security Configuration ilmaisee käytännön. Alla oleva tiedosto on pienin hyödyllinen versio: se kieltäytyy selkokielestä kaikkialla, ellei verkkotunnuskohtainen poikkeus sano toisin.

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

Viittaa tähän resurssiin manifestista ja lue sitten jo olemassa olevat poikkeukset ennen toimitusta. Vanha virheenkorjausverkkotunnus tai maksuntarjoajan SDK-merkintä voi hiljaa sallia selkokielen uudelleen sille isännälle, jota yritit suojata.

Kaksi versiotietoa kannattaa tietää. API 28:aan tai uudempaan kohdistuvat sovellukset kieltäytyvät selkokielestä jo oletuksena, joten sovellus, joka puhuu yhä tavallista HTTP:tä, joko kohdistuu vanhempaan API-tasoon tai sillä on poikkeus jossain. Ja kun verkon suojausasetus on läsnä, vanhempi manifestin määre android:usesCleartextTraffic ei enää ratkaise kysymystä, minkä vuoksi lipun muuttaminen näyttää joskus tekevän ei mitään.

Polku kaksi: sovellus, jota et hallitse

Asennetun kolmannen osapuolen sovelluksen suojausasetusta et voi kirjoittaa uudelleen käyttäjäasetuksella. Realistiset vaihtoehdot ovat tuotteen omat turvallisen yhteyden hallinnat, ylläpidetty vaihtoehto, joka käyttää jo TLS:ää, tai hallitun laitteen käytäntö, joka rajoittaa, mitä laite saa suorittaa. Nämä ovat eri sitoumuksia, ja vain kolmas skaalautuu laitekantaan.

Verkkosäännöt ovat heikompia korvikkeita kuin miltä näyttävät. Vain portin 443 salliminen ei pakota todennettua TLS:ää, koska monet selkokieliprotokollat voidaan siirtää sille portille, eikä portin 80 estäminen kata selkokieltä muilla porteilla. Selaimen vain-HTTPS-tila on myös rajattu siihen selaimeen, ei saman puhelimen erilliseen sähköposti- tai chat-sovellukseen.

Sieppausvarmenteen asentaminen, jotta liikenne näyttäisi salatulta, on luottamuksen muutos, ei korjaus. Se korvaa sovelluksen palvelinvahvistuksen omallasi, eikä sovellusta, joka ei vahvistanut varmenteita alun alkaenkaan, korjata sillä; siirsit vain sitä, kuka voi lukea virran.

Missä VPN auttaa ja missä ei

Tunneli on oikea työkalu, kun vaatimus on, ettei paikallinen verkko opi yhteydestä mitään, tai että sovellus tavoittaa yksityisen palvelun, jota se ei muuten tavoita. Se on väärä työkalu HTTP-asiakkaan saamiseksi puhumaan HTTPS:ää, koska pyyntö jättää tunnelin täsmälleen sellaisena kuin sinne tuli.

Android lisää käytännön rajoituksen: alusta ajaa vain yhtä VPN-palvelua kerrallaan. Sen paikan ottava paikallinen suodatussovellus kilpailee sen etätunnelin kanssa, jota todella tarvitset, ja niiden välillä vaihtaminen on laitetason eikä sovellustason toimenpide. Tuo yksi paikka on hyvä syy pitää hyötykuorman käytäntö sovelluksessa ja säilyttää tunneli polulle.

Ainoa tapaus, jossa nämä kaksi menevät päällekkäin, on yksityinen palvelin, jota myös itse ylläpidät. Siellä tunneli voi tehdä polusta yksityisen, vaikka protokolla on yhä selkokieltä, mikä vähentää altistumista mutta ei muuta sitä, mitä hyötykuorma on. Käsittele sitä riskin vähentämisenä, älä tiedon salauksena.

Mitä testata ennen kuin kutsut sitä estetyksi

Aloita oletuksesta, joka yllättää ihmiset: API 28:aan tai uudempaan kohdistuvan sovelluksen pitäisi jo kieltäytyä selkokielestä, joten tarkista tavoitetaso ennen kuin lisäät asetusta, joka toistaa oletuksen. Testaa sitten epäonnistumistapaus tarkoituksella: pyynnön tavalliselle HTTP-isännälle on epäonnistuttava eikä onnistuttava hiljaa varareitin kautta.

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

Onnistumistapauksessa varmista, että HTTPS-kutsu vahvistaa todellisen varmenneketjun ja että epäluotettuun varmenteeseen perustuva välityspalvelin hylätään eikä sitä suvaita. Kättely, joka onnistuu mitä tahansa varmennetta vastaan, ei ole todistanut mitään kuljetuksen turvallisuudesta.

Kirjaa kolmannen osapuolen sovellukselle raja, jonka todella voit panna täytäntöön, olipa se hallitun laitteen käytäntö, verkkosääntö tai ei mitään, ja sano se hyväksymiskriteereissä. Androidin suojausasetusten opas luettelee alustan oletukset ja mitkä komponentit käytäntöä noudattavat, ja juuri se osa ratkaisee, tekeekö asetuksesi ylipäätään mitään.