Bloker klartekst i Android-apps uden at være afhængig af en VPN

To meget forskellige ting kaldes at blokere klartekst på Android. Det ene er en politik inde i en app, der beder appens eget netværkslag om at afvise almindelig HTTP. Det andet er en ordning på enhedsniveau, der forsøger at beskytte alt på telefonen på én gang, normalt ved at føre trafik gennem en VPN. De løser forskellige problemer, og det andet kan ikke reparere det første: en tunnel beskytter strækningen mellem telefonen og udgangen, mens en app, der taler HTTP, stadig taler HTTP med alt, hvad der ligger bag den udgang.

To problemer under ét navn

Det første problem er lasten: appen skriver legitimationsoplysninger eller tokens i en anmodning, der ikke er krypteret ende til ende, så hvert hop, der kan se den, kan læse den. Det andet er vejen: appen kan være helt velopdragen, og du vil stadig ikke have, at den lokale Wi-Fi-operatør lærer noget om, hvor den forbinder hen. En VPN håndterer det andet og kun det andet.

Den forskel afgør, hvem der ejer rettelsen. Lasten tilhører den, der leverer appen, fordi kun den kode bestemmer, hvilken URL der kaldes, og om der valideres et certifikat. Vejen tilhører enheden eller netværket, fordi det handler om, hvor pakkerne rejser hen, ikke hvad de indeholder.

Vej et: den app, du kontrollerer

Hvis du leverer appen, er rettelsen en transportbeslutning plus en politik, der håndhæver den. Peg hvert endepunkt mod HTTPS, hold validering af værtsnavn og certifikat slået til, og slet reservevejen med almindelig HTTP i stedet for at lade den ligge ét konfigurationsflag væk. En omdirigering hjælper ikke her: en HTTP-anmodning, der får en 301, har allerede sendt sine headers og sin krop i klartekst, så legitimationsoplysninger må aldrig rejse med den antagelse, at omdirigeringen beskytter dem.

På Android 7.0 og nyere udtrykker Network Security Configuration politikken. Filen nedenfor er den mindste brugbare version: den afviser klartekst overalt, medmindre en domænespecifik undtagelse siger andet.

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

Referer til den ressource fra manifestet, og læs derefter de undtagelser, der allerede findes, før du leverer. Et gammelt fejlretningsdomæne eller en SDK-post fra en betalingsudbyder kan stille og roligt igen tillade klartekst for den vært, du prøvede at beskytte.

To versionsdetaljer er værd at kende. Apps, der retter sig mod API 28 eller nyere, afviser allerede klartekst som standard, så en app, der stadig taler almindelig HTTP, enten retter sig mod et ældre API-niveau eller har en undtagelse et sted. Og når der findes en netværkssikkerhedskonfiguration, bestemmer den ældre manifestattribut android:usesCleartextTraffic ikke længere spørgsmålet, og derfor ser det nogle gange ud, som om ændringen af det flag ikke gør noget.

Vej to: den app, du ikke kontrollerer

For en installeret tredjepartsapp kan du ikke omskrive dens sikkerhedskonfiguration via en brugerindstilling. De realistiske muligheder er produktets egne kontroller for sikker forbindelse, et vedligeholdt alternativ, der allerede bruger TLS, eller en politik for administrerede enheder, der begrænser, hvad enheden må køre. Det er forskellige forpligtelser, og kun den tredje skalerer til en flåde.

Netværksregler er svagere erstatninger, end de ser ud. At tillade kun port 443 håndhæver ikke autentificeret TLS, da mange klartekstprotokoller kan flyttes til den port, og blokering af port 80 dækker ikke klartekst på andre porte. En browsers tilstand med kun HTTPS er også begrænset til den browser, ikke til en separat mail- eller chatapp på samme telefon.

At installere et aflytningscertifikat for at få trafik til at se krypteret ud er en ændring af tillid, ikke en rettelse. Det erstatter appens servergodkendelse med din, og en app, der ikke validerede certifikater i forvejen, bliver ikke repareret af det; du har kun flyttet, hvem der kan læse strømmen.

Hvor en VPN hjælper, og hvor den ikke gør

En tunnel er det rigtige værktøj, når kravet er, at det lokale netværk ikke lærer noget om forbindelsen, eller at appen når en privat tjeneste, den ellers ikke kan nå. Den er det forkerte værktøj til at få en HTTP-klient til at tale HTTPS, fordi anmodningen forlader tunnelen præcis, som den kom ind i den.

Android tilføjer en praktisk begrænsning: platformen kører kun én VPN-tjeneste ad gangen. En lokal filtreringsapp, der tager den plads, konkurrerer med den fjernede tunnel, du faktisk har brug for, og at skifte mellem dem er en handling på enhedsniveau snarere end appniveau. Den ene plads er en god grund til at lægge lastpolitikken i appen og beholde tunnelen til vejen.

Det eneste tilfælde, hvor de to overlapper, er en privat server, du også selv driver. Der kan en tunnel gøre vejen privat, selvom protokollen stadig er klartekst, hvilket reducerer eksponering, men ikke ændrer, hvad lasten er. Behandl det som risikoreduktion, ikke som kryptering af dataene.

Hvad du skal teste, før du kalder det blokeret

Start med den standard, der overrasker folk: en app, der retter sig mod API 28 eller nyere, burde allerede afvise klartekst, så tjek målniveauet, før du tilføjer konfiguration, der duplikerer en standard. Test derefter fejltilfældet bevidst: en anmodning til en almindelig HTTP-vært skal fejle i stedet for stille at lykkes gennem en reservevej.

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

For succes tilfældet skal du bekræfte, at HTTPS-kaldet validerer en rigtig certifikatkæde, og at en proxy med et ikke-betroet certifikat afvises i stedet for tolereres. Et håndtryk, der lykkes mod ethvert certifikat, har ikke bevist noget om transportsikkerhed.

For en tredjepartsapp skal du skrive den grænse ned, du faktisk kan håndhæve, hvad enten det er en politik for administrerede enheder, en netværksregel eller intet, og sige det i acceptkriterierne. Android-vejledningen om sikkerhedskonfiguration viser platformens standarder og hvilke komponenter der respekterer politikken, og det er den del, der afgør, om din konfiguration overhovedet gør noget.