Blokker klartekst i Android-appar utan å vere avhengig av ein VPN

To svært ulike ting vert kalla å blokkere klartekst på Android. Det eine er ein policy inne i ein app som ber appen sitt eige nettverksstakk om å avvise vanleg HTTP. Det andre er ei ordning på einingnivå som prøver å verne alt på telefonen på ein gong, vanlegvis ved å rute trafikken gjennom ein VPN. Dei løyser ulike problem, og det andre kan ikkje reparere det første: ein tunnel vernar strekket mellom telefonen og utgangen, medan ein app som talar HTTP framleis talar HTTP med alt som ligg bak den utgangen.

To problem under eitt namn

Det første problemet er lasta: appen skriv legitimasjon eller token i ein førespurnad som ikkje er kryptert ende til ende, så kvart hopp som kan sjå han, kan lese han. Det andre er vegen: appen kan vere heilt korrekt, og du vil likevel at den lokale Wi-Fi-operatøren ikkje skal lære noko om kvar han koplar til. Ein VPN handterer det andre og berre det andre.

Den skilnaden avgjer kven som eig rettinga. Lasta høyrer til den som leverer appen, fordi berre den koden avgjer kva URL som vert kalla og om eit sertifikat vert validert. Vegen høyrer til eininga eller nettverket, fordi det handlar om kvar pakkane reiser, ikkje kva dei inneheld.

Vegen ein: appen du kontrollerer

Viss du leverer appen, er rettinga eit transportval pluss ein policy som handhevar det. Peik kvar endepunkt mot HTTPS, hald validering av vertsnamn og sertifikat på, og slett reservevegen med vanleg HTTP i staden for å la han liggje éin konfigurasjonsflagg unna. Ei omdirigering hjelper ikkje her: ein HTTP-førespurnad som får ein 301, har allereie sendt headrane og kroppen i klartekst, så legitimasjon må aldri reise med den føresetnaden at omdirigeringa verner han.

På Android 7.0 og nyare uttrykkjer Network Security Configuration policyen. Fila nedanfor er den minste nyttige versjonen: ho avviser klartekst overalt med mindre eit domenespesifikt unntak seier noko anna.

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

Vis til den ressursen frå manifestet, og les deretter unntaka som allereie finst, før du leverer. Eit gammalt feilsøkingsdomene eller ei SDK-oppføring frå ein betalingsleverandør kan stille og roleg tillate klartekst igjen for verten du prøvde å verne.

To versjonsdetaljar er verd å kjenne. Appar som rettar seg mot API 28 eller nyare, avviser allereie klartekst som standard, så ein app som framleis talar vanleg HTTP, rettar seg anten mot eit eldre API-nivå eller har eit unntak ein stad. Og når det finst ein nettverkssikkerheitskonfigurasjon, avgjer ikkje det eldre manifestattributtet android:usesCleartextTraffic spørsmålet lenger, og difor ser det nokre gonger ut som om endringa av det flagget ikkje gjer noko.

Vegen to: appen du ikkje kontrollerer

For ein installert tredjepartsapp kan du ikkje skrive om sikkerheitskonfigurasjonen hans via ei brukarinnstilling. Dei realistiske alternativa er produktet sine eigne kontrollar for sikker tilkopling, eit vedlikehalde alternativ som allereie brukar TLS, eller ein policy for administrerte einingar som avgrensar kva eininga får køyre. Det er ulike forpliktingar, og berre den tredje skalerer til ein flåte.

Nettverksreglar er svakare erstatningar enn dei ser ut. Å tillate berre port 443 handhevar ikkje autentisert TLS, sidan mange klartekstprotokollar kan flyttast til den porten, og å blokkere port 80 dekkjer ikkje klartekst på andre portar. Ein nettlesars modus med berre HTTPS er også avgrensa til den nettlesaren, ikkje til ein separat e-post- eller chat-app på same telefon.

Å installere eit avlyttingssertifikat for at trafikken skal sjå kryptert ut, er ei endring av tillit, ikkje ei retting. Det erstattar serverautentiseringa til appen med di, og ein app som ikkje validerte sertifikat i utgangspunktet, vert ikkje reparert av det; du har berre flytta kven som kan lese straumen.

Kvar ein VPN hjelper, og kvar han ikkje gjer det

Ein tunnel er det rette verktøyet når kravet er at det lokale nettverket ikkje skal lære noko om sambandet, eller at appen skal nå ei privat teneste han elles ikkje når. Han er det gale verktøyet for å få ein HTTP-klient til å tale HTTPS, fordi førespurnaden forlèt tunnelen nøyaktig slik han kom inn.

Android legg til ei praktisk avgrensing: plattforma køyrer berre éin VPN-teneste om gongen. Ein lokal filtreringsapp som tek den plassen, konkurrerer med den eksterne tunnelen du faktisk treng, og å byte mellom dei er ei handling på einingsnivå snarare enn appnivå. Den eine plassen er ein god grunn til å leggje lastpolicyen i appen og behalde tunnelen for vegen.

Det einaste tilfellet der dei to overlappar, er ein privat server du også driv sjølv. Der kan ein tunnel gjere vegen privat sjølv om protokollen framleis er klartekst, noko som reduserer eksponeringa, men ikkje endrar kva lasta er. Handsama det som risikoreduksjon, ikkje som kryptering av dataa.

Kva du bør teste før du kallar det blokkert

Start med standarden som overraskar folk: ein app som rettar seg mot API 28 eller nyare, bør allereie avvise klartekst, så sjekk målnivået før du legg til konfigurasjon som dupliserer ein standard. Test deretter feiltilfellet med vilje: ein førespurnad til ein vanleg HTTP-vert må feile i staden for stille å lukkast gjennom ein reserveveg.

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

For suksesstilfellet, stadfest at HTTPS-kallet validerer ein ekte sertifikatkjede, og at ein proxy med eit ikkje-klarert sertifikat vert avvist i staden for tolerert. Eit handtrykk som lukkast mot kva sertifikat som helst, har ikkje prova noko om transporttryggleik.

For ein tredjepartsapp, skriv ned grensa du faktisk kan handheve, anten det er ein policy for administrerte einingar, ein nettverksregel eller ingenting, og seie det i akseptkriteria. Android-rettleiinga for sikkerheitskonfigurasjon viser standardane til plattforma og kva komponentar som respekterer policyen, og det er den delen som avgjer om konfigurasjonen din i det heile gjer noko.