Blokker klartekst i Android-apper uten å være avhengig av en VPN

To svært forskjellige ting kalles å blokkere klartekst på Android. Det ene er en policy inne i en app som ber appens eget nettverksstakk om å avvise vanlig HTTP. Det andre er en ordning på enhetsnivå som prøver å beskytte alt på telefonen på en gang, vanligvis ved å rute trafikken gjennom en VPN. De løser forskjellige problemer, og det andre kan ikke reparere det første: en tunnel beskytter strekket mellom telefonen og utgangen, mens en app som snakker HTTP fortsatt snakker HTTP med alt som ligger bak den utgangen.

To problemer under ett navn

Det første problemet er lasten: appen skriver legitimasjon eller tokens i en forespørsel som ikke er kryptert ende til ende, så hvert hopp som kan se den, kan lese den. Det andre er veien: appen kan være helt korrekt, og du vil fortsatt at den lokale Wi-Fi-operatøren ikke skal lære noe om hvor den kobler til. En VPN håndterer det andre og bare det andre.

Den forskjellen avgjør hvem som eier rettelsen. Lasten tilhører den som leverer appen, fordi bare den koden bestemmer hvilken URL som kalles og om et sertifikat valideres. Veien tilhører enheten eller nettverket, fordi det handler om hvor pakkene reiser, ikke hva de inneholder.

Veien en: appen du kontrollerer

Hvis du leverer appen, er rettelsen et transportvalg pluss en policy som håndhever det. Pek hvert endepunkt mot HTTPS, hold validering av vertsnavn og sertifikat på, og slett reserveveien med vanlig HTTP i stedet for å la den ligge én konfigurasjonsflagg unna. En omdirigering hjelper ikke her: en HTTP-forespørsel som får en 301, har allerede sendt headerne og kroppen i klartekst, så legitimasjon må aldri reise med den antakelsen at omdirigeringen beskytter den.

På Android 7.0 og nyere uttrykker Network Security Configuration policyen. Filen nedenfor er den minste nyttige versjonen: den avviser klartekst overalt med mindre et domenespesifikt unntak sier noe annet.

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

Vis til den ressursen fra manifestet, og les deretter unntakene som allerede finnes, før du leverer. Et gammelt feilsøkingsdomene eller en SDK-oppføring fra en betalingsleverandør kan stille og rolig tillate klartekst igjen for verten du prøvde å beskytte.

To versjonsdetaljer er verdt å kjenne. Apper som retter seg mot API 28 eller nyere, avviser allerede klartekst som standard, så en app som fortsatt snakker vanlig HTTP, enten retter seg mot et eldre API-nivå eller har et unntak et sted. Og når det finnes en nettverkssikkerhetskonfigurasjon, avgjør ikke det eldre manifestattributtet android:usesCleartextTraffic spørsmålet lenger, og derfor ser det noen ganger ut som om endringen av det flagget ikke gjør noe.

Veien to: appen du ikke kontrollerer

For en installert tredjepartsapp kan du ikke skrive om sikkerhetskonfigurasjonen dens via en brukerinnstilling. De realistiske alternativene er produktets egne kontroller for sikker tilkobling, et vedlikeholdt alternativ som allerede bruker TLS, eller en policy for administrerte enheter som begrenser hva enheten får kjøre. Det er forskjellige forpliktelser, og bare den tredje skalerer til en flåte.

Nettverksregler er svakere erstatninger enn de ser ut. Å tillate bare port 443 håndhever ikke autentisert TLS, siden mange klartekstprotokoller kan flyttes til den porten, og å blokkere port 80 dekker ikke klartekst på andre porter. En nettlesers modus med bare HTTPS er også begrenset til den nettleseren, ikke til en separat e-post- eller chat-app på samme telefon.

Å installere et avlyttingssertifikat for at trafikken skal se kryptert ut, er en endring av tillit, ikke en rettelse. Det erstatter appens serverautentisering med din, og en app som ikke validerte sertifikater i utgangspunktet, blir ikke reparert av det; du har bare flyttet hvem som kan lese strømmen.

Hvor en VPN hjelper, og hvor den ikke gjør det

En tunnel er det riktige verktøyet når kravet er at det lokale nettverket ikke skal lære noe om forbindelsen, eller at appen skal nå en privat tjeneste den ellers ikke når. Den er det gale verktøyet for å få en HTTP-klient til å snakke HTTPS, fordi forespørselen forlater tunnelen nøyaktig slik den kom inn.

Android legger til en praktisk begrensning: plattformen kjører bare én VPN-tjeneste om gangen. En lokal filtreringsapp som tar den plassen, konkurrerer med den eksterne tunnelen du faktisk trenger, og å bytte mellom dem er en handling på enhetsnivå snarere enn appnivå. Den ene plassen er en god grunn til å legge lastpolicyen i appen og beholde tunnelen for veien.

Det eneste tilfellet der de to overlapper, er en privat server du også driver selv. Der kan en tunnel gjøre veien privat selv om protokollen fortsatt er klartekst, noe som reduserer eksponeringen, men ikke endrer hva lasten er. Behandle det som risikoreduksjon, ikke som kryptering av dataene.

Hva du bør teste før du kaller det blokkert

Start med standarden som overrasker folk: en app som retter seg mot API 28 eller nyere, bør allerede avvise klartekst, så sjekk målnivået før du legger til konfigurasjon som dupliserer en standard. Test deretter feiltilfellet med vilje: en forespørsel til en vanlig HTTP-vert må feile i stedet for stille å lykkes gjennom en reservevei.

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

For suksesstilfellet, bekreft at HTTPS-kallet validerer en ekte sertifikatkjede, og at en proxy med et ikke-klarert sertifikat avvises i stedet for tolereres. Et håndtrykk som lykkes mot hvilket som helst sertifikat, har ikke bevist noe om transportsikkerhet.

For en tredjepartsapp, skriv ned grensen du faktisk kan håndheve, enten det er en policy for administrerte enheter, en nettverksregel eller ingenting, og si det i akseptkriteriene. Android-veiledningen for sikkerhetskonfigurasjon viser plattformens standarder og hvilke komponenter som respekterer policyen, og det er den delen som avgjør om konfigurasjonen din i det hele tatt gjør noe.