ECH attivato, ma SNI è comunque visibile: come controllare nel 2026

ECH — la crittografia del nome del sito nel handshake TLS — ha ricevuto lo status di standard a marzo 2026 (RFC 9849, Standards Track). Firefox e Chrome lo includono di default, Cloudflare distribuisce le chiavi a quasi tutti i suoi clienti. Tuttavia, per la maggior parte degli utenti ECH non funziona silenziosamente: il browser passa a un handshake normale e il provider vede ancora dove stai andando.

Di seguito, come controllare in un minuto se il SNI è crittografato per te, perché spesso non lo è e in quali scenari ECH è fondamentalmente inutile (spoiler: per l'anti-detect e il parsing — quasi sempre).

Cosa nasconde ECH — e cosa non nasconde

Nel normale TLS 1.3 tutto è crittografato, tranne il primo messaggio — ClientHello. In esso, il campo SNI con il dominio a cui ti connetti è in chiaro. È proprio grazie al SNI che funzionano la maggior parte dei sistemi di filtraggio: l'IP è uno per migliaia di siti dietro un CDN, mentre il dominio è visibile.

ECH suddivide ClientHello in due parti:

ClientHelloOuter — viene inviato in chiaro, ma con un dominio di copertura. Per Cloudflare è cloudflare-ech.com.
ClientHelloInner — il vero dominio, ALPN e lista di cifrari, crittografati con la chiave pubblica del server.

La chiave per questa crittografia il browser la prende non dalla connessione, ma dal DNS — dal record HTTPS (tipo 65), parametro ech=. Da qui deriva la principale conseguenza, che spesso viene dimenticata: ECH non è possibile senza DNS crittografato. Se la richiesta DNS viene inviata in chiaro su UDP/53, l'osservatore vede semplicemente il nome del dominio prima ancora dell'handshake, e il resolver filtrante può rimuovere il parametro ech= dalla risposta — e ECH non si attiverà.

Cosa non nasconde affatto ECH:

Indirizzo IP di destinazione — visibile sempre;
volume e tempistiche del traffico;
impronta TLS del client (JA3/JA4) — il set di cifrari e le estensioni rimangono nella parte aperta;
tu per il sito stesso — il server, dopo la decrittazione, vede tutto ciò che vedeva prima.

L'ultimo punto è il motivo per cui ECH non ha nulla a che fare con l'aggiramento dei sistemi anti-bot. Cloudflare, DataDome e Akamai operano dal lato server: non gli importa se il SNI è stato crittografato durante il percorso. Se l'obiettivo è non farsi scoprire durante l'automazione, funziona un livello completamente diverso: la sostituzione dell'impronta TLS stessa, di cui abbiamo parlato nel materiale su come aggirare l'impronta JA4 tramite curl-cffi.

Controllo n. 1: ECH funziona adesso (10 secondi)

Apri nel browser:

https://crypto.cloudflare.com/cdn-cgi/trace

Cerca la riga sni=. Sono possibili due varianti:

sni=encrypted — ECH funziona, il nome del sito è nascosto durante il percorso;
sni=plaintext — ECH non si è applicato, il dominio è stato inviato in chiaro.

Lo stesso indirizzo tramite curl nel terminale restituirà sempre sni=plaintext — il normale curl non supporta ECH, e questo è un utile riferimento: così appare "disattivato".

Controllo n. 2: il dominio ha una chiave ECH (dig, senza browser)

ECH si attiverà solo se il dominio ha un record DNS HTTPS con il parametro ech=. Controlliamo il record grezzo:

dig +short TYPE65 example.com @1.1.1.1

Nella risposta cerca i byte FE0D — questo è il codice di estensione ECH, seguito da ECHConfig. Esempio pratico: al momento della preparazione del materiale, sia crypto.cloudflare.com che il nostro dominio proxycove.com hanno un record lungo 133–136 byte che contiene sia FE0D che il nome di copertura cloudflare-ech.com in formato esadecimale. Mentre cloudflare.com ha un record corto, di 61 byte: solo ALPN e suggerimenti IP, senza ECH. Ciò significa che anche all'interno dell'infrastruttura Cloudflare, ECH non viene distribuito a tutti i domini indiscriminatamente — non sorprenderti se un sito specifico non lo ha.

Se dig restituisce un errore ignoring invalid type HTTPS — hai una versione obsoleta dell'utilità, usa la forma numerica TYPE65, come nel comando sopra.

Perché ECH non si attiva per te: cinque motivi in ordine

DNS crittografato disattivato. Senza DoH, il browser non riceverà ECHConfig in modo affidabile. In Firefox: Impostazioni → Privacy → DNS tramite HTTPS in modalità "Elevata" o "Massima protezione". In Chrome: Impostazioni → Sicurezza → Usa DNS sicuro.
Il dominio semplicemente non ha un record HTTPS con ech= — controllato con il comando del blocco sopra. Qui non dipende da te, è una decisione del proprietario del sito e del suo CDN.
Il resolver rimuove il parametro. I server DNS aziendali e dei provider sono soliti restituire record HTTPS senza ech=. Controlla richiedendo direttamente il record a un resolver pubblico (@1.1.1.1) e confrontando con la risposta del sistema.
Le flag del browser sono state ripristinate. In Firefox, controlla network.dns.echconfig.enabled e network.dns.http3_echconfig.enabled in about:config — entrambi devono essere true.
Un gateway ispezionante è in mezzo. Di questo si parlerà nel prossimo paragrafo.

Come ECH viene compromesso: due schemi diversi

Firewall aziendale: abbassamento silenzioso

I fornitori di apparecchiature di rete hanno rilasciato ricette pronte contro ECH — non sono disposti a perdere visibilità sul traffico. Cisco, ad esempio, già dalla base applicativa VDB 416 (ottobre 2025) identifica "ECH Servers" come un'applicazione separata e propone due approcci: intercettare la connessione ricreando il certificato e rimuovere l'estensione encrypted_client_hello da ClientHello, oppure agire più semplicemente — a livello DNS: bloccare i record HTTPS per i domini ECH, tagliare DoH/DoT/DoQ, bloccare il dominio canarino use-application-dns.net e consentire DNS solo su server aziendali.

La furbizia del primo schema è che non appare come un blocco. Il server, non vedendo l'estensione ECH, risponde normalmente, il client considera ECH "disattivato in sicurezza" e si riconnette già con un SNI aperto. Il sito si è aperto, non ci sono errori — e il nome del dominio è finito nel log del gateway.

Livello statale: la connessione semplicemente muore

Un esempio russo è indicativo per la sua precisione. Dal 5 novembre 2024, il filtraggio scatta solo quando coincidono due segni contemporaneamente: SNI con valore cloudflare-ech.com più la presenza dell'estensione ECH. Separatamente, né l'uno né l'altro causano un blocco — ECH passa ad altri domini di copertura (ad esempio, i test defo.ie o tls-ech.dev). Questo è implementato non con un reset della connessione, ma con un silenzioso scarto dei pacchetti: la pagina si blocca e si disconnette per timeout. Sono coinvolti sia HTTP/2 basato su TCP che QUIC/HTTP-3. Il Roskomnadzor ha dichiarato esplicitamente che l'uso di TLS ECH viola la legislazione russa e ha raccomandato ai proprietari di siti di allontanarsi da CDN Cloudflare — migliaia di risorse perfettamente legali sono state colpite dal filtro, incluse in un'unica copertura.

In una situazione del genere, Firefox riprova circa un minuto dopo senza ECH — quindi alla fine restituisce un SNI aperto, cosa che la specifica non raccomanda di fare proprio per motivi di sicurezza. Se noti "il sito si carica esattamente per un minuto, poi si apre" — è quasi sicuramente questo.

Quando ECH non è sufficiente e cosa mettere al suo posto

Analizziamo le attività onestamente.

Privacy dal provider su internet domestico. ECH + DoH è un buon miglioramento gratuito. Funziona dove non viene tagliato.
Superamento della filtrazione. ECH non è stato progettato per questo, e la pratica lo ha confermato: non appena ha iniziato a interferire con i filtri, hanno imparato a identificarlo e silenziarlo completamente. Non ci si può fare affidamento come strumento di accesso.
Parsing, multi-accounting, automazione. ECH non offre nulla: il sito target vede il tuo IP, il tuo JA4 e la tua storia delle richieste. Solo la fonte IP e la qualità dell'impronta hanno importanza.

In tutti i casi in cui ECH non riesce, funziona uno strato più grezzo ma affidabile: portare l'handshake TLS al di fuori della rete osservabile. Quando il traffico passa attraverso un proxy, l'osservatore sul tuo canale vede solo la connessione con il nodo proxy — non c'è alcun SNI del sito target in esso, indipendentemente dal fatto che il dominio supporti ECH o meno. Per l'accesso quotidiano e il lavoro con servizi sensibili alla reputazione dell'IP, sono adatti proxy residenziali; per applicazioni mobili e piattaforme che sono particolarmente esigenti sul tipo di connessione, — proxy mobili.

E non dimenticare il DNS: un proxy nel browser non garantisce che i nomi vengano risolti attraverso di esso. Una fuga DNS rivela esattamente ciò che stavi cercando di nascondere — come controllarlo, lo abbiamo trattato in un'istruzione separata su come controllare un proxy per perdite DNS. Se invece la questione riguarda un'analisi approfondita del traffico sul canale, bisogna guardare non a ECH, ma al trasporto stesso.

Breve checklist

Aprire crypto.cloudflare.com/cdn-cgi/trace e controllare la riga sni=.
Se plaintext — attivare DoH nel browser e controllare di nuovo.
Non ha funzionato — controllare la presenza della chiave nel dominio: dig +short TYPE65 dominio @1.1.1.1, cercare FE0D.
La chiave è presente, ma ECH non si applica — confrontare la risposta dei resolver pubblici e di sistema: probabilmente il parametro viene rimosso lungo il percorso.
La connessione si blocca per un minuto e si apre — ECH è silenziato a livello di rete; ECH qui non aiuterà, serve un altro trasporto.

Conclusione

ECH è l'ultima falla chiusa con attenzione nella privacy di TLS, e non uno strumento di accesso e tanto meno uno strumento per l'automazione. Dipende dal DNS crittografato, si disattiva nel mezzo senza alcun errore sullo schermo e viene silenziato completamente dove inizia a interferire. Vale la pena controllarlo — i due comandi sopra richiedono un minuto. Ma basare su di esso l'aggiramento dei blocchi o la protezione dai sistemi anti-bot è inutile: queste attività vengono risolte a livello di chi vede l'IP e l'impronta TLS dall'altra parte.