Blocați textul în clar în aplicațiile Android fără să vă bazați pe un VPN

Două lucruri complet diferite se numesc blocarea textului în clar pe Android. Unul este o politică din interiorul aplicației care îi cere propriului stivă de rețea să refuze HTTP simplu. Celălalt este o rânduială la nivel de dispozitiv care încearcă să protejeze totul pe telefon deodată, de obicei direcționând traficul printr-un VPN. Ele rezolvă probleme diferite, iar al doilea nu poate repara primul: un tunel protejează porțiunea dintre telefon și ieșire, în timp ce o aplicație care vorbește HTTP vorbește în continuare HTTP cu tot ce se află dincolo de acea ieșire.

Două probleme sub un singur nume

Prima problemă este încărcătura: aplicația scrie acreditări sau tokenuri într-o cerere care nu este criptată cap la cap, așa că fiecare salt care o poate vedea o poate citi. A doua este traseul: aplicația poate fi perfect corectă, iar dumneavoastră tot vreți ca operatorul Wi-Fi local să nu afle nimic despre unde se conectează. Un VPN tratează a doua și numai a doua.

Această distincție decide cui aparține remedierea. Încărcătura aparține celui care distribuie aplicația, pentru că doar acel cod decide ce URL este apelat și dacă un certificat este validat. Traseul aparține dispozitivului sau rețelei, pentru că este vorba despre unde călătoresc pachetele, nu despre ce conțin ele.

Traseul unu: aplicația pe care o controlați

Dacă distribuiți aplicația, remedierea este o decizie de transport plus o politică ce o impune. Îndreptați fiecare punct final spre HTTPS, lăsați validarea numelui de gazdă și a certificatului activată și ștergeți revenirea la HTTP simplu în loc să o lăsați la un singur fanion de configurare distanță. O redirecționare nu ajută aici: o cerere HTTP care primește un 301 a trimis deja antetele și corpul în clar, așa că acreditările nu trebuie să călătorească niciodată în presupunerea că redirecționarea le va proteja.

Începând cu Android 7.0, Network Security Configuration exprimă politica. Fișierul de mai jos este cea mai mică versiune utilă: refuză textul în clar peste tot, cu excepția cazului în care o excepție specifică domeniului spune altfel.

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

Faceți referire la acea resursă din manifest, apoi citiți excepțiile care există deja înainte de a distribui. Un domeniu vechi de depanare sau o intrare SDK a unui furnizor de plăți pot permite din nou în silență textul în clar pentru gazda pe care încercați să o protejați.

Două detalii de versiune merită cunoscute. Aplicațiile care țintesc API 28 sau mai nou refuză deja textul în clar implicit, așa că o aplicație care încă vorbește HTTP simplu fie țintește un nivel API mai vechi, fie are o excepție undeva. Și când există o configurație de securitate a rețelei, atributul de manifest mai vechi android:usesCleartextTraffic nu mai decide întrebarea, motiv pentru care schimbarea acelui fanion pare uneori că nu face nimic.

Traseul doi: aplicația pe care nu o controlați

Pentru o aplicație terță instalată nu puteți rescrie configurația ei de securitate printr-o setare de utilizator. Opțiunile realiste sunt controalele proprii ale produsului pentru conexiune sigură, o alternativă întreținută care folosește deja TLS, sau o politică de dispozitiv administrat care limitează ce poate rula dispozitivul. Acestea sunt angajamente diferite, și doar a treia se scalează la un parc de dispozitive.

Regulile de rețea sunt substitute mai slabe decât par. Permiterea doar a portului 443 nu impune TLS autentificat, pentru că multe protocoale cu text în clar pot fi mutate pe acel port, iar blocarea portului 80 nu acoperă textul în clar de pe alte porturi. Nici modul doar-HTTPS al unui browser nu se extinde dincolo de acel browser, nu la o aplicație separată de e-mail sau chat de pe același telefon.

Instalarea unui certificat de interceptare pentru ca traficul să pară criptat este o schimbare de încredere, nu o remediere. Înlocuiește autentificarea serverului aplicației cu a dumneavoastră, iar o aplicație care nu valida certificatele de la început nu este reparată de asta; ați mutat doar cine poate citi fluxul.

Unde ajută un VPN și unde nu

Un tunel este instrumentul potrivit când cerința este ca rețeaua locală să nu afle nimic despre conexiune, sau ca aplicația să atingă un serviciu privat la care altfel nu ajunge. Este instrumentul greșit pentru a face un client HTTP să vorbească HTTPS, pentru că cererea părăsește tunelul exact așa cum a intrat.

Android adaugă o constrângere practică: platforma rulează un singur serviciu VPN o dată. O aplicație locală de filtrare care ocupă acel loc concurează cu tunelul de la distanță de care aveți într-adevăr nevoie, iar trecerea între ele este o operațiune la nivel de dispozitiv, nu de aplicație. Acel singur loc este un motiv bun să păstrați politica de încărcătură în aplicație și tunelul pentru traseu.

Singurul caz în care cele două se suprapun este un server privat pe care îl administrați și dumneavoastră. Acolo un tunel poate face traseul privat chiar dacă protocolul este încă text în clar, ceea ce reduce expunerea dar nu schimbă ce este încărcătura. Tratați asta ca reducere de risc, nu ca criptare a datelor.

Ce să testați înainte de a numi asta blocat

Începeți cu valoarea implicită care surprinde oamenii: o aplicație care țintește API 28 sau mai nou ar trebui să refuze deja textul în clar, așa că verificați nivelul țintă înainte de a adăuga configurație care dublează o valoare implicită. Apoi testați intenționat cazul de eșec: o cerere către o gazdă HTTP simplă trebuie să eșueze, nu să reușească în silență printr-o revenire.

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

Pentru cazul de succes, confirmați că apelul HTTPS validează un lanț de certificate real și că un proxy cu certificat neîncrezut este refuzat, nu tolerat. O strângere de mână care reușește împotriva oricărui certificat nu a demonstrat nimic despre securitatea transportului.

Pentru o aplicație terță, notați limita pe care chiar o puteți impune, fie că este o politică de dispozitiv administrat, o regulă de rețea sau nimic, și spuneți asta în criteriile de acceptare. Ghidul de configurare a securității Android enumeră valorile implicite ale platformei și ce componente respectă politica, iar aceasta este partea care decide dacă configurația dumneavoastră face ceva.