Ok, la storia la sappiamo tutti: una Registration Authority di Comodo è stata compromessa, qualcuno ha prodotto delle richieste di certificato che sono state processate (in parte? Comodo sembra non saperlo) emettendo dei certificati. Successivamente, seppure in tempi brevi, il problema è stato rilevato e i certificati sono stati revocati. La compromissione pare sia partita da un partner di Comodo del sudeuropa… I produttori dei principali browser hanno rilasciato degli update per (immagino) invalidare specificamente quei nove certificati fasulli. Comodo ha precisato che la CA non è stata compromessa (solo una RA) e che in particolare la chiave della CA non è stata compromessa. Fine del problema, pare. Eppure a me rimangono un po’ di perplessità. Per spiegare quali sono devo partire un po’ dall’inizio, ma chi ha già idea di dove vado a parare con le premesse può saltare alla fine, dove comunque c’è qualche considerazione sul caso specifico di Comodo.
Una buona parte dei problemi di sicurezza interessanti in teoria non avrebbe una soluzione. Ad esempio, il problema di autenticare due entità che non sono state in contatto precedentemente (e quindi non hanno potuto concordare un segreto condiviso) sarebbe senza soluzione: non è possibile un “riconoscimento” (che non a caso comincia con “ri”) senza che prima ci sia stato un contatto. Lo stesso vale per molti altri problemi. Cosa si fa allora? Si “concentra” il problema in un sottosistema, e si considera che quel sottosistema svolga il proprio compito correttamente “per definizione”. Una volta fatto questo magheggio, tutto il resto viene da sè. Un esempio “sistemistico ” è il reference monitor, che controlla gli accessi da soggetti a oggetti: come si garantisce la sicurezza del meccanismo (che ci deve essere) con cui si configura il reference monitor? Il problema in realtà non si pone: il reference monitor funziona, punto. Se si entrasse nel merito, si finirebbe in una spirale senza fine. Lo stesso problema, dal punto di vista organizzativo, si ha con gli amministratori di sistema, conl’abusato “Quis custodiet ipsos custodes?”. E della categoria dei “magheggi” fanno parte naturalmente le terze parti fidate, ovvero quelle entità che “ci si fida” che svolgano correttamente uno specifico compito. Quando un problema difficile è risolto con una terza parte fidata, potete scommettere che tutto il problema è stato solo spostato sulla terza parte fidata, che a quel punto diventa “il problema”: se funziona lei, tutto funziona; se lei non funziona, crolla tutto. Per il problema di autenticare due entità che non hanno mai avuto contatti prima, la soluzione è la Certification Authority, che è appunto la terza parte fidata su cui è stato “concentrato” tutto il problema. Per autenticare le due entità che non hanno mai avuto contatti fra di loro, entrambe hanno avuto prima contatti con la Certification Authority, e dopo una qualche autenticazione una ha ottenuto l’emissione di un certificato, l’altra la chiave pubblica della Certification Authority. Ma abbiamo detto che il problema non ha soluzione, e infatti ci dovremmo chiedere: come si è autenticato alla CA chi ottiene il certificato, e come si è autenticata la CA a chi ottiene la chiave pubblica? Questa è la parte che chi si fida della CA (come TLS, ad esempio) non guarda e dà come funzionante “per definizione”. Ma nel mondo reale niente funziona “per definizione” ed eccoci alla differenza fra teoria e pratica, e fra una CA teorica e Comodo. Non che ce l’abbia con Comodo in particolare, naturalmente. Nel mondo reale, la CA si deve porre il problema di come autenticare chi richiede un certificato, e qui compare la Registration Authority (non sto a spiegare cosa, fa, si trova tutto su Wikipedia …incredibilmente, su Wikipedia non l’ho trovato, comunque basta Google). Ma siccome il problema non ha soluzione la RA di fatto non fa altro che appoggiarsi ad un altro meccanismo, ad esempio una carta d’identità. Comunque sia, una volta passato lo scoglio di farsi accettare da una RA, il più è fatto: l’emissione e la firma del certificato da parte di una CA è un passaggio sostanzialmente meccanico. Ma abbiamo un altro passaggio importante: Comodo, come direi più o meno tutte le CA, ha dei “partner”, perché, per farla semplice, controllare le carte d’identità richiede che qualcuno sia fisicamente sul posto per farlo (per non parlare dell’attività commerciale). Ed ecco che la RA diventa una struttura che comprende altre organizzazioni, che a loro volta diventano componenti della terza parte fidata: se loro non funzionano, non funziona il controllo della carta d’identità, e si riescono a far passare alla CA delle richieste di certificati che lei, meccanicamente, firma. Ed ecco che diventa più evidente la rilevanza della RA, e che quindi non è necessario arrivare a compromettere la CA o la sua chiave privata.
Torniamo ora alla CA come terza parte fidata. È fidata sulla sua funzione di associare chiavi pubbliche a identità… ma fidata per chi? Domanda meno ovvia di quello che sembra. È fidata per chi deve autenticare. Nel caso di TLS (o HTTPS) è tipicamente il client, ovvero il browser, ovvero alla fine “l’utente”, e chi si autentica è il server. Ma naturalmente chi sceglie il certificato da presentare è il server, e quindi come si incontrano la fiducia che il client deve mettere in una CA (di sua scelta/fiducia) con il fatto che è il server a scegliere da chi comprare il certificato? Anche questa è cosa nota, e mostra ancora di più la differenza fra il modello teorico e quello che ha realizzato il mercato: infatti meccanismi di mercato (e non di fiducia o terze parti o altro) fanno sì che la maggior parte dei siti usi certificati emessi da CA che sono già “incluse” nelle distribuzioni dei browser.Per completare il quadro manca un ultimo tassello: per come sono gestite le CA nei browser, se un sito si presenta con un certificato valido per una qualsiasi delle CA “fidate”, viene accettato. Questo vuole dire che se una qualsiasi di queste CA viene fraudolentemente convinta ad emettere un certificato per www.example.com, quel certificato viene accettato dal browser a prescindere dalla CA alla quale si appoggia effettivamente example.com. O, per dirla più chiaramente, la compromissione di una CA qualsiasi fra quelle fidate per il browser rende irrilevante la sicurezza di tutte le altre. E per quanto detto sopra, la compromissione di un qualsiasi parner di una qualsiasi di queste CA, se questi ha accesso ad una RA della CA, rende irrilevante la sicurezza di tutto il resto. È questo il bello di aver concentrato tutto il problema sulla sicurezza della CA 😉 Questo vuole dire che la sicurezza delle comunicazioni di un qualsiasi browser con un qualsiasi sito, in generale anche interno della stessa azienda, dipende dalla sicurezza dell’ultimo dei più sconosciuti partner dell’ultima delle CA accettate dal browser. Una bella dose di fiducia che ognuno di noi sparge per il mondo… ma il modello non prevedeva di “concentrare” il problema di fiducia su un sottosistema? 😉
Tutto questo la maggior parte degli utenti questo non lo sa: la maggior parte degli utenti è stata per anni bombardata con il concetto che “il lucchetto vuole dire che il sito è sicuro”, punto. Quindi, la maggior parte degli utenti di fatto si fida ciecamente (letteralmente) di chi è stato scelto dal produttore del browser. A questo punto, una domanda sorge spontanea: di fronte a tanta fiducia, in base a cosa i produttori dei browser scelgono le CA in cui riporre tutta questa fiducia? Un malfidato come me direbbe semplicemente: in base ad accordi commerciali. Ma naturalmente qualcun’altro potrà dire che forse ci sono, e a volte certamente ci sono, degli accordi commerciali, ma il produttore del browser certamente verifica anche che le caratteristiche di sicurezza della CA siano tali da non mettere a rischio gli utenti del browser. Solo che quando pensiamo a controlli di questo tipo, pensiamo al più (e con molto ottimismo) a controlli presso la CA… e le RA, e i partner in giro per il mondo?Non dobbiamo dimenticare che le CA sono in un mercato che necessariamente punta al risparmio: se dovete scegliere un certificato per il vostro sito web, chi scegliete? Di fatto, non siete in grado di valutare personalmente la sicurezza di una CA, posto che vi interessi: l’unica cosa che potete valutare è il prezzo, il che spinge naturalmente le CA verso la riduzione dei costi, l’automazione eccetera. I soliti meccanismi, insomma.
Però qui torniamo alla questione Comodo. È chiaro che un problema di sicurezza almeno presso il suo partner c’è stato. Visto che alla fine tutto dipende dalle scelte dei produttori di browser, direi che questi, anziché liquidare tutto con “abbiamo invalidato i certificati”, avrebbero dovuto dire: “Visto che vi abbiamo sempre raccontato che pretendiamo una certa sicurezza da parte delle CA (vedi qui, ad esempio) e c’è stato un problema di sicurezza, stiamo verificando che effettivamente la CA offra le garanzie che dichiara e questo sia stato sono uno sfortunato incidente”. Ma invece non ho visto niente di tutto questo. Anzi, cercando traccia di queste verifiche vedo che non è facile neanche capire come o se effettivamente i produttori di browser facciano mai qualche controllo, al di là del prendere per buone le dichiarazioni delle CA.
Naturalmente, stando così le cose, un’ultima domanda sorge spontanea: non è che il motivo per cui si è sentito tanto parlare di questo incidente è che sono stati richiesti certificati per siti “molto pubblici” (Yahoo, Google eccetera) e quindi la cosa non poteva passare facilmente sotto silenzio, ma magari “occasionalmente” qualcuno fra questa miriade di CA e loro partner che costituiscono la nostra terza parte fidata viene compromesso, anche abitualmente (che so, dalle autorità del suo paese) per emettere certificati usati per attacchi più “mirati”? E se il partner non se ne accorge e la CA nemmeno, o fanno finta di niente, chi mai lo verrebbe a sapere? Chi è che, alla fine, fa un qualsiasi controllo sul fatto che tutta questa folla sia realmente fidata?
Ottimo articolo!