DNS cifrato: DoH e DoT

La lezione precedente ha descritto una ricerca DNS semplice come una cartolina: leggibile da chiunque la maneggi lungo il percorso. Esistono due standard IETF per mettere quella cartolina in una busta: DNS su TLS (DoT, RFC 7858) e DNS su HTTPS (DoH, RFC 8484). Entrambi cifrano la stessa ricerca; differiscono principalmente nel modo in cui la trasportano.

DNS su TLS

RFC 7858 dichiara direttamente il suo obiettivo: “la cifratura fornita da TLS elimina le opportunità di intercettazione e manomissione sul percorso delle query DNS”, affrontando il fatto che “quasi tutte le query DNS vengono inviate non cifrate, il che le rende vulnerabili all’intercettazione da parte di un aggressore.” DoT usa una propria porta dedicata, la 853, invece della solita porta 53. La RFC spiega perché: “questa raccomandazione contro l’uso della porta 53 per DNS su TLS serve a evitare complicazioni nello scegliere l’uso o il non uso di TLS e a ridurre il rischio di attacchi di downgrade.”

DNS su HTTPS

RFC 8484 prende una strada diversa: “ogni coppia query-risposta DNS viene mappata in uno scambio HTTP”, trasportata sulla stessa porta 443 usata dal normale traffico HTTPS. La RFC nota che questo ha un vantaggio collaterale: “la porta predefinita 443 di HTTPS e la capacità di mescolare il traffico DoH con altro traffico HTTPS sulla stessa connessione possono scoraggiare i dispositivi non privilegiati sul percorso dall’interferire con le operazioni DNS”, perché una ricerca è più difficile da isolare e bloccare quando assomiglia a qualsiasi altra richiesta web.

Cosa nasconde la cifratura, e cosa ancora non nasconde

Entrambi gli standard impediscono a un operatore di rete o a un intercettatore Wi-Fi di leggere le tue ricerche in transito. Nessuno dei due le nasconde dal resolver a cui le hai inviate. RFC 8484 è esplicita sul fatto che DoH non cambia cosa può vedere il server stesso: nota che “vari trasporti delle query e risposte DNS forniscono dati che possono essere usati per correlare le richieste”, e che meccanismi web ordinari come indirizzi IP del client, cookie e informazioni di sessione TLS significano che “non risulta che DoH introduca nuove preoccupazioni oltre a quelle associate a HTTPS” lato server. RFC 7858 nota allo stesso modo che DoT “non affronta altri problemi di sicurezza nel DNS” e che “anche con messaggi cifrati, una parte ben posizionata potrebbe essere in grado di raccogliere alcuni dettagli da un’analisi dei tempi e delle dimensioni dei messaggi.” In breve: il DNS cifrato sposta chi vede le tue ricerche verso l’operatore del resolver che hai scelto, non elimina del tutto la visibilità.

C’è una seconda lacuna che vale la pena conoscere. Cifrare la ricerca DNS non nasconde di per sé a quale sito ti connetti poi: l’handshake TLS che segue normalmente include il nome host in chiaro. Come spiega Cloudflare a proposito della Server Name Indication (SNI), “SNI include il nome host nel messaggio Client Hello, ovvero il primissimo passo di un handshake TLS” — inviato prima che la cifratura sia stabilita. Un’estensione chiamata Encrypted SNI (ESNI), spiega la stessa fonte, “si aggiunge all’estensione SNI cifrando la parte SNI del Client Hello”, il che “impedisce a chiunque origli tra client e server di vedere quale certificato sta richiedendo il client.” Il supporto per nascondere SNI dipende ancora dall’accordo sia del browser che del sito, e non è ancora il modo in cui funziona ogni connessione.

Come lo supporta macOS

Apple documenta una configurazione Impostazioni DNS per Mac, iPhone e iPad che fa esattamente questo: permette a un dispositivo di “instradare le query DNS di un dispositivo attraverso un server DNS cifrato usando DNS su HTTPS o DNS su TLS.” Viene fornita come profilo di configurazione, che può limitare il resolver cifrato a domini specifici tramite “domini di corrispondenza supplementari”, oppure applicarsi solo su certe reti usando “regole su richiesta” che possono corrispondere a cose come l’SSID della rete.