Questa volta, sempre con "viva e vibrante soddisfazione" ospito la prima parte di un post su DNSSEC, scritto dal mio amico Antonio PRADO, brillante e appassionato networker, con grande esperienza teorica e pratica maturata su reti in produzione. Antonio è un personaggio ben conosciuto nell'ambiente, ha un suo blog, collabora con molti enti internazionali (es. MANRS), è l'autore della collana "Internet per le Nonne", insieme a Max Stucchi è l'animatore di ITNOG-on-the-Web, e molto altro.
INTRODUZIONE
La fiducia prima di tutto: anni a conquistarla, attimi a perderla. Così pure su Internet, i rapporti fiduciari stretti volontariamente intrecciano il tessuto della grande Rete e consentono lo sviluppo di servizi sempre più affidabili.
Un acronimo scritto e pronunciato spessissimo, tutte le volte che ci riferiamo alla necessità, per dirla semplicemente, di una traduzione tra nomi a dominio e indirizzi IP (e viceversa). Un po' come nei vecchi elenchi telefonici, al nome "Antonio Prado" (equivalente nell'analogia al nome a dominio) corrispondeva il numero telefonico "0733 123456" (equivalente nell'analogia all'indirizzo IP).
In altre parole, quando desideriamo tradurre un nome in un numero, andiamo a consultare un database (base di dati progettata in modo gerarchico e distribuito) custodito da una autorità. Pensiamo pure a un enorme dizionario che reca su ciascuna pagina una parola tradotta in tanti numeri, ciascun numero corrispondente a una caratteristica di quel lemma.
Ora, dato che i dizionari sono migliaia e distribuiti sia geograficamente sia logicamente, è necessario un indice che li annoveri tutti e dunque occorre che un’altra autorità (di rango superiore rispetto alle precedenti citate) custodisca l’indice di quei database.
Grosso modo, ecco spiegato il meccanismo: un software ha il compito di chiedere all’autorità centrale quale database deve consultare per avere le traduzioni inerenti un certo nome a dominio; l’autorità centrale cerca nel proprio indice e fornisce una risposta.
Di conseguenza il software, intascata l’informazione su quale (e dove) sia il database da raggiungere, interroga l’autorità (locale) responsabile per quel nome a dominio e, se tutto va bene, riesce ad avere la traduzione desiderata.
A questo punto però, la comunità di esperti delle cose di Internet (res interretis) ha sollevato più di un profilo di criticità nell’affidabilità di quell’algoritmo per la risoluzione dei nomi. Non solo da un punto di vista prettamente tecnico, ma anche sotto l’aspetto della fiducia.
Cioè come può il software, protagonista dell’esempio fatto in precedenza, fidarsi dell’autorità centrale: è esattamente chi dice di essere? E come potrebbe fidarsi dell’autorità locale: è, anch'essa, chi dice di essere? Quanto poi alle traduzioni: come può il software avere la prova che le informazioni fornite dalle autorità siano affidabili?
Per rispondere a queste e a molte altre esigenze di affidabilità, IETF (Internet Engineering Task Force) ha ampliato le funzionalità del protocollo DNS e, nel 1999, Donald Eastlake ha per primo formalizzato con la RFC 2535 - Domain Name System Security Extensions, le cosiddette estensioni di sicurezza alle quali è possibile riferirsi usando l’abbreviazione DNSSEC.
In questo e nei prossimi post dedicati all'argomento, ci avventureremo nell’esplorazione di DNSSEC salpando dal molo della terminologia, navigando per l’anatomia del protocollo, solcando le onde delle implementazioni per approdare infine nel porto sicuro delle migliori pratiche.
CONCETTI DI GERARCHIA E DISTRIBUZIONE
DNSSEC si può considerare come una estensione del DNS, cioè non va a stravolgere il funzionamento classico della risoluzione dei nomi, anzi è proprio su questa che si poggia.
Come ne amplia il funzionamento, allo stesso modo ne arricchisce le parole e i concetti introducendo nuovi termini e acronimi.
Partiamo con un rapido ripasso degli aspetti base del Domain Name System secondo la letteratura classica, in funzione di ciò che ci servirà per scoprire il DNSSEC.
Innanzitutto il punto “.”: rappresenta il simbolo di demarcazione tra le etichette che formano i nomi a dominio. Quindi, almeno per chi fa uso di scrittura destrorso, si parte da un’etichetta, a esempio “domain”, si scrive un “.”, un’altra etichetta, a esempio “tld” e un altro “.” per finire. Risultato: “domain.tld.”. Ora, leggendo da destra verso sinistra l’esempio appena riportato, è intuitivo comprendere come in principio ci sia il “.” quindi “tld” e infine “domain”. Si tratta di una vera e propria catena costituita di due maglie che procedono in senso gerarchico.
La massima autorità è dunque quella del “.” iniziale (Root Server) che dà origine al Top Level Domain “tld” (primo livello), al di sotto del quale troviamo l’etichetta “domain” (secondo livello).
Il numero dei punti coinvolti nella scrittura di un nome a dominio ne determina anche il livello: this.is.my.very.long.domain.tld. ⇒ settimo livello.
Alla comparsa di ciascun “.” è possibile associare una autorità gerarchicamente sovraordinata o sottordinata rispettivamente al livello seguente (più a destra) o al precedente (più a sinistra).
Per essere più chiari possiamo dire che, nel precedente esempio, la più alta autorità sia quella del “.”, la seconda quella di “tld”, la terza quella di “domain”; se ne deduce che sarà il “.” a legittimare l’esistenza di “tld” e quest’ultimo a legittimare l’esistenza di “domain”.
Oltre a un comprensibile ruolo di legittimazione, le autorità sono necessarie per poter indirizzare quelle sottordinate: sarà dunque il “.” a custodire le coordinate per raggiungere l’autorità responsabile per “tld” e, a sua volta, sarà quest’ultima a custodire le coordinate per raggiungere l’autorità responsabile per “domain”.
Come si vede, è una fitta e intrecciata maglia di relazioni che, più forte è, più robusto è il sistema DNS e di conseguenza Internet.
Riprendendo il filo, oltre la struttura gerarchica, è impossibile non notare che stiamo descrivendo un sistema distribuito visto che i dati non sono concentrati in un solo punto, anzi.
Cominciamo col dire che le autorità di grado più alto, i Root Server, sono 13 e si chiamano con le prime tredici lettere dell’alfabeto latino (da A a M). A dire la verità, di ciascun Root Server esistono parecchie istanze, geograficamente distribuite, allo scopo di avvicinarsi quanto più possibile agli utenti di Internet.
Al momento (giugno 2020) contiamo nel mondo 53 istanze di A, 6 di B, 10 di C, 156 di D, 308 di E, 252 di F, 6 di G, 8 di H, 72 di I, 185 di J, 77 di K, 165 di L, 9 di M, per un totale di 1307. I Root Server sono sotto la responsabilità di organizzazioni che ne gestiscono le operazioni e ne pianificano l’ampliamento.
In Italia abbiamo 1 D a Torino, 3 E (Milano, Roma, Torino), 3 F (Milano, Roma, Torino), 1 G a Napoli, 1 I a Milano, 3 J (Milano, Roma, Torino), 3 K (Milano, Palermo, Prato), 2 L (Firenze e Latina), cioè 17 in tutto, poco più dell’1% della totalità.
Ciascun Root Server custodisce la root.zone, una copia dell’indirizzario (cioè le coordinate) dei Top Level Domain (TLD), i cosiddetti nomi a dominio di primo livello. È oltre lo scopo di questo post entrare nel dettaglio delle specie di TLD (gTLD, ccTLD), ma comunque è funzionale sapere che anch’essi sono gestiti e manutenuti da organizzazioni con il compito di pubblicare un registro, dal quale poter evincere le coordinate utili a raggiungere i nomi a dominio di livello maggiore (secondo, terzo, ecc.).
Prendiamo a esempio il ccTLD “.it”: anch’esso è presente nella root.zone accompagnato dalle coordinate dell’autorità italiana che si fa carico della gestione di tutte le operazioni connesse alla gerarchia “.it”.
È il Registro “.it” che ha sede presso l’Istituto di Informatica e Telematica (IIT) del CNR (Consiglio Nazionale delle Ricerche) a Pisa e che mette a disposizione, per la gestione DNS del TLD “.it” le infrastrutture: a.dns.it., m.dns.it., r.dns.it., s.dns.it., dns.nic.it., nameserver.cnr.it.:
~ $ dig it. NS IN +short
s.dns.it.
m.dns.it.
nameserver.cnr.it.
dns.nic.it.
a.dns.it.
r.dns.it.
~ $
Ognuna di queste infrastrutture contiene una copia di tutto l’indirizzario dei nomi a dominio afferenti alla gerarchia “.it”, cioè, per conoscere quale sia l’autorità responsabile di un nome a dominio, a esempio “governo.it”, occorre consultare proprio quell’indirizzario. E quindi, scorrendo quel file, si arriva alla riga "governo.it" che riporta, tra gli altri, "ns.palazzochigi.it." e "ns2.palazzochigi.it.", facendoci capire che sono proprio quelle due infrastrutture a conoscere tutti i dettagli del nome a dominio in questione:
~ $ dig governo.it NS IN +short
ns.palazzochigi.it.
ns1a.btitalia.it.
ns2.palazzochigi.it.
ns2a.btitalia.it.
~ $
Di conseguenza se volessimo sapere a quale indirizzo IP sia stato abbinato il nome a dominio "mail.governo.it.", dovremmo chiedere proprio a una di quelle infrastrutture autorità:
~ $ dig @ns.palazzochigi.it. mail.governo.it A IN +short
mail.palazzochigi.it.
195.66.14.147
~ $
Infine è necessario precisare che l’autorità che gestisce a questo livello i nomi a dominio si chiama Registrar, cioè quell’organizzazione che si fa carico di mantenere i rapporti con chi gestisce i TLD. Nel caso di “governo.it.”, il Registrar di riferimento è BTITALIA-REG che infatti è nell’elenco dei Registrar (1.148 soggetti in questo momento) in possesso di un valido contratto con l’IIT:
$ whois governo.it|grep -A5 Registrar
Registrar
Organization: BT Italia s.p.a.
Name: BTITALIA-REG
Web: http://www.btitalia.it
DNSSEC: no
~ $
Fin qui l’illustrazione della catena di autorità che, negli esempi riportati, procede dal “.” (Root Server), passando attraverso “it.” (IIT), fino ad arrivare a "ns.palazzochigi.it." (BTITALIA-REG).
Basterebbe fermarsi qui per avere già un’idea di quanto vulnerabili possano essere alcuni dei passaggi brevemente descritti; e, riprendendo le domande che ci siamo posti nell’introduzione a questa piccola trattazione, chi può darci la sicurezza che quando chiediamo un dato alle autorità, la risposta sia genuina?
Intendiamo in tutti i sensi, cioè che l’autorità sia esattamente chi afferma di essere e che la risposta sia certificata. Stando così le cose, possiamo facilmente dubitare di tutti i passaggi coinvolti nella risoluzione dei nomi. Ma non solo noi. Le stesse autorità potrebbero sollevare perplessità circa le risposte ricevute da quelle gerarchicamente sovraordinate e, per come è stato congegnato il sistema di risoluzione dei nomi (DNS), non esiste una bacchetta magica che possa dare garanzie a tutti i soggetti coinvolti circa la veridicità dei dati.
Per questi motivi è indispensabile il ricorso a una tecnologia capace di arricchire il DNS con dei poteri speciali: la certificazione dei contenuti.
CONTENUTI CERTIFICATI
Verba volant, scripta manent. Ma non è ancora sufficiente per riscuotere la nostra piena fiducia dato che, come abbiamo già riferito, i dati scritti potrebbero giungere a noi corrotti o provenienti da una fonte avvelenata.
Richiediamo allora a gran voce che i dati siano anche firmati digitalmente, cioè che siano certificati. Ed è qui che entrano in gioco le estensioni di sicurezza del DNS (DNSSEC).
Le firme digitali previste da DNSSEC si basano su una sempreverde crittografia a chiave pubblica, cioè per ogni nome a dominio (zona) esiste una coppia di chiavi: una pubblica e una privata. Da un lato, il responsabile della zona userà la sua chiave privata (segreta e custodita gelosamente) per firmare i dati relativi al nome a dominio e anche per creare delle firme digitali. Dall’altro, la chiave pubblica verrà pubblicata proprio nella zona, così che chiunque possa consultarla e usarla liberamente per stabilire la genuinità dei dati DNS.
In altre parole, dando il giusto nome alle cose, il resolver (software che interroga i server DNS, cioè le autorità, per conoscere la traduzione di un nome a dominio in IP, o viceversa) consulta la chiave pubblica che trova nella zona e la usa per capire se i dati del DNS siano coerenti con quelli, sempre presenti nella zona, precedentemente firmati dal responsabile con la sua chiave privata.
A questo punto il resolver può restituire due tipi di risposta all’utente: positiva, nel caso in cui la verifica dei dati firmati vada a buon fine con la chiave pubblica; o, in caso contrario, negativa (con un fondato sospetto che possa essere in corso una qualche specie di attacco).
Possiamo ora intuire quali siano due degli aspetti chiave del DNSSEC: l’autenticazione della sorgente dei dati (cioè i dati appartengono proprio alla zona che stiamo interrogando) e la protezione della loro integrità (cioè i dati, nel percorso dalla sorgente fino a noi, non sono stati manipolati).
Addentriamoci ora con calma più in profondità poiché l’avvocato del diavolo che è in noi vorrebbe ancora risposte a ulteriori domande, prima fra tutte: perché dovremmo fidarci della chiave pubblica che sembra essere il punto debole di questa ricostruzione? Dubbio tutt’altro che peregrino: in effetti ciascuna maglia della catena deve riscuotere la nostra piena fiducia.
Per rispondere ci è utile ora richiamare il concetto di concatenazione delle autorità tratteggiato precedentemente. Infatti, la chiave pubblica di una zona viene anch’essa firmata, ma da chi? Non dal responsabile della zona stessa (come le altre voci), ma dal responsabile della zona del nome a dominio di livello gerarchico superiore.
Riprendiamo l’esempio esposto alcune righe fa: "governo.it.". Il responsabile della zona “governo.it.” genera, allo scopo, una coppia di chiavi; la sua chiave pubblica deve però essere firmata (con la propria chiave privata) dal responsabile della zona “it.”; a sua volta la chiave pubblica della zona “it.” deve essere firmata dal responsabile della zona “.” con la propria chiave privata. Ecco saldata la catena della fiducia:
- “.” → coppia di chiavi: root-pubblica e root-privata.
- “it.” → coppia di chiavi: it.-pubblica (firmata da root-privata) e it.-privata
- “governo.it.” → coppia di chiavi: governo.it.-pubblica (firmata da it.-privata) e governo.it.-privata
- “mail.governo.it.” firmata da "governo.it.-privata".
Verificare a ritroso l’affidabilità della catena a questo punto è semplice, poiché ciascuna autorità viene legittimata da quella di livello superiore. Unica eccezione, come si può notare dallo schema, è rappresentata dalla zona “.” la cui chiave pubblica, chiamata àncora di fiducia (trust anchor), non è legittimata da un’altra autorità, ma piuttosto da una rigorosa procedura di creazione [RFC 7958 - DNSSEC Trust Anchor Publication for the Root Zone, Agosto 2016] (una vera e propria cerimonia data in diretta streaming su Internet; ecco l’ultima del 23 aprile 2020).
E qui termina la prima parte di questo post. Nelle prossime puntate passeremo dalla poesia (la teoria) alla prosa (la pratica) ... Stay tuned!!!
Nessun commento:
Posta un commento