# L'Encrypted Client Hello di TLS diventa standard (RFC 9849)
Table of Contents
Per anni chi osserva il traffico di rete ha potuto leggere un dettaglio che molti credevano già protetto: il nome del sito verso cui ci si sta collegando. La connessione era cifrata, il lucchetto nel browser chiuso, eppure quell’informazione viaggiava in chiaro. A marzo 2026 la IETF, l’organismo che scrive gli standard di Internet, ha pubblicato la RFC 9849, intitolata “TLS Encrypted Client Hello”. Il documento chiude proprio quella falla. Vale la pena capire cosa nasconde davvero e perché riguarda chi progetta reverse proxy, CDN e sistemi di filtraggio.
Il dettaglio che restava scoperto
Quando un browser apre una connessione sicura verso un sito, i due lati si scambiano prima alcuni messaggi per accordarsi su chiavi e parametri. Questa fase si chiama handshake. Con la versione più recente del protocollo, TLS 1.3, quasi tutto l’handshake è cifrato: un osservatore esterno vede passare byte incomprensibili.
Resta però un’eccezione importante. Nel primissimo messaggio, il ClientHello, il browser deve dire a quale sito vuole collegarsi. Serve perché su un singolo indirizzo IP possono vivere centinaia di siti diversi, e il server deve sapere quale certificato presentare. Questa indicazione si chiama SNI, cioè Server Name Indication, e finora viaggiava in chiaro. In pratica, chiunque si trovi lungo il percorso della connessione (il gestore della rete, un provider, un firewall aziendale) poteva leggere esempio.it anche senza vedere nulla del contenuto. Come spiega la stessa RFC, l’SNI in chiaro è forse l’informazione più sensibile rimasta scoperta in TLS 1.3.
Cos’è l’Encrypted Client Hello
L’Encrypted Client Hello, abbreviato in ECH, è un’estensione di TLS 1.3 che cifra il ClientHello, e con esso l’SNI. Non solo il nome del sito: protegge anche altri campi che potrebbero far intuire la destinazione, come l’elenco dei protocolli applicativi che il client è disposto a usare (l’estensione ALPN).
L’idea non è nuova. Nasce da anni di lavoro su una proposta chiamata ESNI, che cifrava soltanto il nome del sito. Con il tempo ci si è accorti che nascondere un solo campo non bastava: altri dettagli del ClientHello potevano tradire la destinazione. La proposta è stata quindi riprogettata per cifrare l’intero messaggio, ed è questa la versione arrivata a standard con la RFC 9849. Il documento ha lo stato di Proposed Standard, il primo gradino della via ufficiale agli standard IETF: è stabile e pubblicato, non è più una bozza.
Come funziona, senza tecnicismi
Il meccanismo si basa su due ClientHello annidati. Ce n’è uno “interno”, quello vero, che contiene l’SNI reale e viene cifrato. E ce n’è uno “esterno”, visibile, che contiene un nome pubblico e innocuo, condiviso da molti siti ospitati dallo stesso operatore.
Chi guarda dall’esterno vede solo il nome pubblico. Il server che riceve la connessione, chiamato client-facing server, decifra il ClientHello interno e capisce quale sito è stato davvero richiesto, poi instrada la connessione di conseguenza. Se molti siti condividono lo stesso nome pubblico, per un osservatore diventano indistinguibili: è quello che la specifica chiama insieme di anonimato.
Per cifrare il ClientHello interno serve la chiave pubblica del server. Il client la ottiene tramite il DNS, il sistema che traduce i nomi in indirizzi. Un secondo documento pubblicato insieme al primo, la RFC 9848, definisce come pubblicare questa configurazione (l’ECHConfig) nei record DNS di tipo SVCB e HTTPS, tramite un parametro dedicato chiamato ech. La cifratura vera e propria usa HPKE, uno schema crittografico standard pensato proprio per cifrare dati verso una chiave pubblica.
Sono previsti anche i casi in cui qualcosa non torna. Se il server non riesce a decifrare, ad esempio perché il client ha usato una configurazione ormai vecchia, può rispondere con quella aggiornata e la connessione viene ritentata. E c’è un accorgimento chiamato GREASE: i client possono inviare dati ECH finti anche quando non li usano davvero, così chi adotta ECH non si distingue dagli altri e gli apparati di rete non si “abituano” ad aspettarsi un formato fisso.
Cosa cambia per reverse proxy, CDN e filtri
Qui sta la parte pratica, quella che tocca chi gestisce infrastrutture.
Molti reverse proxy instradano le connessioni leggendo l’SNI senza nemmeno decifrare il traffico: guardano il nome, scelgono il backend giusto e passano oltre. Con ECH questo non funziona più, perché l’SNI visibile è il nome pubblico condiviso. Per smistare in base al sito reale, il server esposto deve diventare a tutti gli effetti il client-facing server: decifrare l’ECH e leggere l’SNI interno. Chi ha costruito lo smistamento sul solo SNI in chiaro dovrà rivedere l’architettura.
Per le CDN il modello calza bene. Una CDN ospita già molti clienti dietro gli stessi indirizzi: può presentare un nome pubblico comune, fare da client-facing server e instradare verso il sito corretto dopo aver decifrato l’ECH. È anche il contesto in cui l’insieme di anonimato è più ampio, e quindi la protezione più efficace.
Discorso diverso per i filtri basati su SNI. Firewall, sistemi di controllo parentale, filtri aziendali e strumenti di blocco a livello di rete spesso decidono cosa passare leggendo proprio il nome del sito nell’SNI. Con ECH quel nome non è più visibile: un filtro che si basa solo sull’SNI perde il suo appiglio. È il rovescio della medaglia della privacy, ed è bene saperlo per tempo, senza illudersi che nulla cambi.
A che punto siamo
ECH è uno standard pubblicato, ma il suo effetto dipende da quanto viene adottato dalle due parti. Sul fronte client, alcuni browser hanno già sperimentato ECH da tempo. Sul fronte server, diverse CDN lo offrono e le librerie crittografiche stanno aggiungendo il supporto: pochi giorni dopo la pubblicazione, il progetto OpenSSL ha annunciato il supporto a ECH così come descritto dalla RFC 9849.
Restano alcuni prerequisiti da tenere a mente. ECH richiede TLS 1.3, quindi le connessioni che si fermano a versioni precedenti restano scoperte. E dipende dal DNS per recuperare la configurazione: se le richieste DNS viaggiano in chiaro, un osservatore può comunque intuire la destinazione o manomettere la configurazione. Per questo ECH ha senso soprattutto insieme a un DNS cifrato, come DNS over HTTPS o DNS over TLS.
In sintesi, la RFC 9849 mette al riparo l’ultimo pezzo di handshake che restava leggibile. Non è una rivoluzione improvvisa: è un tassello che diventa ufficiale dopo anni di prove sul campo, e che nei prossimi mesi cambierà silenziosamente il modo in cui reverse proxy, CDN e filtri di rete vedono, o non vedono più, il nome dei siti.
