Come funziona la Certificate Transparency?
La Certificate Transparency, o CT, opera all'interno dell'infrastruttura esistente dell'autorità di certificazione (CA) convalidando, dopo l'emissione, l'autorizzazione di un'entità ad emettere certificati SSL.
Qui di seguito illustriamo il processo di emissione del certificato evidenziando in blu le nuove fasi introdotte dalla CT.
- L'operatore del server acquista il certificato dalla CA
- La CA convalida l'operatore del server
- La CA crea un precertificato
- La CA registra il precertificato con il server di log, che restituisce un timestamp del certificato firmato (SCT)
- La CA rilascia il certificato SSL
- Il certificato SSL può includere il timestamp del certificato firmato (SCT)
- Il browser convalida il certificato SSL durante l'handshake TLS
- Il browser convalida l'SCT fornito durante l'handshake TLS con la pinzatura OCSP, o con un'estensione TLS o ancora tramite le informazioni incorporate nel certificato
- Il browser si connette al server
- Il certificato SSL crittografa tutti i dati che passano dal browser al server
Ci sono tre modi possibili per fornire l'SCT durante l'handshake TLS, come spiegato qui. Di seguito è riportato un diagramma di questo processo per uno dei metodi di delivery SCT.
Componenti della trasparenza del certificato
Il sistema CT ha quattro componenti: CA, registro dei certificati, monitor dei certificati e auditor dei certificati. Di seguito è riportato un diagramma con una probabile configurazione di questi componenti. Ciascuna di queste componenti è spiegata in modo più dettagliato di seguito.
Autorità di certificazione
La CT opera all'interno dell'attuale sistema di CA pubblicamente attendibili. Con la CT, le CA possono includere le prove dell'emissione del certificato in un log pubblico e i browser possono verificare la presenza di questi SCT durante l'handshake. La registrazione dei certificati è la prova del corretto funzionamento della CA e fornisce informazioni sulle operazioni della CA.
Log dei certificati
Idealmente, i log dei certificati terranno traccia di tutti i certificati SSL emessi, sebbene il rollout iniziale sia limitato ai certificati EV. Sono necessari più log indipendenti per diversi motivi: 1) Consentono il backup in caso di errore del log, 2) Consentono di convalidare i certificati se viene compromesso un log (ossia un registro) o un operatore del log; 3) Impediscono che un'unica azione governativa possa rimuovere le prove dell'emissione da tutti i log; 4) Evitano che una CA e un operatore del log possano cooperare per offuscare un'emissione errata imbarazzante.
Tutti i log sono:
- Solo aggiungibili - I certificati si possono solo aggiungere a un log: non si possono cancellare, modificare o inserire retroattivamente.
- Crittograficamente garantiti - I log utilizzano un meccanismo crittografico chiamato Merkle Tree Hash per prevenire la manomissione.
- Pubblicamente controllabili - Chiunque può interrogare un log e cercare certificati errati o non conformi. Tutti i log dei certificati devono pubblicizzare pubblicamente i loro URL e la loro chiave pubblica.
Monitoraggio dei certificati
Chiunque controlli i log dei certificati alla ricerca di attività sospette, come le grandi aziende o le CA, è definito "certificate monitor".
I monitor possono recuperare le informazioni dai log utilizzando un comando HTTP GET. Tutti i clienti possono avere il loro servizio di monitoraggio dei log o delegare questo compito ad altri. DigiCert prevede di fornire servizi di monitoraggio dei log ai propri clienti.
Auditor dei certificati
Gli auditor dei certificati esaminano i log per verificare che un logo sia coerente con gli altri log, che siano state aggiunte nuove voci e che il log non sia stato corrotto da qualcuno che ha inserito, cancellato o modificato un certificato in modo retroattivo.
L'auditing verrà probabilmente automatizzato integrandolo nei browser. Tuttavia, gli auditor possono essere un servizio autonomo o una funzione secondaria di un "certificate monitor".
