Come funziona DNSSEC
Il DNS (Domain Name System) può essere considerato l'elenco telefonico di Internet: indica ai computer dove inviare e recuperare le informazioni. Purtroppo, accetta anche qualsiasi indirizzo gli venga dato, e senza fare domande.
I server di posta elettronica utilizzano il DNS per indirizzare i messaggi e questo significa che sono esposti a problemi di sicurezza nell'infrastruttura del DNS. Nel settembre del 2014 i ricercatori della CMU scoprirono che delle email che si presumeva fossero state inviate tramite i server di Yahoo!, Hotmail e Gmail, passavano invece attraverso server di posta non autorizzati. Gli autori degli attacchi avevano sfruttato una antica vulnerabilità nel DNS (Domain Name System), cioè il fatto che esso non controlla le credenziali prima di accettare una risposta.
La soluzione è un protocollo denominato "DNSSEC", che aggiunge un livello di fiducia al DNS fornendo un servizio di autenticazione. Quando un resolver DNS cerca blog.cloudflare.com, i nameserver .com aiutano il resolver a verificare i record restituiti per "cloudflare" e cloudflare aiuta a verificare i record restituiti per "blog". I nameserver del DNS root aiutano a verificare .com, e le informazioni pubblicate dal root vengono controllate tramite una procedura di sicurezza approfondita, che include la cosiddetta cerimonia di firma dei certificati di root.
Una breve introduzione a DNSSEC
DNSSEC crea un sistema di nomi di dominio sicuro aggiungendo le firme crittografiche ai record DNS esistenti. Queste firme digitali vengono memorizzate nei nameserver DNS insieme a tipi di record più comuni, come A, AAAA, MX, CNAME, ecc. Controllando la firma associata, è possibile verificare che il record DNS richiesto provenga dal suo nameserver autoritativo e che non sia stato modificato durante il percorso, a differenza di un record falso iniettato in un attacco man-in-the-middle.
Per facilitare la convalida della firma, DNSSEC aggiunge alcuni nuovi tipi di record DNS:
- RRSIG - Contiene una firma crittografica
- DNSKEY - Contiene una chiave di firma pubblica
- DS - Contiene l'hash di un record DNSKEY
- NSEC e NSEC3 - Per il denial-of-existence esplicito di un record DNS
- CDNSKEY e CDS - Per una zona figlio che richiede aggiornamenti ai record DS nella zona genitore.
L'interazione tra i record RRSIG, DNSKEY e DS, così come il modo in cui essi aggiungono un livello di fiducia al DNS, è ciò di cui parleremo in questo articolo.
RRSet
Il primo passo per proteggere un'area con DNSSEC consiste nel raggruppare tutti i record dello stesso tipo in un insieme di dati detto RRSet (Resource Record Set). Ad esempio, se nell'area sono presenti tre record AAAA dello stesso label (ad es. label.example.com), verrebbero tutti raggruppati in un unico RRSet "AAAA".
In realtà, è questo RRSet completo che viene firmato digitalmente, a differenza dei singoli record DNS. Naturalmente, questo significa anche che è necessario richiedere e convalidare tutti i record AAAA da una zona con lo stesso label, invece di convalidarne uno solo.
Zone-Signing Keys
Ciascuna zona in DNSSEC è munita di una coppia di chiavi, denominate Zone Signing Keys (ZSK): la parte privata della chiave firma digitalmente ogni RRRset nella zona, mentre la parte pubblica ha il compito di verificare la firma. Per abilitare DNSSEC, un operatore di zona crea delle firme digitali per ciascun RRset utilizzando la ZSK privata, e le archivia nel proprio nameserver come record RRSIG. Ciò equivale a dire: "Questi sono i miei record DNS, provengono dal mio server e dovrebbero apparire così".
Tuttavia, questi record RRSIG sono inutili a meno che i resolver DNS non dispongano di un metodo per verificare le firme. L'operatore di zona deve inoltre rendere disponibile la propria ZSK pubblica aggiungendola al proprio nameserver in un record DNSKEY.
Quando un resolver DNSSEC richiede un particolare tipo di record (ad es. AAAA), il nameserver restituisce anche il corrispondente RRSIG. Il resolver può quindi estrarre il record DNSKEY contenente la ZSK pubblica dal nameserver. Insieme, RRSet, RRSIG e la ZSK pubblica possono convalidare la risposta.
Se ci fidiamo della zone-signing key nel record DNSKEY, allora possiamo fidarci di tutti i record nella zona. E se invece questa chiave fosse compromessa? Abbiamo bisogno di trovare un modo per convalidare la ZSK pubblica.
Key Signing Keys
Oltre a una zone-signing key, i nameserver DNSSEC dispongono anche di una key-signing key (KSK). La chiave KSK convalida il record DNSKEY esattamente nello stesso modo in cui la nostra chiave ZSK ha protetto il resto dei nostri RRSet nella sezione precedente: firmando la chiave ZSK pubblica (memorizzata in un record DNSKEY) e creando un RRSIG per il DNSKEY.
Proprio come la ZSK pubblica, il nameserver pubblica la KSK pubblica in un altro record DNSKEY, che ci dà il RRSet DNSKEY mostrato sopra. Sia la KSK che la ZSK pubbliche sono firmate dalla KSK privata. I resolver possono quindi utilizzare la KSK pubblica per convalidare la ZSK pubblica.
La convalida per i resolver ora si configura in questo modo:
- Richiedere il RRSet desiderato, che restituisce anche il record RRSIG corrispondente.
- Richiesta dei record DNSKEY contenenti la ZSK pubblica e la KSK pubblica, che restituisce anche il RRSIG per il DNSKEY RRSet.
- Verifica del RRSIG del RRSet richiesto con la ZSK pubblica.
- Verifica del RRSIG del RRSet DNSKEY con la KSK pubblica.
Naturalmente, il RRSet DNSKEY e i corrispondenti record RRSIG possono essere memorizzati nella cache, in modo che i namserver DNS non vengano costantemente bombardati da richieste superflue.
Perché usiamo chiavi separate di zone-signing e key-signing? Come discuteremo nella prossima sezione, è difficile sostituire una chiave KSK obsoleta o compromessa. Cambiare la ZSK, invece, è un'operazione molto più semplice. Questo ci permette di utilizzare una chiave ZSK più piccola senza compromettere la sicurezza del server, riducendo al minimo la quantità di dati che quest'ultimo deve inviare assieme ad ogni risposta.
Ora abbiamo stabilito la fiducia all'interno della nostra zona, ma il DNS è un sistema gerarchico, e le zone raramente operano in modo indipendente. A complicare ulteriormente le cose, la chiave di key-signing si firma da sola, e ciò non apporta alcuna fiducia addizionale. Abbiamo pertanto bisogno di un modo per collegare la fiducia nella nostra zona con la sua zona genitore.
Record di delegazione del firmatario
DNSSEC introduce un record di delegazione del firmatario (DS) per consentire il trasferimento di fiducia da una zona genitore a una zona figlio. Un operatore di zona esegue l'hash del record DNSKEY contenente la KSK pubblica e lo assegna alla zona genitore per la pubblicazione come record DS.
Ogni volta che un resolver viene ridirezionato a una zona figlio, la zona genitore fornisce a sua volta un record DS. Questo record DS è il modo in cui i resolver sanno che la zona figlio è abilitata al DNSSEC. Per verificare la validità della KSK pubblica della zona figlio, il resolver esegue l'hash e lo confronta con il record DS del genitore. Se corrispondono, il resolver può presumere che la KSK pubblica non sia stata manomessa, il che significa che può considerare attendibili tutti i record nella zona figlio. Questo è il modo in cui viene stabilita una catena della fiducia in DNSSEC.
Si noti che qualsiasi modifica nella KSK richiede anche una modifica nel record DS della zona genitore. La modifica del record DS è un processo in più fasi che può finire per corrompere la zona, se viene eseguito in modo errato. Innanzitutto, il genitore deve aggiungere il nuovo record DS, quindi deve attendere che il TTL per il record DS originale scada, prima di rimuoverlo, ed è questo il motivo per cui è molto più facile cambiare le chiavi zone-signing key rispetto alle key-signing keys.
Denial of Existence esplicito
Se al DNS viene chiesto l'indirizzo IP di un dominio che non esiste, esso restituisce una risposta vuota. Non c'è modo di dire esplicitamente: "sono spiacente, la zona richiesta non esiste". Ciò rappresenta problema se si desidera autenticare la risposta, poiché non è presente alcun messaggio da firmare. DNSSEC corregge questo problema aggiungendo i tipi di record NSEC e NSEC3. Entrambi, infatti, consentono un denial of existence autenticato.
NSEC opera restituendo il record "next secure". Ad esempio, si consideri un nameserver che definisce i record AAAA per api, blog e www. Se si richiedesse un record per "store", esso restituirebbe un record NSEC contenente "www", il che significa che non ci sono record AAAA tra "store" e "www" quando i record sono ordinati alfabeticamente. Questo comunica efficacemente che "store" non esiste. E, poiché il record NSEC è firmato, è possibile convalidare il corrispondente RRSIG proprio come qualsiasi RRSet.
Sfortunatamente, questa soluzione consente a chiunque di attraversare la zona e raccogliere ogni singolo record senza sapere quali sono quelli che sta cercando. Questo può rappresentare una potenziale minaccia per la sicurezza, se l'amministratore della zona contava sul fatto che i contenuti della zona fossero privati. Maggiori dettagli su questo problema in DNSSEC: complessità e considerazioni, nonché nella soluzione unica di Cloudflare in Il DNSSEC fatto come si deve.
La catena della fiducia
Ora disponiamo di un metodo per stabilire la fiducia all'interno di una zona e collegarla alla sua zona genitore, ma come possiamo fidarci del record DS? Il record DS viene firmato proprio come qualsiasi altro RRSet, il che significa che ha un RRSIG corrispondente nel genitore. L'intero processo di convalida si ripete fino a quando non arriviamo alla KSK pubblica del genitore. Per verificarlo, dobbiamo andare al registro DS di quel genitore, e salire man mano la catena di fiducia.
Tuttavia, quando finalmente arriviamo alla zona root del DNS, ci troviamo davanti a un problema: non c'è nessun record DS genitore da convalidare. È proprio qui che possiamo vedere un lato molto umano dell'Internet globale.
Nella cerimonia della firma del dominio root, alcune persone designate, provenienti da tutto il mondo, si incontrano per firmare il dominio root DNSKEY in modo pubblico e altamente controllato. La cerimonia produce un record RRSIG che può essere utilizzato per verificare le chiavi KSK e ZSK pubbliche del nameserver del root. Invece di fidarci della chiave KSK pubblica in ragione del record DS del genitore, supponiamo che sia valida perché ci fidiamo delle procedure di sicurezza messe in piedi per l'accesso alla chiave KSK privata.
La capacità di stabilire la fiducia tra le zone genitore e figlio è parte integrante del protocollo DNSSEC. Se una qualsiasi parte della catena si rompe, non possiamo fidarci dei record che stiamo chiedendo perché un man-in-the-middle potrebbe alterare i record e indirizzarci su qualsiasi indirizzo IP desiderato.
Summary
Similar to HTTPS, DNSSEC adds a layer of security by enabling authenticated answers on top of an otherwise insecure protocol. Whereas HTTPS encrypts traffic so nobody on the wire can snoop on your Internet activities, DNSSEC merely signs responses so that forgeries are detectable. DNSSEC provides a solution to a real problem without the need to incorporate encryption.
Cloudflare’s goal is to make it as easy as possible to enable DNSSEC. All Cloudflare customers can add DNSSEC to their web properties by flipping a switch to enable DNSSEC and uploading a DS record (which we'll generate automatically) to their registrar.: Learn more about how to get DNSSEC.
We’ve also published an Internet Draft outlining an automated way for registries and registrars to upload DS records on behalf of our customers. This will enable Cloudflare to automatically enable DNSSEC for our entire community. Stay tuned for updates.
Milioni di proprietà Internet si affidano a noi
