Trasparenza certificato

Poiché non posso commentare, a quanto pare, voglio chiarire un paio di punti.

• CT non richiede che tutti i browser lo usino: c'è un'immunità della mandria conferita anche se solo un browser lo fa. E, BTW, la prossima versione di Chrome include il supporto CT.

• I server Web non devono essere modificati per supportare CT - Le CA possono includere gli SCT nei certificati emessi. Alcuni CA lo fanno già e altri ci stanno lavorando.

• CT non introduce una nuova entità fidata - i log CT dimostrano la loro corretta operatività, e qualsiasi deviazione lascia evidenza firmata del loro errore.

• L'obiettivo della CT è di consentire alle parti interessate (proprietari di domini, ricercatori, ecc.) di avere piena visibilità della PKI pubblica in modo che l'emissione di certificati sia facile da individuare tempestivamente. Il DigiNotar, ad esempio, sarebbe stato scoperto in ore invece che in mesi in cui era stato distribuito il CT.

Trasparenza certificato è un meccanismo euristico di difesa che riconosce non certificati emessi; al contrario, si sforza di consentire un rilevamento più rapido dei certificati errati.

L'idea di base è Glasnost . Accade così che gli attacchi di maggior successo si basino su un'asimmetria di informazioni. Supponiamo che io voglia impersonare il server di Google. Attraverso l'inganno, la corruzione, l'incompetenza e / o la fortuna, ottengo un certificato falso con "www.google.com" scritto in esso. Lo userò quindi per un server falso che risponde solo alle mie vittime target (ad esempio, tutto il dipendente di un'azienda in cui ho alcune capacità di sysadmin). Il mio interesse, in quanto aggressore, è che nessuno all'esterno nota l'esistenza di quel falso certificato, in particolare Google stesso. Se le persone di Google vengono a conoscenza di questo certificato che porta il loro nome, ma non è uno di loro, quindi parleranno tempestivamente con la CA emittente e chiedono la revoca immediata. Ci si possono aspettare parole dure.

Certificate Transparency è un registro pubblico di certificati. Questo è un sistema mediante il quale un client SSL / TLS (un browser Web) può essere configurato per accettare un certificato solo se viene fornito con una prova verificabile (il "Certificato firmato Timestamp ") che il certificato è stato aggiunto a un log in cui sarà visibile a tutti, in particolare al presunto proprietario del certificato (Google, nel mio esempio sopra). Questo non garantisce il rilevamento; infatti, il certificato è tecnicamente completamente valido. Ciò che CT garantisce è che qualsiasi certificato che vede ogni client si trova in visualizzazione semplice e quindi presumibilmente , verrà presto rilevato se è fraudolento.

(Si può notare che i registri CT includono timestamp firmati da ... un'entità fidata? Come sempre, nessun trust è mai creato , solo spostato . )

La parte debole della CT è che funziona solo se tutti partecipano. CT offre reali miglioramenti della sicurezza solo fino a quando i client SSL / TLS (ovvero i browser Web) rifiutano debitamente i certificati server che non sono forniti con SCT. Funziona solo se tutte le seguenti affermazioni sono vere:

• Tutta la CA partecipa, in modo che ci si possa aspettare che ogni certificato "normale" sia in un registro CT ad un certo punto.
• Tutti i browser Web supportano CT e rifiutano i certificati che non si trovano nel registro.
• Tutti i server Web supportano CT e inviano gli oggetti Timestamp certificati firmati ai browser utilizzando le estensioni SSL / TLS specificate.

Stimo le probabilità che questo sistema completi effettivamente la sua fase di bootstrap a meno del 10%.

PKI ha due elementi: i protcoli tecnici e le procedure che costruiamo intorno a loro.

Nel campo tecnico, le cose sono abbastanza chiare: hai un meccanismo che ti permette di decidere di cosa fidarti, quando in quali condizioni e come comunicare (la maggior parte) cambiamenti in quel sistema di fiducia (CRL, OCSP, ecc.).

Questi elementi tecnici, tuttavia, non coprono le procedure: come possiamo sapere che tale e tale root può essere considerata attendibile? Come utente, solitamente perché ti fidi (implicitamente) della società che crea e gestisce l'elenco di CA radice (Microsoft, Mozilla, Google, Apple, ecc.). Come attore, perché riesamina il modo in cui queste radici sono state convalidate o validate da te (ad esempio, se stai utilizzando le radici private, è importante condurre un'indagine adeguata su come sono gestite).

Quindi, come si fa a sapere che una CA (intermedia o root) è stata compromessa? Può essere perché si individua un uso improprio di tale CA (ad esempio trovare un certificato foglia che è firmato da un certificato che non ha il diritto di firmare le chiavi) ma molto probabilmente è sempre a causa di qualche elemento procedurale: qualcuno ha fatto un controllo e notato un uso inappropriato di detto certificato.

Nel caso specifico collegato, il problema era davvero di quella natura: l'ANSSI ha fatto qualcosa che non avrebbe dovuto fare (rilascia un certificato in nome di un'entità ad un'altra entità non correlata) ed è per questo che il certificato è stato revocato da Google e Mozilla.

Questo evidenzia il problema con l'intero sistema PKI pubblico: ci sono troppi attori che devono seguire troppe regole che non sono banali da capire e anche meno facili da seguire. E non ci vuole che uno solo degli attori fallisca perché la sicurezza dell'intero sistema si sgretoli: l'intera faccenda è incredibilmente fragile.