Confidando di SSL e della catena di fiducia

La catena non è verificata "da sola". Un determinato sistema (ad esempio un browser Web) considererà valido il certificato di un server perché potrebbe creare una catena valida (con tutte le firme corregge e abbina i nomi e tutte le regole di X.509 ) che termina con il certificato da convalidare (il certificato del server) e che inizia con una CA root che il il cliente ha già .

Le firme non creano fiducia, esse trasportano fiducia. Deve ancora iniziare da qualche parte. Ogni client (nel browser o nel sistema operativo stesso) viene fornito con un elenco di "CA attendibile": queste sono le chiavi pubbliche e i nomi di alcune entità ritenute "affidabili" (non le hai scelte tu stesso, Microsoft l'ha fatto per te, ma, comunque, finché usi il software di Microsoft ti stai fidando di Microsoft per non aver giocato a brutti giochi su di te). La CA radice è "affidabile" se ci si fida di loro per non emettere certificati con informazioni false: quando una CA emette (firma) un certificato per qualche entità E , si suppone che assicuri che la chiave pubblica che la CA inserisce quel certificato, insieme al nome di E , è di proprietà di E . Allo stesso modo, quando una CA root delega la sua potenza a un'altra CA (quindi chiamata CA intermedio o sub CA ), si assicura (tramite audit e contratti vincolanti) che la CA sub è davvero affidabile, in quanto applicherà le stesse regole.

Questo è il concetto di Public Key Infrastructure : come cliente, conosci a priori una manciata di chiavi pubbliche di proprietà della CA attendibile, e si fida implicitamente di tutto ciò che questi CA firmano. I certificati assumono una struttura ad albero, con la CA radice come, beh, i certificati radice dell'albero (da cui il nome) e il certificato end-entity (server SSL) come foglie. Una catena di certificati è in realtà un percorso dalla radice a una determinata foglia.

Se una CA radice o intermedia diventa inaffidabile, ad esempio perché è stata compromessa e ha emesso un certificato falso (un'associazione errata tra nome e chiave pubblica), allora il ripristino comporta l'interruzione del ramo non valido, un processo noto come revoca . In pratica, ciò non si verifica spesso per le CA commerciali di grandi dimensioni (quelle che sono considerate di default in Windows o Firefox); di 'una volta all'anno? Per esempio. quello si è verificato pochi giorni fa, e sia la revoca sia un la patch di Microsoft sicura da errori blocca qualsiasi tentativo di utilizzo del certificato canaglia. In pratica, i normali attaccanti (ad esempio per scopi di phishing) non si preoccupano di ottenere certificati "validi" per i loro server falsi.

Non lo chiamerei fiducia cieca, ma sì - ci si basa sull'affidabilità del certificato radice e su tutte le autorità intermedie sulla strada a seconda dell'implementazione e della configurazione.

Il certificato di un sito Web è verificato con una CA. Per assicurarsi che questa CA sia effettivamente la CA che intendi fidarti, puoi verificare il proprio certificato con un'altra CA sopra di essa nella gerarchia ... questo si ripete fino a raggiungere quello che viene chiamato un certificato di origine. Questo certificato è convalidato dal tuo software che ha un elenco di certificati di base di cui si fida. Questo può essere gestito dal sistema operativo o dall'applicazione stessa.

Quindi alla fine tutta la tua sicurezza si basa su questo percorso dal certificato di root fino in fondo.

I vettori di attacco includono:

Un utente malintenzionato riesce a installare un certificato di root dannoso sul tuo PC è game over.

Un utente malintenzionato riesce a ingannare uno dei CA o sfruttare una vulnerabilità e possiede una CA

Ci sono molti difetti con l'attuale PKI e la catena di fiducia è una di queste, ma non l'unica e non in tutti i casi.

• Ogni browser / sistema operativo è dotato di numerose CA e il trust è abilitato per impostazione predefinita. Quindi, una volta ottenuto il browser, ti fidi implicitamente di tutte queste CA per la tua comunicazione. Devi disabilitare esplicitamente le impostazioni di fiducia se vuoi controllare chi ti fidi.
• Ogni CA può creare qualsiasi certificato che desidera, ad es. possono creare un certificato per google.com anche se esiste già un certificato di un'altra CA. E il browser accetterà questi certificati a meno che non utilizzi il blocco dei certificati o tecniche simili.
• Ogni CA può creare un numero illimitato di CA subordinate.
• Ogni CA subordinata ha gli stessi diritti illimitati della sua controllante-CA, ad es. può creare qualsiasi certificato, comprese le sub-sub-CA. Questi sub-sub-CA hanno di nuovo gli stessi diritti, ecc. Ciò significa che devi compromettere solo una delle migliaia CA / sub-CA / sub-sub-CA ecc per ottenere il certificato che desideri.
• Attualmente non esiste alcun controllo che la CA / sub-CA abbia emesso quali certificati o sub-CA, quindi è tentato di vendere tali sub-CA illimitate a enti governativi e altre istituzioni, che possono utilizzarle per man-in-the - attacchi violenti.

Quindi, la catena di fiducia è parte del problema, perché non è possibile limitare le capacità di una CA secondaria. Se la CA secondaria è controllata da una parte diversa, la CA principale aumenta anche il rischio di compromissione.

Tuttavia, le sub-CA possono essere utilizzate anche per un migliore controllo dei rischi. Se il proprietario di una CA radice crea una quantità controllata di CA subordinate di breve durata dalla CA radice longeva e utilizza queste CA secondarie per firmare, (s) può bloccare la chiave segreta per la CA radice. in un luogo molto sicuro fino a quando le sub-CA di breve durata devono essere rinnovate, quindi solo le sotto-CA meno preziose potrebbero essere compromesse. Inoltre, è possibile revocare il certificato per una CA secondaria (almeno in teoria), ma per revocare la CA radice è necessario aggiornare tutti i browser / sistema operativo.