Bloqueja el text en clar a les aplicacions d'Android sense dependre d'una VPN

Dues coses molt diferents es diuen bloquejar el text en clar a Android. Una és una política dins d'una aplicació que ordena a la seva pròpia pila de xarxa que rebutgi l'HTTP simple. L'altra és un arranjament a nivell de dispositiu que intenta protegir-ho tot al telèfon alhora, normalment encaminant el trànsit per una VPN. Resolen problemes diferents, i la segona no pot arreglar la primera: un túnel protegeix el tram entre el telèfon i la sortida, mentre que una aplicació que parla HTTP continua parlant HTTP amb tot el que hi ha més enllà d'aquella sortida.

Dos problemes amb un sol nom

El primer problema és la càrrega: l'aplicació escriu credencials o testimonis en una petició que no està xifrada d'extrem a extrem, de manera que cada salt que la pot veure la pot llegir. El segon és el camí: l'aplicació pot ser perfectament correcta i tot i així voleu que l'operador de Wi-Fi local no aprengui res sobre on es connecta. Una VPN adreça el segon i només el segon.

Aquesta distinció decideix qui és l'amo de la correcció. La càrrega pertany a qui distribueix l'aplicació, perquè només aquell codi decideix quina URL crida i si valida un certificat. El camí pertany al dispositiu o a la xarxa, perquè es tracta d'on viatgen els paquets i no de què contenen.

Camí u: l'aplicació que controleu

Si distribuïu l'aplicació, la correcció és una decisió de transport més una política que la imposa. Apunteu cada extrem a HTTPS, manteniu activa la validació del nom d'amfitrió i del certificat, i suprimiu el recurs alternatiu amb HTTP simple en lloc de deixar-lo a un senyal de configuració de distància. Una redirecció no ajuda aquí: una petició HTTP que rep un 301 ja ha enviat les capçaleres i el cos en clar, així que les credencials no han de viatjar mai amb la suposició que la redirecció les protegirà.

A Android 7.0 i posteriors, Network Security Configuration expressa la política. El fitxer de sota és la versió útil més petita: rebutja el text en clar a tot arreu tret que una excepció específica de domini digui el contrari.

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

Referencieu aquest recurs des del manifest i després llegiu les excepcions que ja existeixen abans de distribuir. Un domini de depuració antic o una entrada d'un SDK de proveïdor de pagaments poden tornar a permetre en silenci el text en clar per a l'amfitrió que intentàveu protegir.

Dos detalls de versió val la pena conèixer. Les aplicacions dirigides a l'API 28 o posterior ja rebutgen el text en clar per defecte, així que una aplicació que encara parla HTTP simple o bé apunta a un nivell d'API més antic o bé té una excepció en algun lloc. I quan hi ha una configuració de seguretat de xarxa, l'atribut de manifest més antic android:usesCleartextTraffic ja no decideix la qüestió, i per això de vegades sembla que canviar aquest senyal no fa res.

Camí dos: l'aplicació que no controleu

Per a una aplicació de tercers instal·lada, no podeu reescriure'n la configuració de seguretat amb un paràmetre d'usuari. Les opcions realistes són els controls de connexió segura del propi producte, una alternativa mantinguda que ja faci servir TLS, o una política de dispositiu gestionat que limiti què pot executar el dispositiu. Són compromisos diferents, i només el tercer s'escala a un parc de dispositius.

Les regles de xarxa són substituts més febles del que semblen. Permetre només el port 443 no imposa TLS autenticat, perquè molts protocols de text en clar es poden traslladar a aquell port, i bloquejar el port 80 no cobreix el text en clar en altres ports. El mode només HTTPS d'un navegador també es limita a aquell navegador, no a una aplicació de correu o xat separada al mateix telèfon.

Instal·lar un certificat d'intercepció perquè el trànsit sembli xifrat és un canvi de confiança, no una correcció. Substitueix l'autenticació del servidor de l'aplicació per la vostra, i una aplicació que no validava certificats des del principi no es repara amb això; només heu canviat qui pot llegir el flux.

On ajuda una VPN i on no

Un túnel és l'eina correcta quan el requisit és que la xarxa local no aprengui res de la connexió, o que l'aplicació arribi a un servei privat al qual d'altra manera no pot arribar. És l'eina equivocada per fer que un client HTTP parli HTTPS, perquè la petició surt del túnel exactament tal com hi va entrar.

Android afegeix una restricció pràctica: la plataforma executa un sol servei de VPN alhora. Una aplicació de filtratge local que ocupa aquest lloc competeix amb el túnel remot que realment necessiteu, i canviar entre tots dos és una operació a nivell de dispositiu i no d'aplicació. Aquest únic lloc és una bona raó per posar la política de càrrega a l'aplicació i reservar el túnel per al camí.

L'únic cas en què les dues coses se superposen és un servidor privat que també opere. Allà un túnel pot fer privat el camí encara que el protocol sigui encara text en clar, cosa que redueix l'exposició però no canvia què és la càrrega. Tracteu-ho com a reducció de risc, no com a xifratge de les dades.

Què cal provar abans de donar-ho per bloquejat

Comenceu pel valor per defecte que sorprèn la gent: una aplicació dirigida a l'API 28 o posterior ja hauria de rebutjar el text en clar, així que comproveu el nivell objectiu abans d'afegir configuració que duplica un valor per defecte. Després proveu el cas de fallada deliberadament: una petició a un amfitrió HTTP simple ha de fallar, no tenir èxit en silenci mitjançant el recurs alternatiu.

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

Per al cas d'èxit, confirmeu que la crida HTTPS valida una cadena de certificats real i que un proxy amb un certificat no fiable es rebutja en lloc de tolerar-se. Un intercanvi que té èxit contra qualsevol certificat no ha demostrat res sobre la seguretat del transport.

Per a una aplicació de tercers, anoteu el límit que realment podeu imposar, sigui una política de dispositiu gestionat, una regla de xarxa o res, i digueu-ho als criteris d'acceptació. La guia de configuració de seguretat d'Android llista els valors per defecte de la plataforma i quins components respecten la política, que és la part que decideix si la vostra configuració fa alguna cosa.