I certificati digitali e gli attacchi subiti dalle autorità di certificazione: l'accaduto e le difese da porre in campo

I certificati digitali vengono utilizzati per attestare l'identità di un sito web (così come di un soggetto, di una società, di un sistema e così via).

I certificati digitali vengono utilizzati per attestare l’identità di un sito web (così come di un soggetto, di una società, di un sistema e così via). Sul web, l’uso più comune dei certificati digitali è per l’accesso ai siti attraverso il protocollo HTTPS (ossia HTTP con l’aggiunta del protocollo crittografico SSL). Ricorrendo all’impiego dei certificati digitali, il browser web può accertarsi che il server a cui si è connessi sia autentico ossia che corrisponda effettivamente a quello che dichiara di essere. Se il certificato è stato firmato da un’autorità di certificazione riconosciuta, il browser provvede ad utilizzare la chiave pubblica indicata nel documento digitale per scambiare dati in modo sicuro, senza la possibilità che vengano in qualche modo essere intercettati.

Nei giorni scorsi la certification authority (CA) olandese DigiNotar ha subìto un pesante attacco informatico che ha permesso, all’aggressore, di emettere – in modo fraudolento – numerosi certificati digitali per una serie di domini Internet gestiti da famose società (Google, Mozilla, Microsoft, WordPress, Facebook, Logmein, Twitter, Skype, AOL, TorProject,…) oltre che da agenzie di intelligence.

I certificati digitali nell’occhio del ciclone potrebbero essere sfruttati, da parte dei malintenzionati che lo hanno ottenuto, per condurre attacchi phishing persuadendo l’utente di trovarsi in uno dei siti di proprietà delle società citate. In particolare, il “documento digitale” fraudolento potrebbe essere adoperato per sferrare attacchi man-in-the-middle con la possibilità, quindi, di sottrarre informazioni personali e porre in essere truffe di vario genere.

Secondo i report pubblicati, l’incursione subita da DigiNotar sarebbe stata piuttosto pesante. Gli amministratori del progetto “Tor” – sistema di comunicazione anonima basato sull’utilizzo di speciali onion router, gestiti da volontari – hanno dapprima comunicato di aver ricevuto dal governo olandese un foglio elettronico con l’elenco di ben 531 certificati digitali riconosciuti come “fasulli” ed attivati in seguito all’attacco sferrato nei confronti di DigiNotar.

Tra i certificati richiesti e registrati in modo illecito vi sarebbero numerose istanze di agenzie di intelligence quali www.sis.gov.uk, www.cia.gov e *.mossad.gov.il oltre che domini quali microsoft.com, windowsupdate.com, login.live.com, skype.com, facebook.com, twitter.com, aol.com, logmein.com ed android.com. Sono stati rilasciati anche certificati definiti “i più bizzarri in assoluto” come *.*.com e *.*.org che però dovrebbero essere comunque accettati dalla maggior parte dei browser.
Nell’elenco reso pubblico da “Tor“, ci sono anche certificati emessi in nome di altre autorità come “VeriSign Root CA”, “Thawte Root CA” ed “Equifax Root CA” mentre si trova riscontro dei certificati fasulli inizialmente individuati (google.com, wordpress.com, addons.mozilla.org, login.yahoo.com e torproject.org).

Il numero dei certificati fraudolenti è, insomma, impressionante e già gli esperti bollano quest’incidente come il più grave mai accaduto nella storia delle “certification authorities”.

I nomi degli autori dell’aggressione non sono noti e non è dato sapere quanti certificati siano stati impiegati per monitorare le attività svolte in Rete da parte degli utenti. Come conferma Trend Micro, si sa solamente che il traffico di Google Gmail sia stato oggetto, in Iran, di spionaggio e che quindi le informazioni in transito possano essere state sottratte da parte di un gruppo di malintenzionati.
Secondo gli amministratori del progetto “Tor” in uno dei certificati fasulli vi sarebbe comunque un possibile indizio circa l’autore della scorribanda messa in atto ai danni di DigiNotar.

In realtà, il cracker che ha messo in atto l’offensiva nei confronti di DigiNotar avrebbe già deciso di far sentire la sua voce. Con un post pubblicato sul servizio pastebin, l’aggressore ha rivendicato l’attacco sferrato nei confronti di DigiNotar. “Chiedete ragguagli, agli amministratori di DigiNotar, circa la seguente combinazione di nome utente e password“, ha scritto spiegando di essere già in grado di accedere ad ulteriori quattro CA “di alto profilo” e di possedere quindi gli strumenti per emettere nuovi certificati digitali fraudolenti. Mikko Hypponen, chief research officer presso la finlandese F-Secure, ritiene che il messaggio apparso su pastebin sia veritiero.

Secondo il resoconto pubblicato dalla società di consulenza Fox-IT, trasmesso alle autorità olandesi, la rete e le procedure adottate da DigiNotar non erano considerabili come “sufficientemente sicure” e, quindi, inadeguate alla prevenzione di eventuali attacchi informatici. “Il software installato sui server web pubblici era obsoleto e non patchato. Sui server oggetto d’investigazione non era nemmeno presente una soluzione antivirus“, sostengono gli esperti di Fox-IT.

Da parte sua, Microsoft ha dichiarato che i certificati digitali generati dall’aggressore non potranno comunque essere sfruttati per veicolare malware agli utenti che ricorrono al servizio Windows Update (alcuni dei documenti fasulli che sono stati emessi riguardano proprio i domini windowsupdate.com, update.microsoft.com e *.microsoft.com). “Gli aggressori non possono essere in grado di impostare un certificato Windows Update fraudolente che possa essere sfruttato per installare malware attraverso i server di Windows Update“, ha dichiarato Jonathan Ness, uno degli ingegneri del Microsoft Security Response Center (MSRC). “Il client di Windows Update installa solamente i file binari che sono firmati con il reale certificato root di Microsoft: esso viene emesso solo dalla nostra azienda“, ha spiegato.

Non è solamente Microsoft a firmare i suoi aggiornamenti con un certificato digitale separato: anche Apple, ad esempio, ha seguito la medesima strada.

I certificati digitali prodotti illecitamente dall’aggressore possono essere utilizzati da parte dei criminali informatici per condurre attacchi del tipo “man-in-the-middle” (MITM). Persuadendo l’utente a visitare un certo sito web, il malintenzionato – grazie all’impiego del certificato fraudolento – avrà la possibilità di “spiare” il traffico di rete estrapolando informazioni personali e dati sensibili in transito sulla connessione cifrata.
Si tratta di un attacco estremamente subdolo dal momento che quelli che noi stessi chiamiamo “certificati fasulli” sono, putroppo, tecnicamente autentici perché emessi da una CA riconosciuta. Ad oggi, infatti, tutti i browser web – nell’attuale modello di fiducia – considerano validi i certificati rilasciati da parte di qualunque nota autorità.

Microsoft ha aggiunto la sua voce al coro di critiche nei confronti di DigiNotar evidenziando la serietà della situazione e, muovendosi nella medesima direzione di Google e Mozilla, ha annunciato il blocco di tutti i certificati digitali della CA olandese, compresi quelli impiegati dal governo dell’Aia.

Secondo l’indagine di Fox-IT, tra il 27 luglio ed il 29 agosto scorsi, circa 300.000 indirizzi IP avrebbero visitato siti web che veicolavano falsi certificati digitali *.google.com. Risultato? Gli aggressori sarebbero stati in grado di monitorare le informazioni contenute negli account Gmail di migliaia e migliaia di cittadini iraniani. “Utilizzando il cookie di autenticazione di Gmail“, hanno dichiarato i tecnici di Fox-IT, “il malintenzionato diventa così in grado di effettuare un login diretto alla casella di posta elettronica dell’utente e leggere tutte le e-mail in essa conservate“. Il medesimo approccio può essere sfruttato per guadagnare l’accesso a servizi quali Google Docs o Google Latitude.

Nel seguente video, Fox-IT mostra come la maggior parte delle richieste del certificato fraudolento *.google.com abbiano avuto origine dall’Iran:

Nelle scorse ore, i principali produttori di browser web si sono attivati non solo per bloccare i certificati “fasulli” emessi dal cracker in seguito all’attacco a DigiNotar. Anziché rendere inattendibili soltanto i certificati emessi in modo fraudolento, infatti, si è preferito “stralciare” tutte le root di DigiNotar e le relative PKI dichiarandole completamente inaffidabili. Si tratta di una mossa mai registrata nell’intera storia delle CA: DigiNotar, di fatto, appare così esclusa dal mercato: al bando sono stati così messi, infatti, non solo i certificati-tarocco ma anche quelli “buoni”, emessi prima dell’incidente.
Aggressioni che hanno portato all’emissione di certificati digitali “fasulli” sono state subìte, in passato, sia da Verisign (molti anni fa, nel 2002) che da Comodo (a marzo 2011; l’aggressore che ha attaccato DigiNotar afferma di essere stato l’unico protagonista dell’azione messa in campo nei confronti di Comodo).

Nel caso di Comodo, i certificati illecitamente attivati dall’aggressore furono pochi (ved. questa notizia) e, dopo una revoca immediata da parte della CA, i produttori dei browser – altrettanto rapidamente – disattivarono solo i documenti digitali fraudolenti. Per quanto riguarda DigiNotar, invece, l’aggiornamento destinato a tutte le versioni di Windows che Microsoft ha messo in distribuzione il 7 settembre 2011 – identificabile grazie all'”etichetta” KB2607712 – ha come obiettivo quello di forzare la disabilitazione di tutti i certificati emessi dalla CA olandese. Installando la patch KB2607712, infatti, il browser ed il sistema operativo non riterranno più affidabile la totalità dei certificati rilasciati da DigiNotar, compresi quelli utilizzati dal governo olandese.

Dopo l’installazione dell’aggiornamento, portandosi nel Pannello di controllo di Windows, quindi cliccando sull’icona Opzioni Internet, sulla scheda Contenuto, sul pulsante Certificati ed infine su Autori non attendibili, si potrà verificare come, in elenco, sia stata inserita proprio DigiNotar (con l’indicazione “Untrusted” ovvero “inaffidabile“).
Sia Internet Explorer che la versione Windows di Google Chrome fanno riferimento alla gestione dei certificati integrata in Windows cosicché, grazie all’intervento dei tecnici di Redmond, visitando un sito web che fa uso dei certificati DigiNotar, l’utente sarà immediatamente allertato.

Per quanto riguarda Firefox, invece, Mozilla ha rilasciato un aggiornamento (Firefox 6.0.2) che si comporta allo stesso modo bloccando in toto i documenti firmati da DigiNotar.

L’aggressore che ha rivendicato l’attacco a DigiNotar mediante un messaggio pubblicato sul servizio “Pastebin“, frattanto, ha precisato di essere in possesso degli strumenti per accedere ad ulteriori quattro famosissime autorità di certificazione. Avendo esplicitamente nominato GlobalSign, la società ha comunicato – in una nota ufficiale – di aver temporaneamente cessato l’emissione di nuovi certificati digitali intendendo procedere, prima, ad un’approfondita attività d’investigazione all’interno della propria infrastruttura. “Pubblicheremo aggiornamenti con la maggior frequenza possibile e ci scusiamo per l’inconveniente“, hanno dichiarato i responsabili di GlobalSign.

Il ventunenne che sta gettando lo scompiglio tra le CA di tutto il mondo ha poi lanciato una provocazione a Microsoft dichiarando di essere pienamente capace di rilasciare aggiornamenti Windows che appaiano uguali, in tutto e per tutto, a quelli veicolati dal colosso di Redmond.

Il tema CA e certificati digitali non è mai stato così “caldo” come in queste settimane. Abbiamo contattato Massimo Penco, fondatore di GlobalTrust, Vicepresidente EMEA del Gruppo Comodo e di CertifiedMail Inc. per avere un parere su quanto accaduto negli ultimi mesi e qualche indizio su ciò che succederà nel prossimo futuro.

La posizione di Comodo e l’analisi approfondita dell’accaduto

– Michele Nasi, IlSoftware.it: L’importanza del ruolo dei certificati digitali. Perché è importante che i siti web che gestiscono informazioni personali degli utenti è fondamentale abilitino il protocollo HTTPS?

Massimo Penco: Si parla molto spesso di certificati digitali dando a queste due parole un significato improprio. Il certificato digitale altro non è che la parte finale del complesso sistema per la creazione di una comunicazione sicura tra una entità ed un’altra. Nel caso del protocollo https, si tratta della creazione di un canale sicuro di comunicazione attraverso la rete Internet tra il sito web che ha la titoliaretà del certificato digitale ed un utente che entra in contatto con il sito web medesimo.
Quest’ultimo inizia ad entrare in possesso dei dati personali dell’utente solo quando questi inizia a comunicarli ai server del sito web. Ciò accade, ad esempio, per qualsiasi operazione legittima dove si richiedono dei dati personali (ad esempio, l’effettuazione di una procedura di login), necessari per l’erogazione del servizio.
E’ quindi l’utente unico e libero arbitro di rilasciare tutta una serie d’informazioni ad un sito web di cui ha fiducia. Tale libertà decisionale è il principio fondamentale su cui si basa la Rete.
Del resto, colui che si avvicina ad un sito web ha oggi tutte le informazioni necessarie per controllare se il sito a cui si sta collegando sia o meno sicuro.
Il protocollo SSL è solo un tassello, di importanza fondamentale, per trasmettere e ricevere qualsiasi tipo d’informazione con sicurezza. Si tratta comunque di un sistema imperfetto, come tutti quelli realizzati dall’uomo, dal momento che la “sicurezza totale” è una semplice utopia.
Un esempio banale? Se si allacciano le cinture di sicurezza in un’autovettura non vuol dire che non si abbiamo incidenti o che addirittura si rimanga illesi nel caso di uno scontro. Formare ed informare “gli utenti della strada” sui vantaggi derivanti dall’indossare la cintura di sicurezza e sui rischi collegati al mancato utilizzo ha aiutato a diffondere un senso di consapevolezza tanto che ora sono pochi i conducenti ed i passeggeri che non si servono delle cinture.

– L’autore di FireSheep (ved. questa pagina e quest’articolo) ha avuto, se non altro, il merito di riportare in auge il tema dell’insicurezza del “mezzo Internet” e dell’impellente necessità di cifrare i dati sensibili, non crede?

M.P.: Ogni tipo di contributo che spinga gli utenti e le organizzazioni a far capire che la sicurezza in Internet è necessaria ed anzi indispensabile è senz’altro benvenuto. Ma come detto in precedenza è una questione culturale: io mi trovo spesso costretto ad evidenziare come non via sia assolutamente nulla di misterioso nel “mezzo Internet”. I singoli individui e le organizzazioni debbono approcciarsi alla Rete utilizzando il medesimo senso comune che si usa nella vita di ogni giorno. Le aziende debbono comprendere che la sicurezza in Internet non è solo una voce di spesa ma soprattutto una ottima occasione di marketing e di fidelizzazione degli utenti.

– Gli amministratori di servizi quali Facebook, Twitter e così via hanno dimostrato una sufficiente sensibilità nell’affrontare la tematica e nell’abilitare tempestivamente l’impiego dei certificati digitali? Le connessioni HTTPS non dovrebbero essere attivate di default e non per scelta del singolo utente?

M.P.: Non solo i social network ma anche i motori di ricerca hanno recentemente riscoperto i certificati SSL. Ci sono molte ragioni per cui non erano mai stati utilizzati prima: la motivazione principale, ma ormai non più giustificabile, è il sensibile rallentamento della navigazione. Il problema è stato ormai superato sia grazie alla potenza di calcolo che contraddistingue personal computer e device portatili a disposizione di tutti gli utenti, sia dagli acceleratori creati appositamente per il protocollo SSL.
Personalmente, sono contrario a qualsiasi obbligo di usare questo tipo di protocollo stante per l’appunto la libertà nell’utilizzo di Internet. Considerato però, da un lato, l’aumento degli attacchi e, dall’altro, la generale scarsa consapevolezza dell’opinione pubblica sulle tematiche legate alla sicurezza, la miglior cura per questi due mail è probabilmente quella di rendere obbligatorio l’impiego del protocollo SSL come misura minima di sicurezza per tutti i siti web. Una “cintura di sicurezza”, insomma, che tutti dovrebbe adottare grazie all’assenza di controindicazioni e ai costi irrisori che l’amministratore del sito web verrebbe ad affrontare.

– Pochi sanno che i certificati digitali non sono tutti uguali. Può illustrare brevemente le differenze, ad esempio, tra certificati EV-SSL e DV-SSL?

M.P.: Il protocollo con cui viene generato un certificato SSL è in effetti sempre lo stesso da oltre 10 anni. L’evoluzione tecnica si è concentrata esclusivamente sulla robustezza della chiave crittografica. Come già puntualizzato, però, la procedura che consente di arrivare all’erogazione di un certificato digitale è molto complessa. La parte più complicata e costosa non è più la royalty sull’uso del protocollo di proprietà di RSA – ormai di pubblico dominio dal momento che il brevetto è “scaduto” – bensì le procedure di autenticazione e validazione di chi richiede il certificato SSL.
La procedura vede coinvolte tre entità, spesso accomunate in un’unica “figura” generando non poca confusione (in Italia, poi, la complessità del quadro viene ulteriormente esacerbata “grazie” ad una serie di leggi e regolamenti tecnici che creano una vera e propria “Torre di Babele” normativa).

Il mondo della certificazione digitale, in realtà, si muove su tre pilastri principali:

ROOT AUTHORITY: Detiene la chiave principale (“root”) indispensabile per la gestione dell’infrastruttura a chiavi pubbliche (PKI). Essa permette di far funzionare l’intero sistema e consente la generazione delle relative chiavi per il rilascio di tutte le chiavi pubbliche dei richiedenti. Il principale compito della root authority è quello di garantire l’integrità della “chiave master” oltre al funzionamento della PKI per l’erogazione dei certificati.
La rapidissima diffusione della rete Internet a livello globale, ha richiesto una successiva autorità intermedia definita come “crossing certification authority”: si tratta di una sorta di “prova del nove” della prima chiave o di un certificatore che ri-certifica la root authority. Al di fuori del “mondo digitale”, questa forma di ri-certificazione viene definita “apostilla” ed è usata per certificare il notaio primario (una specie di notaio che certifica il primo notaio).

CERTIFICATION AUTHORITY (CA): La “figura” della CA spesso coincide con l’ente denominato root authority. Il suo compito è il controllo approfondito dell’esistenza della proprietà del dominio, che il richiedente sia proprietario dello stesso o che comuqnue sia in possesso dei necessari poteri di rappresentanza e la verifica incrociata di tutte le informazioni fornite nella fase di richiesta del certificato attraverso l’accesso a database ufficiali come camere di commercio ed altre risorse.
Si tratta, come facilmente comprensibile, di una procedura piuttosto complessa che varia da Paese a Paese. A seconda delle varie disposizioni, la documentazione relativa deve essere conservata dalla CA per la stessa durata della chiave radice o “root key“, talvolta per vent’anni od oltre. Dal momento che la documentazione stessa viene redatta nella lingua originale di ogni singolo Paese, si è resa necessaria la creazione di una “registration authority” che di solito opera solo a livello locale.

REGISTRATION AUTHORITY: Ha la funzione di effettuare l’autenticazione e validazione dei richiedenti il certificato digitale su delega della CA con la quale si rapporta.
Tutte queste entità operano in tutto il mondo in base ad una best practice pubblica denominata Certificate Practice Statement (CPS) che ormai, dopo oltre 10 anni, è divenuta uno standard possibilmente da leggere prima di richiedere un certificato. All’interno di tale documentazione sono raccolte le condizioni di fornitura del certificato digitale, universalmente accettate e confermate da ogni singolo richiedente.

Le denominazioni EV, OV e DV rappresentano i diversi gradi di autenticazione e validazione del certificato. Contrariamente a quanto qualcuno crede, il certificato digitale nel suo formato tecnico è assolutamente identico. Ne consegue che il valore del certificato stesso ed il relativo costo è strettamente in relazione alle procedure di gestione che, come detto, sono le più dispendiose. Ogni tipo di certificato ha il proprio CPS legato per l’appunto al tipo di autenticazione e validazione eseguita.

DV Domain Validation: Per questo tipo di certificato viene effettuata la validazione solo a livello di intestazione del dominio. Si tratta del certificato più “scadente” sotto il profilo degli accertamenti che vengono fatti.

OV Organization Validation: Questo tipo di certificato richiede una completa autenticazione e validazione del richiedente. Vengono controllati:
– rispondenza tra il registro delle imprese ed il registro dei nomi a dominio. Molto spesso non si tende a considerare il registro dei nomi a dominio fondamentale. In realtà, esso rappresenta una vera e propria “anagrafe dei siti web”, una delle fonti d’informazione che qualsiasi utente può usare per controllare la proprietà degli stessi.
– estrazione del certificato di vigenza del registro imprese
– controllo della rispondenza dei dati (persone fisiche) dotati dei necessari poteri
– controllo della rispondenza degli indirizzi con utenze pubbliche (linee telefoniche, forniture di energia elettrica e così via)
– conferma telefonica con intervista dei dati di cui sopra
– ogni ed altro controllo necessario a stabilire quanto indicato

EV Extended Validation: E’ una forma di certificazione più approfondita ed avanzata dell’OV. In questo caso, viene richiesto un contatto diretto con il richiedente che firmerà apposita documentazione. Il processo da seguire è regolato dal CA/Browser Forum, consesso internazionale di tutti i produttori di browser web e delle CA che emettono certificati EV. E’ proprio il CA/Browser Forum che provvede ad aggiornare periodicamente “le regole del gioco”.
Nessuno ne parla, infatti, ma per poter esercitare il “mestiere” di CA a qualsiasi livello bisogna stipulare un’apposita polizza assicurativa che copre gli eventi relativi alla mala gestione.
Molti governi hanno cercato di regolamentare l’attività delle CA che in Europa è regolata dalla direttiva comunitaria 93/99, normativa ormai piuttosto per la quale sono state promesse revisioni non ancora attuate. Ad ogni modo, l’attività delle CA è sottoposta ad una verifica e l’autorità preposta, ormai unica al mondo, è WebTrust. Essa provvede a rilasciare apposite certificazioni che vengono pubblicate nei siti web delle CA e revisionate ogni anno.
Tutti i documenti relativi ad ogni certificato emesso sono soggetti ad “audit”. L’inserimento in qualsiasi un browser web come CA definita “attendibile” non viene effettuata se non si è in possesso della relativa certificazione.
Si tratta di procedure non bypassabili che costituiscono il requisito essenziale per il rilascio, da parte di una CA, di qualunque certificato digitale.

– Fino a qualche anno fa, soprattutto sui media “generalisti”, andava in voga un consiglio ricorrente: controllate la presenza del “lucchetto” visualizzato nella barra di stato del browser per accertarvi di utilizzare una “connessione sicura”. Già allora era un suggerimento fuorviante e del tutto incompleto. Oggi, perché gli aggressori hanno iniziato ad usare certificati digitali ed in che modo riescono ad ottenerli?

M.P.: Il famoso “lucchettino” visualizzato nel browser web o la più moderna “barra verde” che attesta l’impiego di un certificato EV non sono ovviamente garanzia assoluta di sicurezza.
Qualsiasi persona, oggi, può costruire un’entità truffaldina inesistente e malgrado tutti i controlli può riuscire a fornire documenti falsi alla CA. Per questo tipo di truffa, l’unico rimedio è quello di scegliere un certificato EV dove i controlli sono così approfonditi che è difficile riuscire ad ingannare la CA.
Un esempio concreto. Noi, in qualità di CA, abbiamo predisposto un servizio denominato “5 star” che non prevede l’invio di documentazione da parte del richiedente il certificato. Le informazioni, infatti, vengono estratte direttamente dalle fonti ufficiali. In passato ho potuto verificare personalmente come alcune aziende, pur di avere in tempi brevi un certificato senza aggiornare i dati presenti negli archivi pubblici, commettessero un falso cambiando un nominativo oppure un indirizzo. Tale prassi era piuttosto in voga soprattutto in forza della mancanza di strumenti legislativi adeguati che punissero tale mal costume. Solo con la “convenzione di Budapest” (l’Italia ha impiegato quattro anni per recepirla) sono state introdotte una serie sanzioni, anche di natura penale, a carico sia di chi fornisce false dichiarazioni sia dell’ente certificatore.

Un problema differente ma non meno critico è la penetrazione, da parte di malintenzionati, nel complicato sistema di una CA che più è complessa più risulta facile da attaccare. Si tratta di un tallone d’Achille difficilmente risolvibile, a mio modo di vedere, dal momento che non esistono sistema inespugnabili. Negli “incidenti” che si sono verificati sino ad oggi (Verisign nel 2002; Comodo nel 2011 e, più recentemente, l’olandese DigiNotar) nessuno ha affrontato il tema legato alla tempestività di reazione delle varie CA. Inoltre, quali sono gli obblighi in capo alle CA ed ai produttori di browser web nel caso in cui si verifichi l’emissione di certificati digitali in modo fraudolento?

L’unico obbligo che hanno le CA consiste nel revocare i certificati e pubblicare le liste di revoca in base alla tecnologia che si ha a disposizione. Il lettore interessato può controllare, per ogni singola CA, le corrispondenti liste di revoca constatando l’elevato numero dei certificati revocati.
Accanto a ciascuna voce non è ovviamente presente la motivazione per cui il certificato corrispondente è stato revocato: tra queste, però, ci sono numerosi certificati – per così dire – “fasulli”.

L’obbligo dei produttori di browser web, invece, è quello di pubblicare le liste di revoca. Su quale sia il sistema migliore per far questo si sta ancora discutendo ed ovviamente quando accadono episodi simili a quello di DigiNotar, si riaccende la polemica su chi, come e quando debba far qualcosa.

I cosiddetti “auditors” hanno l’obbligo di verificare l’accaduto, stabilire eventuali responsabilità ed ovviamente fare rapporto alla compagnia di assicurazioni ed alle autorità. La compagnia di assicurazioni, dal canto suo, è tenuta a risarciare gli eventuali danni (qualora questi venissero accertati).

– Recentemente si sono verificati degli incidenti che hanno coinvolto alcune autorità di certificazione. In due parole, gli aggressori sono riusciti a richiedere ed ottenere certificati digitali a nome di importanti società (quali Microsoft e Google) per poi utilizzarli, ad esempio, per allestire siti truffaldini (attacchi “phishing”) e persuadere l’utente circa la bontà del sito. Qual è la vostra posizione in merito?

M.P.: Per prima cosa, va rimarcato come nella vita delle CA gli incidenti non siano solamente quelli venuti a galla in tempi recenti. Gli ultimi sono stati evidenziati con particolare enfasi dai media e dal presunto aggressore che ha inteso dare la massima divulgazione all’evento (e devo dire che c’è riuscito in pieno).
Alcuni media e certi esperti (o presunti tali) hanno descritto alcuni casi recenti, a volte, in modo assolutamente discutibile, senza ovviamente conoscere come si erano verificati i fatti, prendendo per buono quanto pubblicato dal presunto hacker.

L’aggressore che, secondo quanto dichiarato, avrebbe messo in atto l’aggressione contro DigiNotar ha affermato di aver precedentemente violato anche Comodo. In qualità di vice presidente EMEA di Comodo, posso solo far osservare come i certificati SSL “fraudolenti” indicati pubblicamente non solo non siano mai stati utilizzati e conseguentemente non abbiano mai rappresentato pericolo per nessuno, ma che gli stessi sono stati revocati appena dopo 30 minuti dalla loro “generazione anomala”.

In precedenza ho descritto per sommi capi la procedura per il rilascio di certificati SSL dalla quale emerge chiaramente come la parte più complessa sia quella relativa alla autenticazione e validazione. Senza queste due procedure, il certificato digitale non può essere rilasciato.
Nel caso di Comodo, l’attaccante è riuscito a penetrare nel sistema PKI della società autorizzando l’emissione di alcuni certificati fraudolenti saltando così tutte le procedure comprese quelle di autenticazione e validazione. E’ ovvio che nessuno, in quel caso, ha validato richieste di certificati provenienti da nomi quali Mozilla, Google, Skype, Microsoft e così via.
Gli amministratori di Comodo si sono quindi visti arrivare una comunicazione relativa all’emissione di certificati che non erano passati attraverso la normale routine di autenticazione e validazione. Grazie a questo meccanismo abbiamo ricevuto un’allerta ed i certificati “fasulli” sono stati immediatamente revocati.

C’è però un problema di comunicazione di fondo tra CA e produttori di browser web. Le liste di revoca vengono pubblicate con tempi più lunghi ed è probabilmente questo il punto più critico. Nel caso di Comodo, fortunatamente, c’è stata una rapida risposta anche da parte dei produttori dei più famosi browser web.
La root key non è stata compromessa così come non è mai stata messa in discussione la parte relativa all’autenticazione e validazione dal momento che è stata bypassata dall’attaccante. Anzi, è stato proprio l’errore che l’aggressore ha compiuto e che ha permesso a Comodo di rilevare tempestivamente l’attacco.

– Alcuni analisti ritengono che l’attuale sistema di certificazione che poggia sulle CA abbia delle debolezze. Il dato che viene riferito è circa 650 organizzazioni di certificazione che, globalmente, avrebbero titolo per emettere certificati digitali. In un articolo apparso anche su un importante magazine statunitense si criticano le procedure di sicurezza usate da alcune CA e si fa notare non vi sia un procedimento automatico per la revoca dei certificati fasulli né un archivio pubblico dei documenti digitali via a via emessi. Qual è la sua opinione?

M.P.: In primis, non esistono in tutto il mondo 650 CA intese come da me descritto. In seconda battuta, non posso non rilevare come la perfezione non esista e non possa esistere.
Noi utilizziamo la nostra esperienza “sul campo” per prevenire eventuali incidenti, grazie anche ai penetration test che effettuiamo. Ovviamente, un’aggressione andata in porto è sintomo di una falla che c’è e che deve essere corretta. Nel nostro caso, comunque, le procedure da noi adottate hanno consentito di bloccare il problema nel nascere.
Come sottolineato in precedenza, non voglio entrare nella polemica relativa al migliore sistema per pubblicare le liste di revoca, di chi e come debba farlo. Posso solo dire che, a mio parere, gli utenti hanno “il primo incontro” con i browser web.
Il blocco dei siti che usano certificati fasulli è auspicabile; pubblicare una lista di tutti i certificati emessi dalle CA al mondo ritengo sia impossibile per svariati motivi.

– Roel Schouwenberg, ricercatore presso Kaspersky Lab, ritiene che attacchi come quelli sferrati in questi mesi alle CA possano diventare sempre più frequenti. Quali solo le difese che dovrebbero essere messe in campo?

M.P.: Roel ha perfettamente ragione ma come ho detto non esiste la ricetta per difendersi “a tuttotondo”.
L’unica difesa possibile è fare tesoro delle esperienze maturate e, soprattutto, avere in piedi un sistema che sia capace di bloccare sul nascere l’emissione del cosiddetto certificato “fasullo”.

Link copiato negli appunti