Blocca il testo in chiaro nelle app Android senza dipendere da una VPN

Due cose molto diverse vengono chiamate bloccare il testo in chiaro su Android. Una è una policy interna all'app che ordina al suo stesso stack di rete di rifiutare HTTP semplice. L'altra è un assetto a livello di dispositivo che cerca di proteggere tutto sul telefono insieme, di solito instradando il traffico attraverso una VPN. Risolvono problemi diversi, e la seconda non può correggere la prima: un tunnel protegge il tratto tra telefono e uscita, mentre un'app che parla HTTP continua a parlare HTTP con tutto ciò che sta oltre quell'uscita.

Due problemi con un solo nome

Il primo problema è il payload: l'app scrive credenziali o token in una richiesta non cifrata end to end, così ogni salto che può vederla può leggerla. Il secondo è il percorso: l'app può essere perfettamente corretta e tu vuoi comunque che l'operatore Wi-Fi locale non impari nulla su dove si connette. Una VPN affronta il secondo e solo il secondo.

Questa distinzione decide a chi appartiene la correzione. Il payload appartiene a chi distribuisce l'app, perché solo quel codice decide quale URL viene chiamato e se un certificato viene validato. Il percorso appartiene al dispositivo o alla rete, perché riguarda dove viaggiano i pacchetti, non cosa contengono.

Percorso uno: l'app che controlli

Se distribuisci l'app, la correzione è una decisione di trasporto più una policy che la impone. Punta ogni endpoint su HTTPS, lascia attiva la validazione di hostname e certificato, ed elimina il fallback in HTTP semplice invece di lasciarlo a un flag di configurazione di distanza. Un redirect non aiuta qui: una richiesta HTTP che riceve un 301 ha già inviato header e corpo in chiaro, quindi le credenziali non devono mai viaggiare supponendo che il redirect le protegga.

Da Android 7.0 in poi, Network Security Configuration esprime la policy. Il file qui sotto è la versione utile più piccola: rifiuta il testo in chiaro ovunque salvo che un'eccezione specifica di dominio dica il contrario.

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

Fai riferimento a quella risorsa dal manifest, poi leggi le eccezioni già esistenti prima di distribuire. Un vecchio dominio di debug o una voce dell'SDK di un fornitore di pagamenti possono silenziosamente ripermettere il testo in chiaro per l'host che cercavi di proteggere.

Due dettagli di versione vale la pena conoscere. Le app che mirano all'API 28 o superiore rifiutano già il testo in chiaro per impostazione predefinita, quindi un'app che parla ancora HTTP semplice o mira a un livello API più vecchio o ha un'eccezione da qualche parte. E quando è presente una configurazione di sicurezza di rete, l'attributo manifest più vecchio android:usesCleartextTraffic non decide più la questione, ed è per questo che a volte cambiare quel flag sembra non fare nulla.

Percorso due: l'app che non controlli

Per un'app di terze parti installata non puoi riscrivere la sua configurazione di sicurezza con un'impostazione utente. Le opzioni realistiche sono i controlli di connessione sicura del prodotto stesso, un'alternativa mantenuta che usa già TLS, o una policy di dispositivo gestito che limita ciò che il dispositivo può eseguire. Sono impegni diversi, e solo il terzo scala su un parco dispositivi.

Le regole di rete sono sostituti più deboli di quanto sembrino. Consentire solo la porta 443 non impone TLS autenticato, perché molti protocolli in testo chiaro possono essere spostati su quella porta, e bloccare la porta 80 non copre il testo in chiaro su altre porte. Anche la modalità solo HTTPS di un browser è limitata a quel browser, non a un'app di posta o chat separata sullo stesso telefono.

Installare un certificato di intercettazione per far sembrare cifrato il traffico è un cambio di fiducia, non una correzione. Sostituisce l'autenticazione del server dell'app con la tua, e un'app che non validava i certificati fin dall'inizio non viene riparata da questo; hai solo spostato chi può leggere il flusso.

Dove una VPN aiuta e dove no

Un tunnel è lo strumento giusto quando il requisito è che la rete locale non impari nulla della connessione, o che l'app raggiunga un servizio privato che altrimenti non raggiunge. È lo strumento sbagliato per far parlare HTTPS a un client HTTP, perché la richiesta lascia il tunnel esattamente come vi è entrata.

Android aggiunge un vincolo pratico: la piattaforma esegue un solo servizio VPN alla volta. Un'app di filtraggio locale che occupa quel posto compete con il tunnel remoto che ti serve davvero, e passare dall'uno all'altro è un'operazione a livello di dispositivo, non di app. Quell'unico posto è una buona ragione per tenere la policy del payload nell'app e riservare il tunnel al percorso.

L'unico caso in cui i due si sovrappongono è un server privato che gestisci anche tu. Lì un tunnel può rendere privato il percorso anche se il protocollo è ancora testo in chiaro, il che riduce l'esposizione ma non cambia cos'è il payload. Trattalo come riduzione del rischio, non come cifratura dei dati.

Cosa testare prima di dichiararlo bloccato

Parti dal default che sorprende: un'app che mira all'API 28 o superiore dovrebbe già rifiutare il testo in chiaro, quindi controlla il livello target prima di aggiungere una configurazione che duplica un default. Poi prova deliberatamente il caso di errore: una richiesta verso un host HTTP semplice deve fallire, non riuscire silenziosamente tramite un fallback.

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

Per il caso di successo, conferma che la chiamata HTTPS validi una catena di certificati reale e che un proxy con certificato non attendibile venga rifiutato anziché tollerato. Una stretta di mano che riesce contro qualsiasi certificato non ha dimostrato nulla sulla sicurezza del trasporto.

Per un'app di terze parti, annota il limite che puoi davvero imporre, che sia una policy di dispositivo gestito, una regola di rete o nulla, e dillo nei criteri di accettazione. La guida alla configurazione di sicurezza di Android elenca i default della piattaforma e quali componenti rispettano la policy, ed è la parte che decide se la tua configurazione fa qualcosa.