ECH e blocchi SNI nel 2026: guida completa alla configurazione e al bypass del DPI

Introduzione

La crittografia a livello di trasporto è ormai uno standard consolidato, ma fino a poco tempo fa uno dei metadati più importanti rimaneva visibile al provider e ai sistemi di ispezione approfondita dei pacchetti (DPI). Parliamo di SNI, il nome di dominio in chiaro all’interno della stretta di mano TLS. Nel 2026, il ruolo dominante nella protezione contro i blocchi SNI è svolto da ECH, il meccanismo di cifratura del ClientHello. Questo complica drasticamente la censura basata sul nome di dominio e cambia le pratiche di configurazione dell'infrastruttura. In questa guida vedremo perché ECH è importante, come funziona, dove inserirlo, quali errori compromettono la disponibilità e quali soluzioni alternative usare laddove ECH non è ancora adottato. Percorreremo insieme il percorso dalle basi alle strategie avanzate contro il DPI, fornendo istruzioni passo passo e checklist operative.

Basi

Cos’è l’SNI e perché viene bloccato

L’SNI è un’estensione TLS che permette al client di indicare il nome host per ricevere il certificato corretto dal server. Il problema è che l’SNI viene inviato nel primo messaggio della stretta di mano in chiaro, fino all’introduzione di ECH. I DPI e i filtri dei provider analizzano proprio questa parte del traffico e mettono in atto blocchi indirizzati per dominio o filtri comportamentali sui pattern della stretta di mano. La semplicità di implementazione e l’elevata precisione hanno fatto dell’SNI uno dei segnali preferiti per la censura.

Cos’è ECH

ECH (Encrypted Client Hello) è uno standard della famiglia TLS 1.3 che sposta i campi sensibili del ClientHello, inclusi SNI, in una sezione cifrata. Il client invia due ClientHello: uno esterno e uno interno. Quello esterno contiene un nome pubblico neutro e un set di parametri della configurazione ECH del server. Quello interno include il vero SNI e parametri di sessione, cifrati con HPKE usando la chiave pubblica dalla configurazione ECH, che il client ha ottenuto anticipatamente via DNS, tramite resource record HTTPS RR o SVCB.

DNS HTTPS RR e SVCB

Per cifrare il ClientHello interno il client deve conoscere i parametri pubblici di ECH. Questi sono pubblicati in record DNS di tipo HTTPS o SVCB. Il record specifica indirizzi, porte, ALPN e il campo dei parametri ECH codificati in base64. Client che usano resolver protetti DoH o DoT ricevono questi parametri e possono costruire il pacchetto ECH. Senza DNS protetto la configurazione può essere intercettata o manomessa, quindi è raccomandato sempre risolvere tramite DoH o DoT.

Come il DPI reagisce a ECH

Con l’adozione di ECH, l’SNI sparisce dalla parte visibile della stretta di mano. Restano visibili IP server, porta, protocollo TCP o QUIC, lunghezza dei pacchetti, temporizzazioni, alcuni marker del ClientHello esterno e il nome pubblico. Il DPI si sposta verso analisi comportamentali e statistiche, fingerprint JA3 e JA4, analisi del QUIC Initial e segnali aggregati di routing. I blocchi diventano più costosi e rudimentali, spesso colpendo anche traffico legittimo.

Approfondimento

Architettura di ECH

Alla base di ECH c’è HPKE, una crittografia ibrida che usa KEM, KDF e AEAD. Il server pubblica una lista di configurazioni con parametri KEM, KDF, AEAD e chiave. Il client sceglie la configurazione adatta, cifra il ClientHello interno e invia la stretta di mano esterna. Il server tenta di decifrare basandosi sul nome pubblico e sulle policy ECH supportate. Se ha successo, prosegue come di consueto; altrimenti, ritorna un rifiuto implicito oppure un segnale che consente al client di tentare una strategia fallback, se consentita dalla policy.

Fallback e sicurezza

Gestire il fallback è cruciale. Se il client, dopo un fallimento di ECH, invia nuovamente SNI in chiaro, il DPI ottiene esattamente ciò che vuole. Nei moderni stack si impone l’obbligo di ECH per il dominio e si vieta il ritorno alla stretta di mano aperta. Questo si realizza con configurazioni appropriate di browser e server. Si impiega inoltre GREASE per ECH, per introdurre marker pseudo-casuali che evitano problemi alla stretta di mano causati da formati insoliti.

QUIC e HTTP3

Con la crescita di QUIC e HTTP3, ECH diventa parte naturale della prima datagramma. Il QUIC Initial resta visibile ma contiene solo metadati pubblici e non svela l’SNI reale se ECH è abilitato. Il DPI si concentra su IP, comportamento e statistiche. Gli operatori rispondono spostando i servizi su anycast, usando nomi pubblici di uso comune e combinando tattiche di traffic engineering.

JA3, JA4 e fingerprint

ECH non nasconde i fingerprint comportamentali. L’insieme di estensioni, l’ordine dei campi, suite crittografiche supportate e ALPN formano l’impronta del client. Il DPI può usarla per mirare implementazioni specifiche. Perciò si consiglia di uniformare i fingerprint ai browser più diffusi e aggiornare le librerie TLS per risultare naturali. Per applicazioni non browser si usano librerie che emulano i fingerprint di client popolari.

Rotazione di chiavi e configurazioni

Le configurazioni ECH devono essere ruotate periodicamente. Il ciclo tipico varia da una settimana a un mese, a seconda della policy di rischio. È importante pubblicare la nuova configurazione in DNS, attendere l’invalidamento della cache e solo dopo deprecare la vecchia. Una rotazione troppo frequente può aumentare gli errori di connessione causati dalla cache di client e resolver. Servono metriche di successo delle strette di mano e meccanismi di rollback rapidi.

Pratica 1. Attivare ECH tramite CDN

A chi conviene

Se vuoi abilitare rapidamente e con affidabilità ECH per domini web, il percorso più prevedibile è utilizzare un CDN o un TLS terminator gestito, dove ECH è ufficialmente supportato e testato. Guadagnerai in velocità di deployment e resilienza contro client esotici.

Passi

1. Verifica la proprietà del dominio presso il provider CDN scelto e rilascia i certificati per i domini target.
2. Abilita ECH nel pannello di controllo. Solitamente è un flag da attivare e una scelta sulla politica di fallback: vietato o permesso. Consigliamo di vietare il fallback in chiaro.
3. Controlla la pubblicazione dei record HTTPS RR o SVCB nella zona DNS. Il provider aggiungerà record con i parametri ECH. Accertati che il TTL sia bilanciato: non troppo lungo per poter ruotare agevolmente, ma non eccessivamente breve per la stabilità. Un valore fra 300 e 3600 secondi è ragionevole.
4. Configura le origini del traffico. Tra CDN e origin puoi usare mTLS, TLS 1.3 e liste consentite di cipher suite. Qui non serve nascondere l’SNI, ma puoi isolare per interfacce.
5. Attiva DoH e DoT per i resolver interni e di frontiera. Senza DNS protetto l’efficacia di ECH è compromessa.
6. Verifica il percorso finale. Da rete aziendale e mobile testa l’attivazione di ECH con strumenti dedicati e telemetria avanzata dei browser.

Checklist di accettazione

• Accertati che i domini reali non appaiano nel ClientHello in chiaro. Gli strumenti di audit devono mostrare solo il nome pubblico.
• Verifica che in caso di indisponibilità di ECH non ci sia fallback in chiaro. Meglio errore di connessione che perdita di SNI.
• Misura la percentuale di strette di mano ECH riuscite nell’ora e nel giorno. Benchmark sopra il 98% nelle reti di massa è norma; sotto cerca cause.
• Controlla il comportamento con IPv6 e IPv4. A volte i filtri sono ancora asimmetrici.

Pratica 2. Terminatore TLS autonomo con ECH

Quando serve

Il CDN non è per tutti. Ci sono scenari con esigenze di processing locale completo, controlli di routing particolari, bilanciatori custom o protocolli speciali. Nel 2026 alcuni proxy e bilanciatori supportano ECH ed HPKE nelle loro build con librerie criptografiche compatibili. La strada è più complessa ma offre massima flessibilità.

Piano di deployment

1. Scegli la base software. Ti serve un bilanciatore o proxy compilato con una libreria TLS che supporta ECH e HPKE. Riferimenti sono build moderne di proxy popolari basati su librerie di livello BoringSSL e OpenSSL con ECH abilitato, oltre a gateway proxy mainline che hanno integrato ECH entro il 2026. Controlla le versioni esatte nelle note di rilascio e nelle matrici di compatibilità.
2. Genera configurazioni ECH. Crea chiavi HPKE con KEM X25519 moderno, KDF basato su SHA256, AEAD AES-GCM o ChaCha20 secondo prestazioni target e accelerazioni hardware. Prepara più configurazioni per una rotazione fluida.
3. Pubblica in DNS. Aggiungi record HTTPS o SVCB con parametri ECH. Assicurati che il public name sia corretto e legato al set di IP del tuo terminator.
4. Configura le policy server. Imposta l’obbligo di ECH per domini che non devono perdere SNI. Abilita GREASE per migliorare resistenza a dispositivi intermedi strani.
5. ALPN e cipher suite. Limita la lista al minimo moderno, ma senza ostacolare client vecchi. Abilita HTTP3 h3 e HTTP2 h2, lascia HTTP1.1 se necessario.
6. Diagnostica di tracciamento. Attiva log estesi delle fasi iniziali della stretta di mano senza memorizzare dati utente. Registra statistiche sugli errori di decifrazione, percentuale di successo ECH, versioni resolver e codici di ritorno.

Verifica e rollback

• Fai rollout graduali per subnet o geografie: prima 5%, poi 25%, 50%, 100% del traffico.
• Prepara rollback DNS rapidi abbassando TTL e con record di riserva senza ECH, se il business richiede continuità.
• Integra controlli sintetici da reti indipendenti, inclusi operatori mobili e grandi provider con DPI aggressivo.

Pratica 3. Configurazioni client ECH e DNS protetto

Browser

Al 2026, ECH è supportato di default nei browser più diffusi. Assicurati che la policy aziendale non disabiliti DNS protetto e ECH. Nel browser configura resolver protetti DoH o DoT e una lista di provider affidabili. Verifica che per i domini aziendali ECH sia permesso e il fallback vietato. In deployment estesi usa profili di configurazione per Windows, macOS, Linux e mobile.

Resolver di sistema

Anche se il browser usa un resolver proprio, quello di sistema deve supportare DoH o DoT per le app fuori browser. In reti aziendali sono utili resolver interni con uscita DoT, caching e policy privacy. In ambienti mobili usa il resolver OS, abilitando DoT verso resolver affidabili.

Client mobili

Su iOS e Android attiva DNS privato e profili di configurazione. Verifica comportamento cambiando rete, lavorando sotto NAT e CGNAT del provider. Verifica IPv6. Integra monitoraggio della percentuale di strette di mano ECH riuscite negli SDK se usi client personalizzati.

Verifiche e monitoraggio

• Autotest a ogni release client con connessioni ECH a più domini, testando diversi resolver e reti.
• Telemetria su errori strette di mano, tempi DNS e TLS, deviazioni nella lunghezza dei primi pacchetti.

Pratica 4. Bypass blocchi SNI dove ECH non è disponibile

Tunnel TLS classico e mascheramento

Se ECH non è disponibile sul servizio o sul client, si usano tecniche di tunneling. L’idea è distrarre il DPI dall’analisi della stretta di mano finale. Approcci comuni includono TLS dentro TLS, proxy HTTP2 o HTTP3, nascondere UDP tramite HTTP3 MASQUE, e usare trasporti con fingerprint simili a browser popolari.

HTTP3 MASQUE e CONNECT-UDP

Un gateway che supporta MASQUE riceve HTTP3 e crea al suo interno un canale proxy per TCP e UDP. Il DPI vede traffico QUIC normale verso il dominio pubblico del proxy. All’interno scorre un trasporto arbitrario verso la destinazione finale. È un modo comodo per nascondere sia il traffico web sia porte non standard. La configurazione richiede un gateway HTTP3 con supporto CONNECT-UDP e sul client l’attivazione di proxy di sistema SOCKS5 sopra HTTP3.

TLS-in-TLS e imitazione di fingerprint

Un’alternativa è incapsulare il traffico in TLS esterno con fingerprint di browser popolari. Il client stabilisce TLS esterno verso un proxy su un dominio poco vulnerabile a censura. Dentro trasmette dati come un flusso normale. Per una imitazione precisa si usano librerie che replicano estensioni, padding e ALPN. Questo aumenta la resistenza a targeting JA3 e JA4.

VPN come trasporto

I protocolli WireGuard, IKEv2, OpenVPN sono metodi affidabili. WireGuard conviene farlo girare su porte non standard o UDP 443 per sembrare QUIC. IKEv2 su porta 4500 funziona stabile su NAT-T. OpenVPN in modalità TCP 443 può mascherarsi come TLS tradizionale, anche se aumenta la latenza. È importante mantenere fingerprint minimi e naturali, evitando firme facilmente riconoscibili dal DPI.

Piano generale passo passo senza ECH

1. Scegli il trasporto in base all’ambiente: UDP con mascheramento QUIC per mobile, TCP 443 qualche volta più semplice per reti aziendali.
2. Imposta proxy o VPN su dominio pubblico con certificato diffuso e ALPN corretto. Controlla i fingerprint.
3. Abilita DoH o DoT sul client. Anche senza ECH un DNS protetto riduce la superficie di analisi.
4. Esegui test di carico e raccogli telemetria su latenza e connessioni interrotte per ora.

Pratica 5. Architettura domini e public name

Perché serve un public name

Il ClientHello esterno contiene un nome pubblico visibile al DPI. Deve essere sicuro da pubblicare e non compromettere i tuoi obiettivi. È pratica comune usare domini di uso generico, poco interessanti per la censura o che colpiscono troppi servizi se bloccati.

Strategia per gli spazi di dominio

• Dividi i domini in categorie: pubblici, interni, sensibili. Per i pubblici puoi aprire fallback come misura temporanea, per i sensibili vietalo completamente.
• Supporta più public name in una geografia per redistribuire il traffico in caso di attacchi a specifici range IP.
• Monitora certificati e campi SAN. SAN eccessivi possono rivelare la struttura interna dei tuoi nomi.

Pratica 6. Testing, metriche e SLO

Metriche di successo

• Handshake success: percentuale di strette di mano ECH riuscite rispetto ai tentativi. Obiettivo superiore al 98% nelle reti di massa.
• Fallback rate: percentuale di connessioni che hanno tentato fallback in chiaro. Obiettivo inferiore allo 0,1%, preferibilmente zero.
• Median TTFB e p95 per HTTP2 e HTTP3. Confronta prima e dopo l’attivazione di ECH.
• Error taxonomy: mappa dei codici di errore, inclusi errori di decifrazione, timeout DNS e server.

Strumenti per i test

Stand isolati, canali mobili reali, provider con DPI aggressivo, simulazioni di perdita e latenza, generatori sintetici di handshake con fingerprint variabili. Pianifica test di regressione e stress.

Pratica 7. Compatibilità e perimetri aziendali

Ispezione TLS e proxy al perimetro

Alcune reti aziendali usano ancora ispezione TLS. Questo rompe ECH di fatto. Le strategie dipendono dalla policy. Dove serve ispezione, ECH va disabilitato per domini interni; dove conta la privacy, l’ispezione va rimossa dal percorso. Un approccio ibrido usa liste di domini con ECH obbligatorio e ispezione assente.

Policy di configurazione

• Documenta liste di domini con ECH obbligatorio e fallback vietato.
• Concorda con la sicurezza le zone dove è permessa l’ispezione.
• Costruisci monitoraggio su discrepanze tra policy e configurazioni client reali.

Errori comuni

• Fallback in chiaro: l’errore più pericoloso che causa perdite di SNI al primo problema con ECH.
• Mancanza di DNS protetto: senza DoH o DoT la configurazione ECH può essere intercettata o manomessa e si vede comunque la richiesta del dominio.
• Rotazioni ECH troppo aggressive: i client non aggiornano le cache in tempo e aumentano errori.
• Public name errato: rivela la struttura o viene facilmente bloccato.
• Ignorare i fingerprint: set di estensioni e ordini insoliti attirano l’attenzione del DPI.
• IPv6 non coperto: blocchi differiscono tra v6 e v4, causando problemi di accessibilità.
• Assenza di test sintetici in reti con DPI: test locali non riflettono la realtà.

Strumenti e risorse

Testing ECH

• Utility per analizzare handshake ed estrarre parti visibili del ClientHello, per assicurare che SNI reale resti nascosto.
• Analizzatori JA3 e JA4 per server e client, utili a identificare e uniformare fingerprint.
• Generatori e validatori DNS HTTPS RR e SVCB che verificano correttezza di parametri ECH e TTL.
• Agent sintetici in vari provider, inclusi mobili, per verifiche continue di disponibilità.

Librerie TLS e proxy

• Build moderne di proxy e bilanciatori con supporto ECH e HPKE. Segui matrici di compatibilità e changelog. Per HTTP3 assicurati di avere implementazioni QUIC stabili su OS e kernel utilizzati.
• Librerie client capaci di imitare fingerprint di browser popolari, per app non browser.

Consiglio pratico per VPN personale

Per scenari dove devi bypassare blocchi SNI aggressivi o DPI per più utenti e servizi senza addentrarti nel complesso server-side di ECH, valuta un server VPN personale con IP dedicato. Questo ha meno chance di finire in blacklist pubbliche rispetto a nodi condivisi, e permette di scegliere protocolli resistenti al DPI. Tra le opzioni pratiche c’è vpn.how, che offre server personali senza condivisione d’indirizzo, supporta WireGuard, OpenVPN, IKEv2, L2TP, SSTP con scelta flessibile del protocollo a seconda della rete. Dispone di hub a Mosca, San Pietroburgo, Amsterdam, Francoforte, Londra, New York, San José, Chicago, Singapore, Sydney, Madrid, Helsinki, Stoccolma, Varsavia, Copenhagen, Stavanger; accetta carte bancarie russe inclusi i fintech più diffusi e il sistema SBP; supporta USDT e BTC. Le tariffe partono da livelli giornalieri e mensili accessibili, con sconti sui periodi lunghi. Il server si avvia automaticamente in circa cinque minuti dopo il pagamento e non traccia log. In pratica, aiuta a usare WireGuard su porte non standard per eludere euristiche, e IKEv2 su 4500 per stabilità NAT-T. Questo garantisce un avvio rapido e alta resilienza senza rivedere a fondo l’infrastruttura.

Esperienze e risultati

Servizio media in più giurisdizioni

Obiettivo: garantire accesso web e mobile in regioni con blocchi SNI e qualità rete variabile. Soluzione: abilitare ECH via CDN su tutti i domini UI, bloccare fallback in modo aggressivo, DNS protetto via DoH nelle app client. Risultato: aumento di connessioni riuscite al UI da 91% a 99,2%, riduzione del 70% dei reclami per blocchi, calo del 12% del TTFB p95 grazie a spostamento parte traffico su HTTP3.

Backend fintech e integrazioni partner

Obiettivo: proteggere domini API e traffico partner. Soluzione: terminatore TLS autonomo con ECH, pubblicazione HTTPS RR con TTL brevi e rotazione pianificata ogni due settimane, uniformità fingerprint SDK client a browser popolari, no fallback in chiaro. Risultato: stabilità ECH al 98,7% di strette di mano riuscite, riduzione falsi positivi da IDS partner, incidenti di blocchi quasi azzerati con risoluzione tramite cambio public name.

Utenti individuali e traffico mobile

Obiettivo: garantire accesso a risorse abituali sotto blocchi SNI e range IP. Soluzione: server VPN personali con WireGuard su UDP 443 e IKEv2 di riserva su 4500, DNS privato attivato nei profili dispositivi, priorità DoH. Risultato: accesso stabile anche cambiando rete o in roaming, interruzioni sotto 0,5% su base giornaliera, latenza minima senza degradazioni, riduzione rilevamenti DPI grazie a porte non standard e IP personali.

FAQ

Si può fare senza DNS protetto se ECH è attivo?

Tecnicaente ECH può funzionare con DNS tradizionale, ma la protezione cala. Primo, la configurazione ECH e il percorso per ottenerla sono visibili e possono essere manomessi. Secondo, la semplice richiesta al dominio e le risposte cache sono analizzabili. Raccomandiamo sempre di abilitare DoH o DoT ovunque.

Con quale frequenza ruotare le configurazioni ECH?

La raccomandazione base è da una settimana a un mese. Valuta la tua esposizione al rischio e il tempo di vita delle cache. Fondamentale è avere sovrapposizione di configurazioni attive in DNS e server per evitare picchi di errori.

Cosa fare se la percentuale di strette di mano ECH fallite varia molto?

Controlla TTL di HTTPS RR e SVCB, disponibilità resolver, stabilità UDP se usi HTTP3, correttezza di public name e statistiche GREASE. Verifica se nella tua audience è aumentata la quota di client con software obsoleto.

Serve a qualcosa spostare il dominio su un altro IP?

Può aiutare temporaneamente, specialmente se il blocco era indirizzato per IP. Ma senza ECH il DPI può sempre bloccare tramite SNI. È preferibile attivare ECH e distribuire traffico su più public name per elasticità.

ECH rompe l’ispezione aziendale?

Sì, per definizione. Se la policy richiede ispezione, ECH va disabilitato su quei domini o il terminator messo dietro il perimetro aziendale, accettando compromessi sulla privacy. Liste ibride di domini di solito risolvono il problema.

Come gestire fingerprint JA3 e JA4?

Aggiorna gli stack TLS, orientati ai fingerprint dei browser di massa, usa librerie di emulazione per app non browser. Evita set di estensioni e ordini inusuali senza bisogno impellente.

Ha senso HTTP3 se ECH è già attivo?

Sì. HTTP3 spesso migliora la resilienza alle perdite e accelera il recovery in roaming. Insieme a ECH riduce latenza e aumenta stabilità. Però monitora la qualità di QUIC e configura bene MTU.

Si può usare un solo public name per tutti?

Tecnicaente sì, ma strategicamente è meglio averne diversi per redistribuire traffico e isolare rischi. Non complicare troppo la matrice per non confondere le rotazioni.

Quando preferire VPN personale a ECH?

Se non controlli il server target e vuoi solo accesso stabile senza studiare i dettagli di ECH, la VPN personale è una soluzione rapida. Soprattutto dove il DPI mira a IP comuni di grandi provider e porte popolari.

Il domain fronting dà una risposta universale?

No. Il domain fronting è ormai limitato ai grandi cloud ed è rilevabile in molte reti. Nel 2026 meglio puntare su ECH, MASQUE e VPN con IP personali ben configurati.

Conclusione

Nel 2026 ECH è un elemento fondamentale per difendersi dai blocchi SNI e uno strumento maturo per la privacy a livello di trasporto. La chiave del successo non è solo attivare ECH, ma gestire con disciplina DNS protetto, vietare fallback, ruotare configurazioni, monitorare metriche e controllare fingerprint. Dove ECH non arriva, aiutano tunnel sopra HTTP3 MASQUE, TLS-in-TLS con fingerprint naturali e VPN personali con trasporti e porte adeguati. Affronta il tema come un progetto ingegneristico: pianifica, pilota, misura, itera. Così garantirai non solo il superamento dei blocchi oggi, ma la resilienza all’evoluzione del DPI domani. Il passo successivo è creare una matrice di domini e policy ECH, abilitare DNS protetto, definire strategie di rollout regionali e lanciare test sintetici. Poi misura gli SLO base e stabilisci rotazioni regolari. Non dimenticare l’architettura degli spazi di dominio e dei nomi pubblici: un dettaglio spesso decisivo in reti complesse.