Certificate Transparency (CT) ha avuto un tale successo che la maggior parte delle persone la considera un componente obbligatorio dell'ecosistema PKI pubblico. Probabilmente ciò accade perché la maggior parte di noi ha solitamente a che fare solo con certificati destinati ai siti web e, per questi, CT è obbligatorio… più o meno, ma in realtà non necessariamente.
La verità è che CT non è mai entrato nell'agenda del CA/Browser Forum e non è presente nei Baseline Requirements, il documento principale utilizzato per regolamentare l'emissione dei certificati. Ci sono diversi riferimenti ai precertificati (un artefatto dell'implementazione di CT), ma nessuna indicazione su se le CA debbano utilizzare CT. In teoria, e spesso anche in pratica, CT resta opzionale.
Come Funziona Certificate Transparency?
Certificate Transparency è un meccanismo progettato per imporre un livello di controllo su ciò che fanno le autorità di certificazione fidate (CA). Queste CA sono al centro della Web PKI e hanno il potere di emettere certificati per qualsiasi proprietà nel mondo, senza alcun controllo tecnico. Storicamente, questo ha causato molti problemi.
CT ribalta l'equilibrio richiedendo che tutti i certificati emessi vengano registrati (logged), ovvero resi pubblici. Come parte del processo di emissione, le CA inviano i loro certificati ai log CT e vi incorporano le firme di tali invii. È fondamentale che CT venga fatto rispettare dagli user agent, che hanno il potere di rifiutare qualsiasi certificato per il quale non esista una prova di registrazione sufficiente.
In che modo questo ci aiuta? Beh, costringe i malintenzionati ad agire allo scoperto. Se qualcuno diverso da te ottiene un certificato per una delle tue proprietà, ora sei in grado di osservarlo nel flusso globale dei certificati pubblici e reagire. Nessuno si sveglia un giorno e decide di monitorare il flusso continuo dei log CT, ma esistono aziende che offrono il monitoraggio come servizio (Red Sift è una di queste).
È fondamentale avere un sistema di monitoraggio attivo: se non lo hai, non succede nulla. Ad esempio, un paio di anni fa, le forze dell'ordine [presumibilmente] in Germania ottennero un certificato per jabber.ru e lo utilizzarono per intercettare il traffico XMPP. Il certificato era presente nei log CT, ma nessuno lo stava osservando, e l'intercettazione rimase attiva e non rilevata più a lungo. In un altro caso, FINA, una piccola CA croata, aveva emesso ripetutamente certificati errati per l'indirizzo IP 1.1.1.1 appartenente a Cloudflare, senza essere scoperta per molti mesi.
Sul lato positivo, anche se non stai monitorando CT, ottieni comunque il beneficio della deterrenza, poiché i certificati emessi in modo errato rimangono per sempre come registro pubblico. I tuoi avversari potrebbero non sapere se li stai monitorando oppure no.
Chi Richiede Certificate Transparency?
Abbiamo già stabilito che, tecnicamente parlando, CT non è obbligatorio. Tuttavia, capita che alcuni dei maggiori consumatori di certificati lo richiedano. Apple, Google, Microsoft e Mozilla richiedono tutti CT in diversi punti dei loro prodotti. In pratica, se pubblichi un sito web destinato a essere fruito tramite un browser, devi utilizzare un certificato pubblicato su CT.
Ma non tutti gli user agent sono browser, e Internet non si riduce ai soli siti web.
Un problema intrinseco di CT è che viene fatto rispettare a livello di client. Molti client che non sono compatibili con CT non offrono alcuna protezione. Per questo motivo, i tuoi avversari possono ignorare completamente CT, e tu non ottieni il beneficio della sua protezione.
I browser moderni richiedono CT, così come le librerie di rete ufficiali sulle piattaforme Apple e, recentemente, anche Android. Tuttavia, esiste un'intera gamma di linguaggi di programmazione e librerie TLS che non se ne preoccupano affatto. Praticamente tutto ciò che non è un browser ignorerà CT. I tuoi server API, anche se oggi stai utilizzando certificati CT, non sono effettivamente protetti da CT. La comunicazione server-to-server (ad esempio, SMTP) è ugualmente a rischio. Per certi casi d'uso, CT non offre alcun beneficio.
Colmare il Divario
Nel lungo termine, l'unica soluzione è che CT venga integrato nei Baseline Requirements, il che probabilmente accadrà solo se uno degli store di root deciderà di richiederlo.
La situazione è complicata dalla migrazione post-quantistica. Per affrontare la minaccia incombente di un computer quantistico crittograficamente rilevante, Google sta lavorando a un nuovo tipo di certificato, chiamato Merkle Tree Certificates (MTC). Come parte di questo sforzo, Certificate Transparency verrà ricostruito e combinato con l'emissione dei certificati. È possibile che in futuro avremo due tipi di certificati: MTC e X.509 con crittografia post-quantistica. Il primo avrà il vantaggio della trasparenza, ma non è chiaro cosa accadrà nel secondo caso.
Tuttavia, esiste una soluzione.
Senza alcuna azione da parte tua, qualsiasi CA può emettere un certificato per uno qualsiasi dei tuoi nomi di dominio. Tuttavia, esiste un meccanismo che ti consente di limitare l'emissione per singola CA, e persino per singolo account CA. Si chiama Certification Authority Authorization (CAA). CAA può essere utilizzato per creare e distribuire policy di emissione che tutte le CA devono rispettare. Questo meccanismo non è infallibile, ma il suo supporto è obbligatorio per tutte le CA.
Per colmare il divario di visibilità di CT, devi solo scegliere di fare affari con CA impegnate a registrare tutti i loro certificati su CT. Let's Encrypt, la più grande CA per numero di emissioni e gratuita, ha sempre registrato tutto. Probabilmente esistono altre CA che fanno lo stesso; se non ne sei sicuro, chiedi alla tua CA una dichiarazione ufficiale in merito.
Come esempio di uno sviluppo positivo, Amazon e DigiCert si sono recentemente impegnati a registrare anch'essi tutto. Le loro decisioni potrebbero essere legate ai cambiamenti recentemente apportati da Chrome in questo ambito. Secondo il testo della versione 1.8 della loro root policy, la registrazione dei precertificati è obbligatoria, mentre la registrazione dei certificati rimane un SHOULD.
Se vuoi saperne di più, abbiamo un whitepaper che approfondisce come colmare il divario di visibilità di CT e utilizzare CAA per affermare il controllo sui tuoi ambienti PKI pubblici: High-Assurance Certificate Transparency Monitoring. Questa guida può aiutarti a colmare il divario di visibilità di CT, ma anche in altri aspetti della sicurezza PKI, incluso il raggiungimento del santo graal della PKI: una solida validazione crittografica dell'emissione dei certificati.
Ivan Ristic is the Chief Scientist for Red Sift and former founder of Hardenize. Learn more about how Red Sift helps organizations with their Certificate Monitoring.