Il problema delle chiavi DNS: quando la crittografia non basta

Immagina di avere un lucchetto robusto, ma di non riuscire a ottenere la chiave. È esattamente la situazione in cui si trovano oggi milioni di utenti che provano a usare protocolli DNS criptati.

DNS-over-HTTPS e DNS-over-TLS promettono di proteggere le ricerche dei domini da intercettazioni e censura. Tuttavia, la loro efficacia dipende da un dettaglio spesso trascurato: prima di poter cifrare una query, il client deve recuperare le chiavi pubbliche necessarie. Se questa fase preliminare viene ostacolata, l’intera protezione crolla.

La nuova strategia dei firewall

I censori hanno capito che non serve più forzare la crittografia. Basta impedire l’accesso alle chiavi che la rendono possibile. In Cina, per esempio, il Great Firewall non blocca più solo le connessioni: applica filtri selettivi e temporanei sui resolver DoH. Una singola query può scatenare un blocco IP di pochi minuti, sufficiente a rendere il servizio inutilizzabile. Ripetendo il pattern, l’effetto pratico è lo stesso di un divieto permanente.

Il firewall distingue inoltre tra protocolli:

• DNS normale: ancora avvelenato con risposte false
• DoT (porta 853): bloccato alla radice
• DoH (porta 443): monitorato e rallentato con soglie dinamiche

Il nodo architetturale

Il problema nasce da un circolo vizioso. Per usare Encrypted Client Hello (ECH), il browser deve prima ottenere le chiavi dal DNS. Ma se la query DNS stessa può essere intercettata, la crittografia non parte mai. Si crea così un punto debole prima ancora che la connessione criptata venga stabilita.

Cosa significa per chi gestisce domini e hosting

Chi offre servizi globali non può dare per scontato che i record DNS siano sempre raggiungibili. In alcune regioni, l’infrastruttura di risoluzione può essere parzialmente o totalmente inaccessibile. Inoltre, anche quando il traffico è cifrato, la distribuzione delle chiavi resta un bersaglio facile per chi controlla la rete.

Le vecchie certezze vanno riviste:

• La sola crittografia non garantisce accessibilità
• La censura oggi agisce più con l’attrito che con il blocco totale
• L’architettura centralizzata delle chiavi crea singoli punti di fallimento

Come si sta evolvendo la difesa

Le contromisure in fase di sperimentazione puntano su diversi fronti. Alcuni puntano a decentralizzare la distribuzione delle chiavi con DNSSEC avanzato o registri distribuiti. Altri cercano di mimetizzare le query DoH all’interno del normale traffico HTTPS, riducendo i pattern riconoscibili. Le reti anycast e la replica geografica rendono più difficile colpire singoli endpoint. Infine, alcune applicazioni integrano direttamente le chiavi, aggirando del tutto la dipendenza dal DNS.

Nessuna di queste strade è risolutiva da sola. Ogni approccio comporta compromessi su velocità, complessità e facilità d’uso.

Il punto centrale

La privacy delle connessioni non può essere progettata ignorando chi controlla fisicamente la rete. Per chi gestisce domini, hosting o infrastrutture, la domanda da porsi è semplice: se qualcuno volesse impedire l’accesso alle chiavi crittografiche, saprebbe come farlo? E noi, cosa abbiamo previsto per resistere?