Android 17 cifra il Client Hello: ECH nasconde i domini agli osservatori di rete

🛡️ Executive Summary

• Encrypted Client Hello cifra SNI e altri dati iniziali di TLS, rendendo più difficile identificare il dominio contattato da un’app.
• ECH funziona soltanto quando applicazione, libreria di rete e server remoto supportano il protocollo e rendono disponibile una configurazione valida.
• La protezione non nasconde indirizzo IP, DNS non cifrato o caratteristiche del traffico e non sostituisce VPN, proxy o reti anonime.

Android 17 introduce il supporto di piattaforma a Encrypted Client Hello, estensione di TLS 1.3 progettata per cifrare la parte più sensibile del messaggio iniziale inviato durante una connessione sicura. ECH protegge soprattutto il Server Name Indication, il campo che comunica al server quale dominio vuole raggiungere il client e che, nelle connessioni tradizionali, resta leggibile agli osservatori di rete nonostante HTTPS. Operatori, amministratori Wi-Fi, sistemi di filtraggio e soggetti collocati lungo il percorso possono quindi avere più difficoltà nel ricostruire i servizi contattati. Il miglioramento non equivale però all’anonimato: disponibilità e copertura dipendono dall’intera catena composta da app, libreria, DNS e server.

ECH chiude una delle esposizioni rimaste nella connessione TLS

HTTPS cifra contenuti, credenziali, cookie e percorsi richiesti dopo l’avvio della sessione, ma il ClientHello ha storicamente lasciato visibili diversi metadati necessari a negoziare la connessione. Il più rivelatore è SNI, usato dai server che ospitano numerosi siti sullo stesso indirizzo IP per selezionare certificato e configurazione corretti. La RFC 9849 pubblicata dall’IETF definisce ECH come un meccanismo che crea un ClientHello interno cifrato, contenente il vero nome del servizio e altri parametri sensibili, affiancato da un messaggio esterno con informazioni meno specifiche. Più servizi ospitati dietro una configurazione pubblica coerente formano così un insieme nel quale diventa più difficile distinguere il dominio effettivamente richiesto. Android 17 porta questa capacità nello stack della piattaforma e riduce una perdita informativa che HTTPS, da solo, non aveva eliminato.

Leggi anche: come OpenSSL 4.0 ha introdotto Encrypted Client Hello nello stack TLS

Il supporto di Android 17 non attiva ECH in ogni applicazione

La protezione entra nel comportamento predefinito delle app che impostano Android 17, API level 37, come target, ma non opera automaticamente su qualsiasi traffico generato dal dispositivo. La documentazione ufficiale sulle modifiche di Android 17 specifica tre condizioni: la libreria di rete deve integrare le API ECH, il server remoto deve supportare il protocollo e deve essere disponibile una configurazione utilizzabile per cifrare il ClientHello. Google cita HttpEngine, WebView e OkHttp tra gli stack destinati a integrare il meccanismo. La piattaforma aggiunge inoltre a DnsResolver la capacità di interrogare i record DNS HTTPS contenenti le configurazioni ECH e mette a disposizione di SSLEngine e SSLSocket, attraverso Conscrypt, i metodi necessari a completare la negoziazione. Il risultato riguarda quindi browser integrati e comunicazioni delle app, non soltanto Chrome o la navigazione tradizionale.

Gli sviluppatori possono applicare ECH globalmente o per dominio

Android 17 amplia la Network Security Configuration con l’elemento <domainEncryption>, utilizzabile dentro <base-config> o <domain-config>. La guida tecnica di Google all’adozione di ECH consente di impostare il comportamento globalmente o per singolo dominio attraverso le modalità enabled e disabled. Per le app destinate ad API 37 la modalità predefinita è abilitata: quando il client riceve una configurazione ECH valida, tenta la connessione cifrata; quando la configurazione non è disponibile, invia ECH GREASE, un’estensione con contenuto casuale progettata per evitare che apparati intermedi e implementazioni obsolete imparino a bloccare il nuovo campo. GREASE migliora la compatibilità futura, ma non sostituisce una vera negoziazione ECH e non garantisce da solo che il nome del dominio resti nascosto. L’eventuale disattivazione dovrebbe quindi essere limitata agli endpoint realmente incompatibili.

ECH protegge il dominio ma non rende anonima la navigazione

Il salto di privacy è concreto, ma circoscritto. ECH impedisce a un osservatore sul percorso di leggere direttamente SNI e altri elementi del ClientHello interno, ma non nasconde l’indirizzo IP del server, la quantità di dati scambiati, gli orari delle connessioni o i pattern prodotti dalle applicazioni. Se la risoluzione DNS avviene in chiaro, il nome richiesto può inoltre essere osservato prima ancora dell’handshake TLS; per questo ECH offre una protezione più completa quando lavora insieme a DNS-over-HTTPS o DNS-over-TLS. Anche il server di destinazione continua necessariamente a conoscere il servizio richiesto, mentre app, browser, provider DNS e piattaforme possono conservare telemetria secondo le rispettive politiche. ECH non sostituisce quindi Tor, una VPN o un proxy affidabile e non impedisce ogni forma di fingerprinting. Si inserisce però nel percorso con cui Android 17 riduce progressivamente l’accesso indiscriminato a dati e risorse.

Filtri aziendali e ispezione TLS devono adattarsi al nuovo handshake

La cifratura del nome del servizio limita i sistemi che classificano o bloccano le connessioni osservando soltanto SNI. Proxy trasparenti, parental control, captive portal e appliance aziendali non aggiornate possono quindi incontrare incompatibilità, tentare downgrade o interrompere il traffico. Android offre agli sviluppatori la disattivazione per dominio proprio per gestire endpoint legacy, ma un opt-out generale riporterebbe visibile il metadato che ECH intende proteggere. Le imprese che svolgono ispezione TLS attraverso dispositivi amministrati dovranno verificare stack, certificati, resolver e policy di rete, privilegiando strumenti consapevoli del protocollo rispetto ai blocchi indiscriminati. Lo stesso cambiamento riduce l’efficacia della censura basata unicamente sul nome SNI, senza impedire blocchi per indirizzo IP o analisi statistica. L’impatto dipenderà quindi dalla diffusione del supporto sui server e nelle librerie più utilizzate, non dalla sola presenza di Android 17 sul telefono.

Continua con:

• Android 17 introduce nuove difese e prepara la crittografia post-quantistica
• Pixel 11 e Android 17 completano il nuovo ecosistema mobile di Google

La privacy di rete diventa una proprietà della piattaforma

Con ECH, Android 17 trasferisce una protezione finora dipendente soprattutto dai singoli browser al livello delle API di sistema disponibili alle applicazioni. La scelta non elimina tracciamento e sorveglianza, ma rende meno immediata una delle osservazioni passive più semplici: leggere il dominio direttamente dall’avvio di una sessione TLS. L’efficacia crescerà con l’adozione da parte di WebView, OkHttp, HttpEngine, provider DNS e infrastrutture server, mentre configurazioni incomplete continueranno a produrre connessioni prive della stessa riservatezza. Per sviluppatori e amministratori il passaggio richiede test di compatibilità e rinuncia agli opt-out generalizzati. Per gli utenti rappresenta invece un miglioramento silenzioso: nessuna nuova interfaccia da imparare, ma meno metadati esposti sulle reti mobili, aziendali e Wi-Fi attraversate ogni giorno.