Blokkearje platte tekst yn Android-apps sûnder op in VPN te fertrouwen

Twa hiel ferskillende dingen hjitte it blokkearjen fan platte tekst op Android. It iene is in belied binnen in app dat syn eigen netwurkstapel opdracht jout om gewoane HTTP te wegerjen. It oare is in regeling op apparaatnivo dy't besiket alles op de telefoan tagelyk te beskermjen, meastentiids troch ferkear troch in VPN te stjoeren. Se lossen ferskillende problemen op, en it twadde kin it earste net reparearje: in tunnel beskermet it stik tusken de telefoan en de útgong, wylst in app dy't HTTP praat noch altyd HTTP praat mei alles wat efter dy útgong leit.

Twa problemen ûnder ien namme

It earste probleem is de lading: de app skriuwt ynloggegevens of tokens yn in fersyk dat net fan begjin oant ein fersifere is, dus elke hop dy't it sjen kin, kin it lêze. It twadde is it paad: de app kin folslein korrekt wêze, en do wolst noch altyd dat de pleatslike Wi-Fi-operator neat leart oer wêr't er ferbynt. In VPN behannelet it twadde en allinnich it twadde.

Dat ûnderskied bepaalt wa't de reparaasje hat. De lading heart by wa't de app leveret, want allinnich dy koade beslút hokker URL oproppen wurdt en oft in sertifikaat falidearre wurdt. It paad heart by it apparaat of it netwurk, want it giet oer wêr't pakketten reizgje, net oer wat se befetsje.

Paad ien: de app dy't do kontrolearrest

As do de app leverest, is de reparaasje in ferfiersbeslút plus in belied dat it ôftwinket. Rjochtsje elk einpunt op HTTPS, hâld falidaasje fan hostnamme en sertifikaat oan, en wiskje de fallback mei gewoane HTTP ynstee fan dy ien konfiguraasjeflag fuort te litten. In trochferwizing helpt hjir net: in HTTP-fersyk dat in 301 krijt, hat syn kopteksten en lichem al iepen stjoerd, dus ynloggegevens meie nea reizgje op 'e oanname dat de trochferwizing se beskermet.

Op Android 7.0 en letter sprekt Network Security Configuration it belied út. It bestân hjirûnder is de lytste nuttige ferzje: it wegeret platte tekst oeral, útsein as in domeinspezifike útsûndering oars seit.

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

Ferwize nei dy boarne út it manifest, en lês dan de útsûnderings dy't al bestean foar't do leverest. In âld debug-domein of in SDK-ynstjoer fan in betellingsprovider kin stilwei platte tekst wer tastean foar de host dy't do besochtst te beskermjen.

Twa ferzjedetails binne it witten wurdich. Apps dy't rjochtsje op API 28 of letter wegerje platte tekst al standert, dus in app dy't noch gewoane HTTP praat rjochtet har op in âlder API-nivo of hat earne in útsûndering. En as der in netwurkfeiligenskonfiguraasje is, beslút it âldere manifestattribút android:usesCleartextTraffic de fraach net mear, en dêrom liket it feroarjen fan dy flag soms neat te dwaan.

Paad twa: de app dy't do net kontrolearrest

Foar in ynstallearre app fan tredden kinst de feiligenskonfiguraasje net oerskriuwe mei in brûkersynstelling. De reële opsjes binne de eigen kontrôles fan it produkt foar feilige ferbining, in ûnderhâlden alternatyf dat al TLS brûkt, of in belied foar beheard apparaat dat beheint wat it apparaat útfiere mei. Dat binne ferskillende ferplichtings, en allinnich de tredde skaalet nei in float.

Netwurkregels binne swakkere ferfangings as se lykje. Allinnich poarte 443 tastean twingt gjin autentisearre TLS ôf, want in soad protokollen foar platte tekst kinne nei dy poarte ferhuze wurde, en poarte 80 blokkearje dekt platte tekst op oare poarten net. De modus allinnich-HTTPS fan in browser is ek beheind ta dy browser, net ta in aparte e-post- of chat-app op deselde telefoan.

In ûnderskeppingssertifikaat ynstallearje om ferkear fersifere lykje te litten is in feroaring fan fertrouwen, net in reparaasje. It ferfangt de tjinstferifikaasje fan 'e app troch dyn, en in app dy't fan it begjin ôf gjin sertifikaten falidearre wurdt dêr net troch reparearre; do hast allinnich ferpleatst wa't de stream lêze kin.

Wêr't in VPN helpt en wêr't net

In tunnel is it goede ark as de eask is dat it pleatslike netwurk neat oer de ferbining leart, of dat de app in partikuliere tsjinst berikt dy't er oars net berikke kin. It is it ferkearde ark om in HTTP-klant HTTPS prate te litten, want it fersyk ferlit de tunnel krekt sa't it der yn gie.

Android foeget in praktyske beheining ta: it platfoarm rint ien VPN-tsjinst tagelyk. In pleatslike filterapp dy't dat plak ynnimt, konkurrearret mei de tunnel fan fierrens dy't do echt nedich hast, en tusken beide wikselje is in operaasje op apparaatnivo, net op appnivo. Dat iene plak is in goede reden om it ladingsbelied yn 'e app te hâlden en de tunnel foar it paad te bewarjen.

It iene gefal wêr't de twa oerlaapje is in partikuliere tsjinner dy't do sels ek beheart. Dêr kin in tunnel it paad partikulier meitsje, ek al is it protokol noch platte tekst, wat bleatstelling fermindert mar net feroaret wat de lading is. Behannelje dat as risikofermindering, net as fersifering fan 'e gegevens.

Wat te testen foar't do it blokkearre neamst

Begjin mei de standert dy't minsken ferrast: in app dy't rjochtet op API 28 of letter soe platte tekst al wegerje moatte, dus kontrolearje it doelnivo foar't do konfiguraasje tafoegest dy't in standert duplisearret. Test dan it gefal fan mislearring opsetlik: in fersyk nei in gewoane HTTP-host moat mislearje, net stil slagje fia in fallback.

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

Foar it gefal fan súkses, befêstigje dat de HTTPS-oprop in echte sertifikaatkeatling falidearret en dat in proxy mei in net-fertroud sertifikaat wegere wurdt yn stee fan tolerearre. In hânskodding dy't slagget tsjin hokker sertifikaat dan ek hat neat bewiisd oer ferfiersfeiligens.

Foar in app fan tredden, skriuw de grins op dy't do echt ôftwinge kinst, itsij in belied foar beheard apparaat, in netwurkregel of neat, en sis dat yn 'e akseptansekritearia. De gids foar Android-feiligenskonfiguraasje listet de standerts fan it platfoarm en hokker komponinten it belied respektearje, en dat is it part dat beslút oft dyn konfiguraasje ea wat docht.