La chiave privata della root Certification Authority è quanto di più prezio- so esista per la CA stessa e l’intero ecosistema. Oltre ad avere un immenso valore economico, se la chiave viene compromessa può essere utilizzata per generare qualunque certificato fraudolento per qualunque nome di dominio. In tal caso la chiave dovrebbe essere revocata causando così l’inutilizzabilità di tutti i siti che dipendono da essa. Questi sono motivi per cui per esempio rilasciare un certificato firmato direttamente dalla root CA non è più permes- so (Basement Requirements for the Issuance and Management of Publicly-Trusted Certificates), inoltre il server dove risiede la CA deve sottostare a rigidissimi
2.3. Importanza della root CA 23
controlli e regole di sicurezza una delle quali l’isolamento quasi totale dalla rete.[45]
2.3.1
Debolezze della PKI
Se osserviamo l’intera PKI possiamo notare che ci sono diverse mancanze dal punto di vista della sicurezza, alcune meno significative ed alcune note- voli. Dobbiamo sempre ricordare che l’Internet non è nato sicuro per design ma quest’ultima è stata aggiunta e poi sempre rifinita successivamente. La sicurezza sul web è un compromesso tra Browser, Certification Authority ed esperienza di navigazione per l’utente finale. Le CA hanno sicuramente come scopo quello di aumentare i profitti commerciali, i browser quello di incrementare i loro market share, il tutto tentando di mantenere un adeguato livello di sicurezza per l’utente finale. È proprio riguardo a questo livello che si viene ad un compromesso: se si volesse mantenere lo standard più elevato allora molti client che non lo supporterebbero verrebbero tagliati fuori per motivi di compatibilità, all’opposto uno standard eccessivamente permissi- vo porterebbe solamente a peggiori problemi di sicurezza per tutti. Questo è il motivo per cui spesso è impossibile sfruttare la crittografia più potente e più recente su grande scala, quindi se ne utilizza una a livello inferiore che permetta di allargare il bacino di utilizzatori. Per poter usufruire appieno di un sistema veramente sicuro sarebbe necessario che ogni singolo compo- nente dell’intero ecosistema funzioni a dovere cooperando con tutti gli altri, adoperando sempre l’ultima tecnologia disponibile pena l’inaccessibilità del sito web, dunque lo scontento e la perdita del pubblico.
Vediamo alcuni punti critici:
• Permesso del proprietario di dominio non richiesto per il rilascio di
certificati: è senza dubbio che la CA debba verificare l’identità del ri- chiedente certificato prima di rilasciarlo, ma è vero anche il contrario? Questo è un problema concettuale, qualsiasi CA può creare un certifi- cato per qualsiasi dominio senza bisogno dell’autorizzazione del pro- prietario del dominio stesso. Questo poteva non essere un problema quando le root CA erano poche, ma ad oggi che ce ne sono decine e centinaia la sicurezza dell’intera PKI dipende appunto "dall’anello più debole della catena". Che danni si avrebbero se un attaccante riuscisse a prendere controllo di questo meccanismo? Sono accaduti eventi in passato come ad esempio il caso della CA Trustwave (2012) la quale
ha ammesso pubblicamente di aver permesso ad una azienda di creare certificati on the fly con l’obiettivo di poter quindi ispezionare il traf- fico di rete protetto diretto a qualsiasi sito web.[5] Possiamo a questo punto essere completamente sicuri che le Certification Authority non agiscano anche sotto direttive dei governi o di enormi e potenti azien- de visto che, come terze parti, affidiamo a loro tutta la nostra fiducia e ne saremmo comunque ignari?
• Debole validazione di dominio (DV certificates): questi certificati so- no rilasciati sulla prova di proprietà di un dominio, il più delle vol- te mediante e-mail che potrebbero essere insicure. Tutta la sicurez- za di quel dominio si potrebbe ridurre per un attaccante a trovare la password della mailbox appartenente a quel dominio.
• Il controllo sulla revoca dei certificati non funziona affatto: ci sono diversi motivi per la quale questo accade. Uno è il ritardo di propaga- zione del comando di revoca in ogni server della CA, come da baseline, ogni informazione in CRL e OCSP deve rimanere valida per almeno 10 giorni. Ciò significa che c’è bisogno di almeno 10 giorni per propagare totalmente l’informazione. Un altro problema è cosi detto della soft-fail policy implementata nei browser; ovvero quando essi tentano di otte- nere informazioni riguardo la revoca o meno di un certificato, se que- sta informazione non giunge in un tempo limite o non giunge proprio allora i browser semplicemente la ignorano e proseguono accettando il certificato così com’è. Addirittura Google Chrome non prova nemmeno a controllare lo stato di revoca dei certificati (tranne che per certificati EV). Un attaccante può mediante man in the middle sopprimere le richie- ste e dunque far accettare alla vittima un certificato falso.[6]Per control- lare certificati più importanti Chrome utilizza i CRLSets che sono liste CRL aggiornate periodicamente dal browser.[19]
• Gli avvisi su certificati da parte del browser fanno fallire lo scopo
della crittografia: uno dei più grandi fallimenti della PKI è questo lasso approccio alla verifica della validità dei certificati. Quando il brow- ser riesce a verificare che un certificato è invalido presenta un warning all’utente al quale viene chiesto se vuole bypassarlo o meno con un semplice click. Un click e lo scopo della crittografia, e della sicurezza svanisce. Recentemente uno standard chiamato HTTP Strict Transport
Security (HSTS) è stato sviluppato per istruire i browser a troncare la connessione e dunque a mostrare un errore invece che un warning.[66]