Certificate Transparency

Trust, but verify. - Ronald Reagan

Introduzione

Al giorno d'oggi sebbene il phishing sia una tecnica da molti considerata rétro, essa è molto utilizzata e continua a mietere diverse vittime. Sempre più spesso si sente parlare di svariate contromisure e la maggior parte dei browser moderni si è attivata per mettere in atto alcune misure allo scopo di aiutare gli utenti a non cadere in potenziali trappole. Una delle best practices più gettonate consiste nel prestare attenzione al famoso lucchetto verde. Il significato che si nasconde dietro quest'ultimo risulterà più chiaro una volta introdotto il concetto di certificazione. Un sito web che ci viene mostrato dal browser con tale lucchetto utilizza il protocollo HTTPS (HTTP over TLS) ai fini di una comunicazione sicura e di un'autenticazione del sito stesso. A certificare quest'ultima sono le Certification Authority (CA), enti emettenti appositi certificati digitali i quali dichiarano che un determinato sito web foobar.com appartiene al relativo proprietario. Prima di proseguire è bene esporre in maniera più dettagliata il concetto di certificato digitale. Si tratta di un documento digitale (standard X.509) che serve a provare la proprietà, da parte di un entità, di una chiave crittografica pubblica alla quale si associa una scadenza.

HTTP vs HTTPS

In questa sezione analizzeremo l'importanza della certificazione, mettendo in luce alcune relative criticità, e proporremo la Certificate Transparency, uno standard di sicurezza ed un framework open source atto a monitorare e raccogliere certificati digitali, come possibile soluzione a tali problematiche.

Problema

Quando ci si ritrova a discutere sulla certificazione, un ruolo fondamentale è giocato dal trust, ovvero dalla fiducia che riponiamo alle Certification Authority. A questo proposito, si parla di catene - anche se in realtà sono propriamente degli alberi - di Certification Authority. Iniziamo col dire che la crittografia, in particolare quella asimmetrica (o a chiave pubblica), è lo strumento cardine che governa la struttura. Alla base di una catena vi è una Root Certification Authority (RCA), la quale firma i certificati per le CA di livello inferiore, le quali a loro volta sottoscrivono i certificati per le CA loro immediatamente sottostanti e così via. È bene osservare che solamente le RCA auto-firmano i propri certificati, pertanto si evince una maggiore criticità legata al trust nella base della catena. Nel momento in cui viene richiesto di effettuare una richiesta HTTPS al browser, questo si preoccuperà di risolvere la catena, dalla quale deriva il certificato di quel sito, per verificarne la validità. È bene osservare che tale procedimento si riduce ad una verifica a cascata di chiavi crittografiche pubbliche. In aggiunta, per migliorare le prestazioni dovute alla latenza di rete e per ulteriori motivazioni legate al trust, solitamente un browser gestisce una whitelist delle catene che ha già verificato, la quale è da considerarsi come una sorta di cache periodicamente aggiornata per evitare di considerare certificati scaduti e, quindi, non più validi. Oltre alla whitelist è possibile gestire anche la corrispondente duale, la blacklist, in cui vengono contrassegnate le CA con firme non valide.
Fino a questo punto sembra essere "tutto rose e fiori". Ciò nonostante, sorge un problema per nulla indifferente sollevato dalla seguente domanda: cosa succederebbe se un utente malevolo riuscisse a certificare il proprio sito creato ad hoc per i suoi scopi? Prima di replicare, è necessario attenzionare la semantica che sta dietro il verbo "certificare". Infatti, poichè trattasi di chiavi crittografiche, nessuno vieta di creare una propria RCA home-made - ricordiamo che le RCA sono auto-firmate - ed iniziare a firmare certificati per siti potenzialmente malevoli. In questo caso il certificato è, e va trattato, come valido nel suo senso proprio, poiché l'aggettivo falso qualificherebbe l'eventuale intento fraudolento dello stesso. Evidenziamo che questa accezione non viene imposta dalla crittografia ma siamo noi che, conoscendo e deducendo il comportamento malevolo del sito, associamo - riprenderemo questo discorso quando parleremo di double-spending nell'ultima sezione - l'aggettivo "falso" al certificato.

A rendere le cose leggermente più complicate all'utente malintenzionato, in aggiunta alle whitelist/blacklist, è il lato economico. Infatti, mettere su un'infrastruttura ai fini di certificazione fraudolenta ha senza dubbio un costo. Pertanto l'eventuale attaccante si ritrova a dover effettuare un'analisi costi-benefici - si veda Security Economics sotto un punto di vista di un attaccante - per poter stabilire se il gioco valga la candela. Tuttavia, esiste una ormai famosa Certification Authority che emette, in modo completamente gratuito, certificati.
A questo proposito prenderemo in analisi un rilevante caso reale che ha come protagonista proprio tale ente.

Esempio

Let's Encrypt è una Certification Authority non-profit che offre certificati - X.509 seguendo lo standard - in maniera del tutto gratuita. Sebbene si tratti di un'interessante iniziativa, sono e continuano a essere molti gli attacchi di phishing legati all'emissione di certificati fraudolenti firmati da parte di questa CA. Giusto per citarne qualcuno, molteplici sono stati i tentativi di creare un sito malevolo simile a paypal.com, raggiungibile mediante protocollo HTTPS, aventi certificati firmati proprio da Let'Encrypt. Ma ciò che rende quest'ultima "un'arma a doppio taglio" è la completa automatizzazione dei processi di certificazione e di rinnovo, grazie ai quali un utente malevolo non deve far altro che sottoporre richiesta di certificazione per il proprio dominio myevilsite.com, senza avere altre preoccupazioni. È sufficiente aspettare circa due giorni affinché le firme si propaghino nella catena e, una volta completato il processo, il gioco sarà fatto: in pochissimo tempo - prima che il sito fraudolento venga scoperto e segnalato - è possibile creare tutti i siti di phishing che si vogliono e renderli accessibili tramite protocollo HTTPS, così che vengano mostrati agli utenti dai browser con il lucchetto verde!

Let's Encrypt Logo

Tuttavia è bene osservare che non tutti i certificati firmati da Let's Encrypt sono ingannevoli, dunque questa autorità certificante non deve essere considerata nel complesso come una untrusted CA. Nonostante la nostra precisazione però, un utente che non abbia un po' di sensibilità sul problema della certificazione non sarà, negli scenari che abbiamo descritto, guidato dal browser, in base al lucchetto verde o meno, nelle sue scelte di navigazione dei siti web.

Soluzioni

Una delle possibili soluzioni, molto "famosa" negli ultimi tempi, è costituita dalla Certificate Transparency (CT), il cui core si basa sul mantenere dei log pubblici - in tal modo tutti possono avervi accesso - contenenti tutti i certificati utilizzati su Internet e considerati affidabili dai browser. La prima Certification Authority che ha implementato la CT è stata DigiCert nel 2013, qualche mese dopo che Google ebbe lanciato il suo primo log di Certificate Transparency.
Entriamo quindi, un po' nel dettaglio della struttura di una CT. Ogni log inserisce nuovi certificati ad un sempre crescente Merkle hash tree, una particolare struttura dati ad albero molto utilizzato in crittografia - ritroveremo questa struttura nell'ultima sezione quando parleremo di crittovalute - nel quale ogni foglia è etichettata con l'hash di un blocco di dati e i nodi interni con l'hash crittografico delle etichette dei propri figli. In questo modo viene garantita un'importante proprietà di sicurezza, l'integrità dei dati. Inoltre, ai fini di essere considerato valido, è necessario che ogni log rispetti le seguenti regole:

verificare che un certificato abbia una catena di firme valida riconducibile ad una trusted CA;
rifiutarsi di pubblicare un certificato che manca di una catena di firme valida;
salvare l'intera catena di verifica di un nuovo certificato fino ad una trusted RCA;
fornire tale catena su richiesta per essere consultata.

All'interno di un log è possibile trovare anche certificati non ancora del tutto verificati e/o scaduti. Nell'ecosistema della Certificate Transparency troviamo due ruoli principali: i monitor e gli auditor. Entrambi si presentano come client ai log server. I primi si occupano di controllare il corretto comportamento dei log, i secondi utilizzano informazioni parziali su un determinato log per verificarne la validità contro altre informazioni che posseggono.

Certificate Transparency Scheme

Grazie alla Certificate Transparency, dunque, è possibile monitorare i certificati relativi ai propri domini ed essere in grado di scovare in real-time se un utente malevolo, o più in generale una "falsa" - vi invito ancora una volta a riflettere sull'aggettivo, analogamente a quanto abbiamo discusso poc'anzi - Certification Authority, ha firmato un certificato fraudolento. In tal modo si possono individuare in poco tempo eventuali scenari di phishing, segnalando a chi di competenza la frode al più presto, evitando così che ci possano essere degli utenti che cadano nel tranello.

Conclusioni

Avendo analizzato gli aspetti più cruciali della certificazione ci siamo resi conto di alcune problematiche che a colpo d'occhio non sembrano essere particolarmente trasparenti all'utente. Eppure abbiamo descritto come un utente potenzialmente malevolo possa facilmente ingannare il tanto ritenuto sicuro lucchetto verde, sfruttando un servizio gratuito quale Let's Encrypt. In conclusione, si comprende facilmente che la Certification Transparency può essere un potente strumento per il monitoraggio dei certificati emessi da più di una specifica Certification Authority - in effetti abbiamo affermato che lo scopo è quello di inglobarle tutte - e si presta molto bene come possibile contromisura a certificati validi ma emessi per scopi illeciti.

Introduzione

Problema

Esempio

Soluzioni

Conclusioni

References