Come funziona il DNSSEC?

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 sta cercando 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 della 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 verifica della firma, DNSSEC aggiunge alcuni nuovi tipi di record DNS:

• RRSIG, che contiene una firma crittografica
• DNSKEY, che contiene una chiave di firma pubblica
• DS, che 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 questi 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 (set di record di risorse). 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". pubblicato

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.

Chiavi di firma di zona

Ciascuna zona in DNSSEC è munita di una coppia di chiavi, denominate chiavi di firma di zona (ZSK): la parte privata della chiave firma digitalmente ogni RRset 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 chiave di firma di zona 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.

Chiavi di firma delle chiavi

Oltre a una chiave di firma di zona, i nameserver DNSSEC dispongono anche di una chiave di firma delle chiavi (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 fornisce il DNSKEY RRset mostrato sopra. Sia la KSK che la ZSK pubblica 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:

• Richiesta del 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 per la firma delle zone e per la firma delle chiavi? 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 firma delle chiavi si firma da sola, e ciò non apporta alcuna fiducia aggiuntiva. 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 di firma delle zone che non le chiavi di firma delle chiavi.

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 della 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 della 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 della 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.

DNSSEC per i registrar

Poiché la fiducia nel DNSSEC è dall'alto verso il basso (la zona root verifica la zona .com, la zona .com verifica la zona cloudflare.com e così via), l'abilitazione di DNSSEC richiede che il proprietario di un sito Web aggiorni il record DS con te, il registrar.

Questa parte è problematica: copiare e incollare il record DS apre la possibilità di errore umano e aggiunge un livello di complessità per gli utenti meno esperti. Vogliamo rendere il DNSSEC il più semplice possibile da implementare.

Se Cloudflare potesse comunicare direttamente con il registrar o il registro, potremmo attivare automaticamente il DNSSEC per ogni sito Web su Cloudflare e gestire le chiavi senza alcun intervento umano.

Nell'ambito del rollout del DNSSEC, abbiamo pubblicato una bozza Internet insieme al CIRA, il registro .ca, proponendo un protocollo che consenta agli operatori DNS come Cloudflare di fare proprio questo: comunicare con le società di registrazione e i registri per automatizzare la gestione del protocollo DNSSEC.

Unisciti a noi e rendi il DNSSEC più accessibile a tutti

Diversi registri stanno già pianificando di aggiungere il supporto, come NIC Chile (.cl) ed eNIC (.ee). Se lavori per un registrar o un registro e vuoi saperne di più, partecipare allo sviluppo del protocollo o aggiungere un'integrazione con Cloudflare, contattaci inviando un'e-mail a dnssec-integration@cloudflare.com

Riassunto

Come HTTPS, DNSSEC aggiunge un livello di sicurezza abilitando risposte autenticate su un protocollo altrimenti non sicuro. Mentre HTTPS crittografa il traffico in modo che nessuno sulla rete possa curiosare nelle attività Internet, DNSSEC firma semplicemente le risposte in modo che i falsi siano rilevabili. DNSSEC fornisce una soluzione a un problema reale senza necessità di incorporare la crittografia.

L'obiettivo di Cloudflare è quello di rendere l'abilitazione del protocollo DNSSEC il più semplice possibile. Tutti i clienti Cloudflare possono aggiungere DNSSEC alle loro proprietà web attivando un interruttore per abilitare DNSSEC e caricando un record DS (che verrà generato automaticamente) sul loro registrar. Scopri di più su come ottenere DNSSEC.

Abbiamo inoltre pubblicato una bozza Internet che delinea un metodo automatizzato per consentire ai registri e ai registrar di caricare i record DS per conto dei nostri clienti. In questo modo, Cloudflare potrà abilitare automaticamente il protocollo DNSSEC per la nostra intera comunità. Non farti sfuggire gli aggiornamenti futuri.