Mozilla implementa CRLite per verificare i certificati TLS problematici

Azienda Mozilla ha annunciato sull'inizio della sperimentazione nelle versioni notturne di Firefox del nuovo meccanismo di rilevamento dei certificati revocati — CRLite. CRLite consente di effettuare un'efficace verifica della revoca dei certificati attraverso un database ospitato sul sistema dell'utente. L'implementazione di CRLite sviluppata in Mozilla è stata pubblicata è sotto licenza libera MPL 2.0. Il codice per la generazione del database e i componenti server sono scritti in Python e Go. Le parti client aggiunte a Firefox per la lettura dei dati dal database sono stati preparati sono scritte in Rust.

Il metodo di verifica dei certificati ancora in uso che coinvolge servizi esterni basati sul protocollo OCSP (Online Certificate Status Protocol) richiede un accesso di rete garantito, porta a un ritardo significativo nel trattamento delle richieste (in media 350 ms) e presenta problemi nella protezione della privacy (i server OCSP che rispondono alle richieste ricevono informazioni su certificati specifici, da cui si può dedurre quali siti sta visitando l'utente). Esiste anche la possibilità di verifica locale tramite le liste CRL (Certificate Revocation List), ma il difetto di questo metodo è dato dalla grande dimensione dei dati da scaricare: attualmente il database dei certificati revocati occupa circa 300 MB e continua a crescere.

Per bloccare i certificati compromessi e revocati dalle autorità di certificazione, Firefox utilizza dal 2015 una blacklist centralizzata OneCRL in combinazione con l'accesso al servizio Google Safe Browsing per identificare possibili attività dannose. OneCRL, così come CRLSets in Chrome, funge da anello intermedio che aggrega le liste CRL dalle autorità di certificazione e fornisce un servizio OCSP centralizzato per verificare i certificati revocati, consentendo di non inviare richieste direttamente alle autorità di certificazione. Nonostante il grande lavoro svolto per migliorare l'affidabilità del servizio di verifica online dei certificati, i dati della telemetria mostrano che oltre il 7% delle richieste OCSP termina con un timeout (qualche anno fa questa percentuale era del 15%).

Per impostazione predefinita, se non è possibile effettuare il controllo tramite OCSP, il browser considera il certificato valido. Il servizio potrebbe essere inaccessibile a causa di problemi di rete e restrizioni sulle reti interne o essere bloccato da attaccanti: per eludere il controllo OCSP durante un attacco MITM è sufficiente bloccare l'accesso al servizio di verifica. In parte per prevenire tali attacchi è stata implementata una tecnica Must-Staple, che permette di interpretare un errore nell'accesso a OCSP o l'inaccessibilità di OCSP come un problema con il certificato, ma questa possibilità è facoltativa e richiede una particolare formalizzazione del certificato.

CRLite riduce le informazioni sui certificati revocati in una struttura facilmente aggiornabile, della dimensione di soli 1 MB, che consente di mantenere un database completo CRL sul lato cliente.
Il browser potrà sincronizzare quotidianamente la propria copia dei dati sui certificati revocati, e questo database sarà accessibile in qualsiasi condizione.

CRLite combina informazioni da Certificate Transparency, un registro pubblico di tutti i certificati emessi e revocati, e i risultati della scansione dei certificati su Internet (vengono raccolti vari elenchi CRL delle autorità di certificazione e aggregata l'informazione su tutti i certificati noti). I dati vengono impacchettati usando strutture a cascata Bloom, una struttura probabilistica che ammette la falsa identificazione di un elemento mancante, ma esclude l'omissione di un elemento esistente (cioè, con una certa probabilità potrebbe avvenire un falso positivo su un certificato valido, ma i certificati revocati saranno garantiti come identificati).

Per escludere falsi positivi in CRLite, sono stati introdotti ulteriori livelli di filtraggio correttivi. Dopo la generazione della struttura, viene effettuata una revisione di tutte le registrazioni sorgenti per identificare eventuali falsi positivi. Sulla base dei risultati di questo controllo, viene creata una struttura aggiuntiva che si sovrappone alla prima e corregge i falsi positivi emersi. L'operazione viene ripetuta fino a quando i falsi positivi non sono completamente esclusi durante il controllo. Di solito, per coprire completamente tutti i dati, è sufficiente creare 7-10 strati. Poiché lo stato del database a causa della sincronizzazione periodica è leggermente in ritardo rispetto allo stato attuale CRL, il controllo dei nuovi certificati, emessi dopo l'ultimo aggiornamento del database CRLite, viene eseguito tramite il protocollo OCSP, inclusa l'uso della tecnica OCSP Stapling (la risposta OCSP firmata dall'autorità di certificazione viene trasmessa dal server del sito durante l'accordo TLS della connessione).

Mozilla implementa CRLite per verificare i certificati TLS problematici

Grazie ai filtri di Bloom, il campione di dicembre delle informazioni da WebPKI, che copre 100 milioni di certificati attivi e 750.000 certificati revocati, è stato compresso in una struttura di dimensioni 1,3 MB. Il processo di generazione della struttura è abbastanza intensivo in termini di risorse, ma viene eseguito sul server Mozilla e all'utente viene fornito un aggiornamento già pronto. Ad esempio, in forma binaria, i dati sorgenti utilizzati per la generazione richiedono circa 16 GB di memoria se memorizzati nel database Redis, mentre in forma esadecimale il dump di tutti i numeri di serie dei certificati occupa circa 6,7 GB. Il processo di aggregazione di tutti i certificati revocati e attivi richiede circa 40 minuti, mentre il processo di generazione della struttura compressa basata sul filtro di Bloom richiede altri 20 minuti.

Attualmente, in Mozilla viene assicurato l'aggiornamento del database CRLite quattro volte al giorno (non tutti gli aggiornamenti vengono consegnati ai client). La generazione di aggiornamenti delta non è ancora stata implementata: l'uso di bsdiff4, utilizzato per creare aggiornamenti delta delle versioni, non garantisce l'efficienza necessaria per CRLite e gli aggiornamenti risultano ingiustificatamente grandi. Per risolvere questo inconveniente, è previsto un riadattamento del formato della struttura di archiviazione per evitare ricostruzioni superflue e rimozioni di strati.

CRLite funziona attualmente in Firefox in modalità passiva ed è utilizzato parallelamente con OCSP per raccogliere dati sulla correttezza operativa. CRLite può essere trasferito in modalità di verifica principale; per farlo, in about:config è necessario impostare il parametro security.pki.crlite_mode = 2.

Mozilla implementa CRLite per verificare i certificati TLS problematici

Fonte: opennet.ru

Acquista hosting affidabile per siti web con protezione DDoS, VPS VDS server 🔥 Acquista hosting affidabile per siti web con protezione DDoS, VPS VDS server | ProHoster