Blokkeer cleartext in Android-apps sonder om op 'n VPN staat te maak

Twee heel verskillende dinge word cleartext op Android blokkeer genoem. Die een is 'n beleid binne 'n app wat sy eie netwerkstapel opdrag gee om gewone HTTP te weier. Die ander is 'n reëling op toestelvlak wat alles op die foon tegelyk probeer beskerm, gewoonlik deur verkeer deur 'n VPN te stuur. Hulle los verskillende probleme op, en die tweede een kan nie die eerste regmaak nie: 'n tonnel beskerm die segment tussen die foon en die uitgang, terwyl 'n app wat HTTP praat steeds HTTP praat met wat ook al anderkant daardie uitgang sit.

Twee probleme onder een naam

Die eerste probleem is die vrag: die app skryf geloofsbriewe of tekens in 'n versoek wat nie end-tot-end geïnkripteer is nie, so elke hop wat dit kan sien, kan dit lees. Die tweede is die pad: die app kan heeltemal ordentlik wees, en jy wil steeds hê die plaaslike Wi-Fi-operateur moet niks leer oor waarheen dit verbind nie. 'n VPN spreek die tweede aan en net die tweede.

Daardie onderskeid bepaal wie die regstelling besit. Die vrag behoort aan wie ook al die app lewer, want net daardie kode besluit watter URL dit oproep en of dit 'n sertifikaat valideer. Die pad behoort aan die toestel of die netwerk, want dit gaan oor waar pakkette reis eerder as wat hulle bevat.

Pad een: die app wat jy beheer

As jy die app lewer, is die regstelling 'n vervoerbesluit plus 'n beleid wat dit afdwing. Wys elke eindpunt na HTTPS, hou hostnaam- en sertifikaatvalidering aan, en skrap die gewone HTTP-terugval eerder as om dit een konfigurasievlag weg te laat. 'n Herleiding help nie hier nie: 'n HTTP-versoek wat 'n 301 ontvang, het reeds sy kop- en lyfdele in die ope gestuur, so geloofsbriewe moet nooit op die aanname reis dat die herleiding hulle sal beskerm nie.

Op Android 7.0 en later druk Network Security Configuration die beleid uit. Die lêer hieronder is die kleinste nuttige weergawe: dit weier cleartext oral tensy 'n domeinspesifieke uitsondering anders sê.

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

Verwys daardie hulpbron vanuit die manifest en lees dan die uitsonderings wat reeds bestaan voordat jy lewer. 'n Ou ontfoutdomein of 'n betaalverskaffer-SDK-inskrywing kan cleartext stilletjies weer toelaat vir die gasheer wat jy probeer beskerm het.

Twee weergawedetails is die moeite werd om te weet. Apps wat API 28 of later teiken, weier reeds by verstek cleartext, so 'n app wat steeds gewone HTTP praat, teiken óf 'n ouer API-vlak óf het êrens 'n uitsondering. En wanneer 'n netwerksekuriteitskonfigurasie teenwoordig is, besluit die ouer android:usesCleartextTraffic manifest-kenmerk nie meer die vraag nie, en daarom lyk dit soms of die verandering van daardie vlag niks doen nie.

Pad twee: die app wat jy nie beheer nie

Vir 'n geïnstalleerde derdeparty-app kan jy nie sy sekuriteitskonfigurasie deur 'n gebruikersinstelling herskryf nie. Die realistiese opsies is die produk se eie beheer oor veilige verbindings, 'n onderhoude alternatief wat reeds TLS gebruik, of 'n beleid vir bestuurde toestelle wat beperk wat die toestel mag uitvoer. Dit is verskillende verbintenisse, en net die derde een skaal na 'n vloot.

Netwerkreëls is swakker plaasvervangers as wat dit lyk. Om net poort 443 toe te laat, dwing nie geauthentiseerde TLS af nie, want baie gewone protokolle kan na daardie poort verskuif word, en om poort 80 te blokkeer dek nie cleartext op ander poorte nie. 'n Blaaier se HTTPS-only-modus is ook beperk tot daardie blaaier, nie tot 'n aparte e-pos- of kletsapp op dieselfde foon nie.

Om 'n onderskepsertifikaat te installeer om verkeer geïnkripteer te laat lyk, is 'n vertrouensverandering, nie 'n regstelling nie. Dit vervang die app se bedienerverifikasie met joune, en 'n app wat nie van die begin af sertifikate gevalideer het nie, word nie daardeur herstel nie; jy het net verskuif wie die stroom kan lees.

Waar 'n VPN help en waar dit nie help nie

'n Tonnel is die regte instrument wanneer die vereiste is dat die plaaslike netwerk niks oor die verbinding leer nie, of dat die app 'n private diens bereik wat dit andersins nie kan bereik nie. Dit is die verkeerde instrument om 'n HTTP-kliënt HTTPS te laat praat, want die versoek verlaat die tonnel presies soos dit ingegaan het.

Android voeg 'n praktiese beperking by: die platform laat een VPN-diens op 'n slag loop. 'n Plaaslike filterapp wat daardie plek inneem, ding mee met die afgeleë tonnel wat jy werklik nodig het, en om tussen hulle te skakel is 'n handeling op toestelvlak eerder as op appvlak. Daardie enkele plek is 'n goeie rede om vragbeleid in die app te plaas en die tonnel vir die pad te hou.

Die een geval waar die twee oorvleuel, is 'n private bediener wat jy ook bedryf. Daar kan 'n tonnel die pad privaat maak, al is die protokol steeds cleartext, wat blootstelling verminder maar nie verander wat die vrag is nie. Behandel dit as vermindering van risiko, nie as enkripsie van die data nie.

Wat om te toets voordat jy dit geblokkeer noem

Begin met die verstek wat mense verras: 'n app wat API 28 of later teiken, behoort reeds cleartext te weier, so kyk na die teikenvlak voordat jy konfigurasie byvoeg wat 'n verstek dupliseer. Toets dan die mislukkingsgeval doelbewus: 'n versoek na 'n gewone HTTP-gasheer moet misluk eerder as om stilweg deur 'n terugval te slaag.

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

Vir die suksesgeval, bevestig dat die HTTPS-oproep 'n werklike sertifikaatketting valideer en dat 'n instaanbediener met 'n onvertroude sertifikaat verwerp word eerder as geduld. 'n Handdruk wat teen enige sertifikaat slaag, het niks oor vervoersekuriteit bewys nie.

Vir 'n derdeparty-app, skryf die grens neer wat jy werklik kan afdwing, hetsy dit 'n beleid vir bestuurde toestelle, 'n netwerkreël of niks is, en sê so in die aanvaardingskriteria. Die Android-sekuriteitskonfigurasiegids lys die platformverstekke en watter komponente die beleid eerbiedig, wat die deel is wat besluit of jou konfigurasie hoegenaamd iets doen.