Il DNS è un servizio nato per un’operazione relativamente semplice: tradurre nomi di host in indirizzi IP. È stato progettato per offrire questo servizio in modo efficiente e distribuito, in sostituzione del meccanismo precedente che era semplicemente un grosso file “hosts”, mentre la sicurezza non è stata certo uno dei fattori che ne hanno guidato lo sviluppo. Nel tempo sono state trovate molte vulnerabilità nel meccanismo di risoluzione dei nomi, legate principalmente al fatto che per arrivare ad ottenere la traduzione di un nome in indirizzo IP, passiamo da un gran numero di sistemi di cui sono tutt’altro che chiare l’affidabilità e il rapporto di fiducia con noi e con il sistema di cui vogliamo tradurre il nome. Per gestire questi problemi sono stati trovati dei “trucchi” (non saprei come altro definire cose come il double reverse lookup o i meccanismi di protezione della cache, ad esempio). Ma il DNS è rimasto un servizio debole, proprio per questo rapporto di fiducia con sistemi più o meno arbitrari. Dato che molti non sono convinti dell’esistenza di questo problema, consiglio la lettura dell’RFC 3833, in particolare le sezioni 2.3 e 2.4, ed eventualmente dell’RFC 4367 sezione 6.3. Conscia di questo problema, e nell’intento di favorire lo sviluppo del commercio elettronico, all’inizio degli anni ’90 Netscape ha sviluppato SSL, poi diventato TLS. Scopo di SSL era principalmente fornire un modo per associare nomi a host senza fidarsi del DNS. Per fare questo, si sono fidati delle Certification Authorities. Con il tempo, abbiamo avuto essenzialmente tre tipi di servizi: quelli a bassa criticità che si fidano del DNS, quelli ad alta criticità che si fidano dei certificati, e quelli ad alta criticità mal realizzati che sembra si fidino dei certificati, ma in realtà si fidano del DNS (ad esempio le pagine http con i soli frame di autenticazione via https). Di fatto, il DNS ha continuato ad avere un ruolo importante, e riuscire a manomettere il DNS continua ad avere un impatto notevole. Così, si è pensato di migliorare la sicurezza del DNS con l’uso di DNSSEC. Il miglioramento di DNSSEC consiste essenzialmente nella firma dei record per garantirne l’origine.
Per farla semplice, il meccanismo del DNSSEC prevede essenzialmente che quando una zona viene delegata (informalmente, quando si delega un sottodominio) si deleghi anche la firma dei record per quella zona, mediante un apposito record DS (Delgation Signer) firmato da chi delega, e un record DNSKEY contenente la chiave pubblica delegata. Quindi in pratica, abbiamo una catena di certificazioni che “risale” fino ai record DNSKEY dei root dns, che devono essere distribuiti in modo “sicuro” come attualmente si distribuiscono i certificati delle CA. E qui si chiarisce il mistero: chi delega fa da certification authority per chi è delegato, e i root server sono le root CA. Quindi abbiamo solo cambiato gerarchia di CA e catena di fiducia. Tecnicamente è senz’altro una soluzione più semplice, ma la semplificazione deriva principalmente dal fatto che il meccanismo di trust “deriva” da una soluzione tecnica, invece di essere gestito direttamente. Vuole dire ad esempio che chi gestisce un ccTLD è automaticamente CA per i domini di quella regione (sostituite a regione il paese autoritario/illiberale di vostra preferenza), che quindi potrebbe facilmente fornire certificati falsi per i siti di quella zona. O anche, chi ha un dominio .com o .org si troverebbe implicitamente a fidarsi del gestore del TLD anche come gestore di certificati. Per dirla ancora diversamente, mentre con le attuali CA c’è un minimo di scelta, con DNSSEC non c’è neanche quella. Inutile dire che molti dei soggetti saranno gli stessi… Ora, se il DNSSEC era nato per migliorare la sicurezza del DNS, mentre l’uso dei certificati era nelle intenzioni un meccanismo indipendente dalla sicurezza del DNS, integrando le due cose si ottiene che i meccanismi di trust del DNS, poco definiti anche contrattualmente, diventano l’unico meccanismo di trust. È chiaro che “in teoria” uno può decidere che per alcuni certificati si appoggia al DNS e per altri usa CA tradizionali, ma sappiamo che in questi contesti se un meccanismo prende piede poi è improbabile che altri vengano ancora utilizzati in modo diffuso: su queste cose l’informatica cerca “malamente” l’efficienza. Quindi, quando si avrà un utilizzo diffuso di DNSSEC, tutti utilizzeranno questo meccanismo per distribuire il proprio certificato, probabilmente senza che ci sia neanche qualcosa di simile al CSP, e altri meccanismi (e servizi, e aziende) spariranno. C’è però un ulteriore problema, ovvero quello dei cosidetti “stub resolver”, come sono tipicamente quelli dei pc domestici, ovvero i resolver che in sostanza si limitano a passare la richiesta di risoluzione al server del proprio provider e a ricevere da questo la risposta: dato che non effettuano l’intera risoluzione, non sono in grado di verificare la catena di trust. Per dirla più chiaramente, o i pc di casa implementano integralmente un resolver DNS, cosa che avrebbe un impatto non da poco dull’utilizzo del DNS in generale, oppure si fidano completamente dell’ISP, che sarebbe tranquillamente in grado di fornire record falsificati. Allo stato attuale, non sarebbe un grosso problema.
È il caso di sottolineare, per completezza, che l’RFC 4398 prevede di poter distribuire informazioni relative a certificati attraverso il DNS, ma dato che il DNS non era autenticato, la verifica del certificato rimaneva un normale rapporto con la CA: in pratica era solo un modo comodo per ottenere un certificato, senza grosse implicazioni sulla sicurezza..
Ma la commistione fra DNS e certificati sta aumentando,mentre nel frattempo il DNS è stato reso ancora più critico da meccanismi come SPF, o anche le varie DNSBL, e cominciano ad apparire usi ancora più “estrosi“, usando il DNS come una specie di directory general purpose… solo che con il DNS non sappiamo realmente di chi ci stiamo fidando.
Prima di andare avanti è utile vedere prima di tutto in quali casi è utile SSL/TLS e come si potrebbe sfruttare un certificato falsificato, almeno in assenza di DNSSEC. Il certificato falso non è necessario quando l’attaccante ha compromesso il client o il server (es. un server HTTP): in entrambi i casi, si possono ottenere ottimi risultati con sistemi molto più semplici che procurarsi un certificato falso. Il certificato falso serve invece quando si pratica un man-in-the-middle, quindi quando l’attaccante è in grado di mettersi sulla strada fra il client e i server e presentare i propri dati/pacchetti/pagine al client al posto di quelli del server.
Torniamo al DNSSEC e consideriamo adesso l’impostazione del gruppo dell’IETF dane, che prevede che chi gestisce il DNS, e quindi ha già la possibilità di firmare i Resource Record, possa anche firmare il certificato relativo alla chiave pubblica da associare a un nome di host, distribuendo la stessa chiave con il DNS. In sostanza, se il DNS è sicuro, chi fornisce la traduzione da host a indirizzo IP fornisce anche “contestualmente” la chiave pubblica dell’host (o di un suo servizio). Cito: “The solutions specified by this working group rely upon the security of the DNS to provide source authentication for public keys. The decision whether the chain of trust provided by DNSSEC is sufficient to trust the key, or whether additional mechanisms are required to determine the acceptability of a key, is left to the entity that uses the key material“. Potrebbe sembrare la soluzione ottimale, che elimina il problema delle Certification Authorities, ma come sempre se un problema che non ha soluzione sembra risolto, tutto sta nel capire dove è stato nascosto. In questo caso, bisogna focalizzarsi su due punti: il “chain of trust” a cui si riferisce la citazione, e il meccanismo di verifica. Di fatto, anche per SSL/TLS abbiamo solo sostituito la catena di trust delle attuali CA con quella di DNSSEC. Con due conseguenze importanti: la prima è che se prima il DNSSEC era un miglioramento della sicurezza del DNS, che non aumentava la criticità del DNS, adesso il DNS, seppure nella versione “sicura”, assorbe la criticità delle attuali CA (ripeto, è improbabile che queste sopravvivano nella forma attuale nel momento in cui DNSSEC si diffonda come soluzione più efficiente). Per capire quanto la cosa sia critica, basta ritornare agli stub resolver: se la proposta del gruppo dane venisse accettata, allo stato attuale, un ISP sarebbe in grado di fornire anche certificati SSL/TLS falsificati; per dirla in altre parole, sarebbe in grado di intercettare in modo trasparente le comunicazioni finora protette da SSL/TLS. Non mi pare di aver visto finora niente che affronti questo problema, ma magari mi è sfuggito: se qualcuno ne sa qualcosa di pìu e avesse voglia di raccontarmelo mi farebbe un favore. Il problema di fondo, secondo me, è che sulla base di modelli “ideali” vengono sviluppati degli standard tecnici, che poi vengono adottati senza considerare che il mondo non corrisponde a quei modelli ideali. O più spesso, aggirando questi problemi con frasi come “The decision whether the chain of trust provided by DNSSEC is sufficient to trust the key, or whether additional mechanisms are required to determine the acceptability of a key, is left to the entity that uses the key material“. Non vado oltre su questa strada, ma porto un altro esempio concreto: una proposta che lega anch’essa DNSSEC e CA, che viene nientemeno che da Comodo.
Come le recenti vicende hanno mostrato, quando ci si appoggia a una PKI pubblica la quantità di entità fidate è enormemente più alta di quella che uno si aspetterebbe, con il rischio che per un sito venga proposto un certificato falso ma “valido” perché creato da una CA trusted compromessa. Comodo ha proposto in un draft IETF (nota, un draft proposto spontaneamente è ben lontano dall’essere un RFC, o anche un draft proposto da un gruppo di lavoro dell’IETF) un nuovo record DNS che indica quali sono le CA autorizzate ad emettere certificati per un certo dominio. Cito: “The Certification Authority Authorization (CAA) DNS Resource Record allows a DNS domain name holder to specify the Certification Authorities authorized to issue certificates for that domain.” E naturalmente, per aumentare la sicurezza del meccanismo suggeriscono di appoggiarsi a DNSSEC. In realtà, il meccanismo permette anche di inserire come record non il certificato di una CA, ma un certificato autofirmato.
Allora mi chiedo: io, gestore del dominio, mi devo preoccupare della correttezza di questo record e della protezione della chiave privata con cui firmarlo, perché altrimenti il record potrebbe essere sostituito ad esempio con un certificato autofirmato dell’attaccante. Ma se io curo così questo record, perché usarlo per reindirizzare ad una CA, e non metterci invece direttamente un mio certificato autofirmato? Quindi anche in questo caso, a quale scopo rivolgersi più a una CA? Ovvero, io, responsabile del dominio, firmo un record che delega a una CA il compito di firmare una chiave con cui garantisce una chiave privata che gestisco io? Mi pare abbastanza curioso.
Ma nessuno di questi meccanismi tocca il vero problema, ovvero che comunque è il gestore del dominio a scegliere di chi fidarsi, ma non sarebbe lui in realtà a dover fare questa scelta. Con SSL/TLS il certificato di un host serve principalmente per autenticare l’host nei confronti dei client, e in definitiva sono questi a doversi fidare. Se è l’host a scegliere la CA o la catena di trust, siamo alla situazione paradossale in cui Tizio si deve autenticare a Caio, ed è Tizio a indicare a Caio a chi chiedere conferma.
Esiste una terza “soluzione”. È una soluzione alla quale penso da tempo, ma non ho mai avuto molto tempo per verificarla… salvo accorgermi in questi giorni che ci aveva già pensato qualcun altro 😉 E dato che si tratta di Carnegie Mellon, probabilmente l’idea non è cattiva. Dunque: il problema di mettere in contatto due entità che non si sono conosciute prima non ha soluzione, quindi il meglio che si può fare è ridurre il rischio. Non potendo lavorare sull’impatto, lavoriamo sulla probabilità. Un modo per lavorare sulla probabilità è coinvolgere più entità che debbano colludere (o essere attaccate contemporaneamente) perché l’attacco abbia effetto. È il problema dei tre direttori di banca: se non mi fido a lasciare le chiavi a un solo direttore, metto tre serrature che devono essere aperte contemporaneamente, e a ogni direttore do una chiave di una delle tre serrature. Se il loro comportamento (la loro etica e sicurezza) sono abbastanza indipendenti, ho ridotto il rischio; aumentando i direttori, riduco la probabilità, di principio fino a un livello arbitrario accettabile. Ad esempio, se nell’handshake di TLS richiedessi che la chiave pubblica fosse certificata da due CA, e le CA fossero indipendenti, avrei lo stesso effetto… solo che bisognerebbe modificare TLS, e possiamo scommettere che si creerebbero degli accordi fra CA per fornire più certificati attraverso un’unica RA 😉 Da questo punto di vista, la proposta di Comodo sembrerebbe corretta: coinvolgo sia la CA che la catena di trust del DNS; purtroppo, nel momento in cui nel DNS posso mettere certificati autofirmati (e non sarebbe realistico ipotizzare di non poterlo fare) il meccanismo crolla. Quello che si può fare allora è avere più entità che verifichino indipendentemente che l’host che vogliamo contattare fornisca un certo certificato, lo stesso per tutti. Il punto importante è questo: non ci interessa sapere chi ha emesso il certificato, ci interessa che quell’host stia effettivamente presentando quel certificato. Per ingannare più sistemi che indipendentemente facciano la verifica, non basta più praticare un man-in-the-middle davanti ad una potenziale vittima, bisogna praticarlo davanti a tutti questi “notai”. Se questi sono sufficientemente ben distribuiti in giro per il mondo, per praticare un MitM bisogna mettersi davanti alle fonti l’host e/o il server DNS del suo dominio. Per come si sviluppa la maggior parte degli attacchi adesso, mettersi davanti al server web è generalmente molto, molto più difficile: pensiamo, nel phishing, alla difficoltà di mettersi davanti al server della banca rispetto alla difficoltà nel mettersi davanti a un suo cliente . Non solo: i “notai” sono sistemi specializzati che hanno una funzione specifica, e sono certamente più difficili da ingannare dell’utente. Naturalmente, ci sono una serie di dettagli che possono rendere più o meno efficace un servizio di questo genere, e direi anche economicamente profittevole (come dicevo, ci ho pensato un po’ sopra). Ma vorrei sottolineare che c’è una differenza fondamentale rispetto a tutti i meccanismi visti fino adesso: è l’utente a scegliersi i “notai”: è l’unico di questi meccanismi, in cui chi deve autenticare sceglie, finalmente, di chi fidarsi.
Aggiornamento: vedo questo post che aggiunge un’altra entità che non avevo esplicitamente considerato criticando l’impostazione di dane: i Registar
