Nota del traduttore: per comodità dei lettori, le date sono indicate secondo il fuso orario di Mosca.
Recentemente abbiamo perso il termine di scadenza di uno dei certificati utilizzati per firmare le estensioni. Questo ha portato alla disattivazione delle estensioni per gli utenti. Ora, che per lo più il problema è stato risolto, desidero raccontare i dettagli di quanto accaduto e del lavoro svolto.
Fondo: estensioni e firme
Le estensioni installate devono avere una firma digitale, che protegge gli utenti da estensioni dannose e richiede un controllo minimo delle estensioni da parte dei dipendenti di Mozilla. Abbiamo introdotto questo requisito nel 2015, poiché riscontravamo serissimi problemi con estensioni dannose.
Come funziona: ogni copia di Firefox contiene un 'certificato radice'. La chiave di questo 'radice' è conservata in un modulo di protezione hardware (HSM), non accessibile dalla rete. Ogni pochi anni, questa chiave firma un nuovo 'certificato intermedio', utilizzato per firmare le estensioni. Quando uno sviluppatore invia un'estensione, creiamo un 'certificato finale' temporaneo e lo firmiamo usando il certificato intermedio. Poi, il certificato finale firma l'estensione stessa. Sinteticamente questo appare così.
Nota: ogni certificato ha un 'soggetto' (a cui è stato rilasciato il certificato) e un 'emittente' (chi ha emesso il certificato). Nel caso del certificato radice, 'soggetto' = 'emittente', ma per altri certificati, l'emittente del certificato è il soggetto del certificato superiore che lo ha firmato.
Punto importante: ogni estensione è firmata con un certificato finale unico, ma quasi sempre questi certificati finali sono firmati dallo stesso certificato intermedio.
Nota dell'autore: eccezione per le estensioni molto vecchie. All'epoca venivano utilizzati vari certificati intermedi.
Questo certificato intermedio ha causato problemi: ogni certificato è valido per un periodo di tempo specifico. Prima o dopo questo periodo, il certificato non è valido e il browser non utilizzerà le estensioni firmate con questo certificato. Sfortunatamente, il certificato intermedio è scaduto il 4 maggio alle 4 del mattino.
Le conseguenze non si sono manifestate immediatamente. Firefox controlla le firme delle estensioni installate non in modo costante, ma circa una volta ogni 24 ore, e il tempo di verifica è individuale per ogni utente. Di conseguenza, alcune persone hanno avuto problemi subito, altre molto più tardi. Abbiamo appreso per la prima volta del problema circa nel momento in cui il certificato è scaduto, e abbiamo subito iniziato a cercare una soluzione.
Ridurre i danni
Non appena abbiamo capito cosa fosse successo, abbiamo cercato di evitare un ulteriore deterioramento della situazione.
In primo luogo, abbiamo smesso di accettare e firmare nuove estensioni. Non ha senso utilizzare un certificato scaduto per questo. Guardando indietro, direi che avremmo potuto decidere di mantenere tutto come era. Ora la ricezione delle estensioni è ripresa.
In secondo luogo, abbiamo immediatamente inviato una correzione che ha impedito il controllo quotidiano delle firme. In questo modo, abbiamo salvato quegli utenti il cui browser non aveva ancora controllato le estensioni nelle ultime 24 ore. Ora questa correzione è revocata, poiché non è più necessaria.
Lavoro parallelo
Teoricamente, la soluzione al problema sembra semplice: creiamo un nuovo certificato intermedio valido e risigniamo ogni estensione. Sfortunatamente, questo non funzionerà:
- non possiamo risignare rapidamente 15.000 estensioni contemporaneamente, il sistema non è progettato per un carico del genere.
- dopo aver firmato le estensioni, le versioni aggiornate devono essere consegnate agli utenti. La maggior parte delle estensioni viene installata dai server Mozilla, quindi nelle prossime 24 ore Firefox troverà gli aggiornamenti, ma alcuni sviluppatori distribuiscono estensioni firmate attraverso canali di terze parti, quindi gli utenti dovrebbero aggiornare manualmente tali estensioni.
Invece, abbiamo cercato di sviluppare una correzione che raggiungesse tutti gli utenti, senza richiedere (o quasi senza richiedere) azioni da parte loro.
Abbiamo rapidamente individuato due strategie principali, che abbiamo utilizzato in parallelo:
- Aggiornare Firefox per modificare il periodo di validità del certificato. Questo farà sì che le estensioni esistenti funzionino di nuovo magicamente, ma richiederà il rilascio e la distribuzione di una nuova versione di Firefox.
- Creare un certificato valido e in qualche modo convincere Firefox ad accettarlo al posto di quello esistente, la cui validità è scaduta.
Abbiamo deciso di utilizzare inizialmente la prima opzione, che sembrava essere piuttosto efficace. Alla fine della giornata, abbiamo rilasciato anche la seconda correzione (nuovo certificato), di cui parleremo più avanti.
Sostituzione del certificato
Come accennato sopra, era necessario:
- creare un nuovo certificato valido
- installarlo da remoto in Firefox
Per capire perché questo funzionerebbe, esaminiamo più nel dettaglio il processo di verifica dell'estensione. L'estensione stessa viene fornita come un insieme di file, inclusa la catena di certificati utilizzata per la firma. Di conseguenza, l'estensione può essere verificata se il browser è a conoscenza del certificato radice, che è integrato in Firefox durante la costruzione. Tuttavia, come già sappiamo, il certificato intermedio è scaduto, quindi l'estensione non può essere verificata.
Quando Firefox tenta di verificare l'estensione, non si limita a utilizzare i certificati contenuti all'interno dell'estensione stessa. Invece, il browser cerca di creare una catena di certificati valida, partendo dal certificato finale e continuando finché non raggiunge la radice. Al primo livello iniziamo con il certificato finale e poi troviamo il certificato il cui soggetto è l'emittente del certificato finale (cioè, il certificato intermedio). Di solito, questo certificato intermedio viene fornito insieme all'estensione, ma può anche svolgere questo ruolo qualsiasi certificato presente nel keystore del browser. Se riusciremo a aggiungere da remoto un nuovo certificato valido al keystore, Firefox cercherà di utilizzarlo. La situazione prima e dopo l'installazione del nuovo certificato.
Dopo l'installazione del nuovo certificato, Firefox avrà due opzioni durante il controllo della catena dei certificati: utilizzare il vecchio certificato non valido (che non funzionerà), oppure il nuovo certificato valido (che funzionerà). È importante che il nuovo certificato contenga lo stesso nome del soggetto e la stessa chiave pubblica del vecchio certificato, quindi la sua firma sul certificato finale sarà valida. Firefox è abbastanza intelligente da provare entrambe le opzioni fino a quando non trova quella che funziona, quindi le estensioni torneranno ad essere verificate. Si noti che questa è la stessa logica che usiamo per verificare i certificati TLS.
Nota dell'autore: i lettori familiari con WebPKI noteranno che i certificati incrociati funzionano esattamente allo stesso modo.
La cosa straordinaria di questa correzione è che non richiede di risignare le estensioni esistenti. Non appena il browser riceve il nuovo certificato, tutte le estensioni ricominceranno a funzionare. Rimane la complessità di consegnare il nuovo certificato agli utenti (in modo automatico e remoto), oltre a costringere Firefox a ricontrollare le estensioni disabilitate.
Normandy e sistema di ricerche
Ironia della sorte, questo problema è risolto da un'estensione speciale chiamata 'sistemica'. Per condurre ricerche, abbiamo sviluppato un sistema chiamato Normandy, che consegna ricerche agli utenti. Queste ricerche vengono eseguite automaticamente nel browser e hanno accesso avanzato alle API interne di Firefox. Le ricerche possono aggiungere nuovi certificati al keystore.
Nota dell'autore: non stiamo aggiungendo un certificato con privilegi speciali; è firmato da un certificato radice, quindi Firefox si fida di esso. Stiamo semplicemente aggiungendolo al pool di certificati che possono essere utilizzati dal browser.
Pertanto, la soluzione consiste nel creare una ricerca:
- che installa il nuovo certificato creato da noi sugli utenti
- che costringe il browser a ricontrollare le estensioni disabilitate affinché tornino a funzionare
"Ma aspetta", dirai tu, "le estensioni non funzionano, come si avvia l'estensione sistemica?" Firmiamola con il nuovo certificato!
Mettiamo insieme il tutto… perché ci vuole così tanto tempo?
Quindi, il piano: rilasciare un nuovo certificato per sostituire il vecchio, creare un'estensione di sistema e installarla per gli utenti tramite Normandy. I problemi, come ho detto, sono iniziati il 4 maggio alle 4:00, e già alle 12:44 dello stesso giorno, meno di 9 ore dopo, abbiamo inviato la correzione a Normandy. Ci sono volute altre 6-12 ore affinché arrivasse a tutti gli utenti. Già non male, ma gli utenti su Twitter chiedono perché non abbiamo potuto agire più rapidamente.
In primo luogo, ci è voluto tempo per rilasciare un nuovo certificato intermedio. Come ho già accennato sopra, la chiave del certificato radice è conservata in modo autonomo in un modulo di sicurezza hardware. Questo è buono dal punto di vista della sicurezza, poiché la radice è usata molto raramente e deve essere protetta in modo affidabile, ma è un po' scomodo quando è necessario firmare urgentemente un nuovo certificato. Uno dei nostri ingegneri ha dovuto recarsi nel deposito HSM. Poi ci sono state tentativi falliti di emettere il certificato corretto, e ogni tentativo costava da una a due ore dedicate ai test.
In secondo luogo, è stato necessario un certo tempo per sviluppare l'estensione di sistema. Concettualmente è molto semplice, ma anche i programmi semplici richiedono attenzione. Volevamo assicurarci di non peggiorare ulteriormente la situazione. La ricerca deve essere testata prima dell'invio agli utenti. Inoltre, l'estensione deve essere firmata, ma il nostro sistema di firma delle estensioni era disattivato, e abbiamo dovuto cercare una soluzione alternativa.
Infine, dopo aver preparato la ricerca per l'invio, ci è voluto tempo per il deployment. Il browser controlla la presenza di aggiornamenti di Normandy ogni 6 ore. Non tutti i computer sono sempre accesi e connessi a Internet, quindi ci vuole tempo affinché la correzione si diffonda tra gli utenti.
Passi finali
La ricerca dovrebbe risolvere il problema per la maggior parte degli utenti, ma non è disponibile per tutti. Alcuni utenti richiedono un approccio speciale:
- utenti che hanno disattivato la ricerca o la telemetria
- utenti della versione Android (Fennec), dove la ricerca non è affatto supportata
- utenti di build personalizzate di Firefox ESR nelle aziende, dove non è possibile attivare la telemetria
- gli utenti che si trovano dietro un proxy MitM, poiché il nostro sistema di installazione delle estensioni utilizza il key pinning, che non funziona con tali proxy
- gli utenti di versioni obsolete di Firefox che non supportano gli aggiornamenti
Non possiamo fare nulla per l'ultima categoria di utenti: dovrebbero comunque aggiornarsi all'ultima versione di Firefox, poiché le versioni obsolete presentano gravi vulnerabilità non risolte. Sappiamo che alcune persone rimangono su versioni obsolete di Firefox perché vogliono eseguire vecchie estensioni, ma molte di queste estensioni sono già state portate sulle nuove versioni del browser. Per gli altri utenti abbiamo sviluppato una patch che installerà un nuovo certificato. È stata rilasciata come un bugfix release (nota del traduttore: Firefox 66.0.5), quindi le persone lo riceveranno - probabilmente lo hanno già ricevuto - tramite il normale canale di aggiornamento. Se utilizzi una build personalizzata di Firefox ESR, contatta il tuo mantenitore.
Comprendiamo che tutto ciò non è ideale. In alcuni casi, gli utenti hanno perso i dati delle estensioni (ad esempio, i dati dell'estensione Multi-Account Containers).
Non siamo riusciti a evitare questo effetto collaterale, ma riteniamo di aver scelto la soluzione migliore per la maggior parte degli utenti nel breve termine. Nel lungo termine, cercheremo approcci architettonici alternativi e più sofisticati.
Lezioni
In primo luogo, il nostro team ha svolto un lavoro straordinario, creando e inviando una correzione in meno di 12 ore dall'individuazione del problema. Come persona che era presente durante le riunioni, posso dire che in questa situazione difficile le persone hanno lavorato molto duramente e si è sprecato davvero poco tempo.
È evidente che tutto questo non sarebbe dovuto accadere. È chiaro che dobbiamo rivedere i nostri processi per ridurre la probabilità di tali incidenti e rendere più facile l'adeguamento alle conseguenze.
La prossima settimana pubblicheremo un post-mortem ufficiale e un elenco delle modifiche che intendiamo apportare. Nel frattempo, voglio condividere i miei pensieri. In primo luogo, ci deve essere un modo migliore per monitorare lo stato di ciò che può essere una bomba a orologeria. Dobbiamo assicurarci di non trovarci in una situazione in cui una di esse esploda improvvisamente. Stiamo ancora lavorando sui dettagli, ma almeno è necessario tenere traccia di tutte queste cose.
In secondo luogo, ci serve un meccanismo per inviare aggiornamenti agli utenti rapidamente, anche quando — specialmente quando — tutto il resto non funziona. È stato fantastico che abbiamo potuto usare il sistema delle "ricerche", ma è uno strumento imperfetto e ha alcuni effetti collaterali indesiderati. In particolare, sappiamo che molti utenti hanno attivato l'aggiornamento automatico, ma preferirebbero non partecipare alle ricerche (ammetto che anche io le ho disattivate!). Allo stesso tempo, abbiamo bisogno di un modo per inviare aggiornamenti agli utenti, ma, qualunque sia l'implementazione tecnica interna, gli utenti devono avere la possibilità di iscriversi agli aggiornamenti (inclusi i fix urgenti) ma di rifiutare tutto il resto. Inoltre, il canale di aggiornamento deve essere più reattivo di quanto non sia attualmente. Anche il 6 maggio c'erano utenti che non avevano utilizzato né il fix né la nuova versione. Abbiamo già lavorato su questo problema, ma ciò che è successo ha dimostrato quanto sia importante.
Infine, daremo un'occhiata all'architettura della sicurezza delle estensioni per assicurarci che garantisca un adeguato livello di sicurezza con il minimo rischio di rompersi.
La prossima settimana esamineremo i risultati di un'analisi più approfondita di quanto accaduto, ma nel frattempo sarò felice di rispondere a qualsiasi domanda via email: ekr-blog@mozilla.com
Fonte: linux.org.ru
