# Encrypted Client Hello e DoH: cosa non vedono più i firewall perimetrali

> ECH (RFC 9849) nasconde il vero nome host nell’handshake TLS e DoH nasconde la richiesta DNS. Cosa toglie questo ai firewall di rete, cosa no, e dove si sposta la visibilità.

HisnLabs Security & Research Team · Published 2026-09-25
Canonical: https://hisnlabs.com/it/blog/encrypted-client-hello-ech-doh-blind-perimeter-firewalls

Per vent’anni, firewall e proxy di rete si sono affidati a un campo non cifrato per sapere dove stesse andando il traffico cifrato: il Server Name Indication (SNI), il nome host che un client annuncia nel primo messaggio di un handshake TLS. DNS over HTTPS (DoH, [RFC 8484](https://www.rfc-editor.org/rfc/rfc8484.html)) nascondeva già la richiesta DNS che precede una connessione. Encrypted Client Hello, ora pubblicato come [RFC 9849](https://www.rfc-editor.org/rfc/rfc9849.html), nasconde lo stesso SNI. Insieme, eliminano i due segnali su cui era costruita la maggior parte del filtraggio in uscita.

## Come funziona ECH: un ClientHello interno e uno esterno

Con ECH, il client costruisce due messaggi ClientHello. Quello interno porta la destinazione reale e i parametri sensibili ed è cifrato con HPKE verso una chiave pubblica pubblicata in anticipo dal server. Quello esterno, inviato in chiaro, porta un nome pubblico condiviso, tipicamente il nome del front end del fornitore, così un osservatore apprende solo che il client sta parlando con quel fornitore ([RFC 9849](https://www.rfc-editor.org/rfc/rfc9849.html); [la spiegazione di Cloudflare](https://blog.cloudflare.com/encrypted-client-hello/)).

*Cosa vede un osservatore di rete (illustrativo)*

```text
TLS ClientHello (outer, cleartext)
  server_name:            cloudflare-ech.com      <- shared public name
  encrypted_client_hello: <HPKE ciphertext>        <- real hostname is inside

```

## Da dove viene la chiave: il record DNS HTTPS

Il client ha bisogno della chiave pubblica ECH del server prima dell’handshake. La ottiene dal DNS, nel record di risorsa HTTPS (tipo 65, [RFC 9460](https://www.rfc-editor.org/rfc/rfc9460.html)), il cui parametro `ech` porta una ECHConfigList. Ne abbiamo interrogata una reale. Il `dig` incluso in macOS non conosce il record per nome, quindi va richiesto per numero:

*Terminale, macOS 26.7, 25 settembre 2026*

```console
$ dig crypto.cloudflare.com TYPE65 +short
\# 133 0001000001000302683200040008A29F874FA29F884F000500470045 FE0D0041AF…
     …0012636C6F7564666C6172652D6563682E636F6D
# 0005 = the "ech" key, FE0D = ECH config version, and the last bytes decode to
# the ASCII public name: cloudflare-ech.com
```

Se anche quella richiesta DNS viaggia via DoH, un osservatore di rete non vede né la richiesta né, con ECH, il nome host nell’handshake. È questa la combinazione di cui parla questo articolo.

## Se ECH venga usato dipende dal client

ECH non è qualcosa che una rete attiva; decide ogni client. I browser hanno rilasciato il supporto ([Chrome Platform Status](https://chromestatus.com/feature/6196703843581952)), generalmente legato all’uso del DNS cifrato. Molto altro software non lo usa affatto. L’endpoint di trace di Cloudflare riporta cosa ha ricevuto, e il `curl` incluso in macOS invia ancora il nome host in chiaro:

```console
$ curl -s https://crypto.cloudflare.com/cdn-cgi/trace | grep -E "^(tls|sni)="
tls=TLSv1.3
sni=plaintext
```

Il quadro realistico oggi è quindi misto: i browser nascondono sempre più spesso il nome host, molti altri programmi no, e il software scritto per eludere il monitoraggio può scegliere di usare ECH e DoH deliberatamente.

## Cosa perde un firewall perimetrale, e cosa conserva

| Segnale | TLS + DNS in chiaro | ECH + DoH |
| --- | --- | --- |
| Richiesta DNS (quale nome) | Visibile sulla porta 53 | Nascosta dentro HTTPS verso il resolver |
| SNI (quale nome host) | Visibile | Solo il nome pubblico condiviso |
| IP e porta di destinazione | Visibile | Ancora visibile |
| Quale dispositivo sulla LAN | Visibile | Ancora visibile |
| Quale programma sul dispositivo | Non visibile | Non visibile |

*Su un front end condiviso di un fornitore, l’IP di destinazione spesso identifica il fornitore, non il sito.*

Il riassunto onesto è che il filtraggio basato sul nome host al perimetro smette di funzionare per il traffico ECH, mentre i controlli basati su IP no. Una rete può ancora rifiutare connessioni verso resolver DoH noti, il che in pratica impedisce anche ai browser di ottenere chiavi ECH via DNS cifrato, e può ancora bloccare intervalli di indirizzi. Ciò che non può più fare è distinguere due siti dietro lo stesso fornitore, o permetterne uno e bloccare l’altro, senza rompere TLS in modi che ECH è progettato per rilevare.

> **Warning:** Le affermazioni secondo cui ECH renda il traffico "intracciabile" o il filtraggio perimetrale "obsoleto" vanno troppo oltre: IP, tempistiche, volumi e il dispositivo restano visibili. Ciò che si perde è il nome host, e con esso la leva di policy più semplice.

## La visibilità si sposta sull’endpoint

L’unico punto in cui il nome host non è mai nascosto è la macchina che stabilisce la connessione: il programma lo ha richiesto per nome. Ecco perché ECH sposta il controllo in uscita verso l’endpoint. Un firewall basato sull’host non ha affatto bisogno di leggere l’handshake; vede quale processo ha aperto la connessione, verso quale indirizzo e, quando il programma ha risolto un nome, quale nome, prima che qualsiasi byte cifrato lasci la macchina. Vede anche l’unica cosa che un dispositivo di rete non ha mai potuto vedere, nemmeno prima di ECH: quale applicazione sulla macchina sta comunicando.

- Decidi per applicazione, non per nome host: un browser, un client di sincronizzazione e un binario sconosciuto ricevono regole diverse.
- Tratta un programma che avvia un proprio DoH verso un resolver che il sistema non ha configurato come un segnale che merita un’occhiata.
- Mantieni le liste di blocco basate su IP al perimetro; funzionano ancora, e non costano nulla.

## Il ruolo di FireAI e di HisnLabs

ECH hides the hostname from the network, not from the machine making the connection: an on-device firewall such as FireAI still sees which process is connecting and where, and asks before an app it does not know goes online.

FireAI è il prodotto di HisnLabs: un firewall con IA che funziona direttamente sul Mac. Mostra in linguaggio chiaro ogni connessione che le tue app effettuano e ti lascia decidere cosa esce dal tuo Mac — la sua IA lavora in locale, quindi il tuo traffico non viene mai inviato a noi né a nessun altro. Il team di ricerca sulla sicurezza di HisnLabs è quello che mantiene affidabili queste decisioni: cataloga quali domini sono semplice telemetria e quali un servizio reale, traccia il Paese e la rete dietro una connessione e addestra il modello locale (la funzione FireAI Pilot) su schemi di traffico reali, senza che nulla lasci il tuo Mac.

Puoi leggere le scelte tecniche che ci stanno dietro, oppure provare FireAI per 17 giorni, su [FireAI, di HisnLabs](https://hisnlabs.com/fireai/it/download).

## Sources

- [RFC 9849: TLS Encrypted Client Hello](https://www.rfc-editor.org/rfc/rfc9849.html)
- [RFC 9460: SVCB and HTTPS DNS resource records](https://www.rfc-editor.org/rfc/rfc9460.html)
- [RFC 8484: DNS Queries over HTTPS (DoH)](https://www.rfc-editor.org/rfc/rfc8484.html)
- [Cloudflare: Good-bye ESNI, hello ECH!](https://blog.cloudflare.com/encrypted-client-hello/)
- [Chrome Platform Status: Encrypted Client Hello](https://chromestatus.com/feature/6196703843581952)