Nota del traduttore: per comodità dei lettori, le date sono indicate in ora di Mosca
Recentemente abbiamo perso il momento della scadenza di uno dei certificati utilizzati per firmare le estensioni. Questo ha portato a disattivare le estensioni per gli utenti. Ora che la maggior parte del problema è stata risolta, vorrei raccontare i dettagli di quanto accaduto e del lavoro svolto.
Contesto: estensioni e firme
Le estensioni installate devono avere una firma digitale, che protegge gli utenti dalle estensioni dannose e richiede controlli minimi delle estensioni da parte del personale di Mozilla. Abbiamo introdotto questo requisito nel 2015, poiché abbiamo riscontrato seri problemi con estensioni dannose.
Come funziona: ogni copia di Firefox contiene un «certificato radice». La chiave di questo «radice» è conservata in un modulo di sicurezza hardware (HSM), che non ha accesso alla rete. Ogni pochi anni, questa chiave firma un nuovo «certificato intermedio», che viene usato per firmare le estensioni. Quando uno sviluppatore invia un'estensione, creiamo un «certificato finale» temporaneo e lo firmiamo usando il certificato intermedio. Successivamente, il certificato finale firma l'estensione stessa. Schematicamente sembra così.
Nota: ogni certificato ha un «soggetto» (a chi è stato rilasciato il certificato) e un «emittente» (chi ha rilasciato il certificato). Nel caso del certificato radice, il «soggetto» = «emittente», ma per altri certificati l'emittente è il soggetto del certificato superiore di cui è 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 — estensioni molto vecchie. All'epoca venivano utilizzati vari certificati intermedi.
Questo certificato intermedio ha causato problemi: ogni certificato è valido per un determinato periodo. Prima o dopo questo periodo, il certificato è non valido, e il browser non utilizzerà estensioni firmate con quel certificato. Purtroppo, il certificato intermedio è scaduto il 4 maggio alle 4 del mattino.
Le conseguenze non si sono manifestate subito. Firefox controlla le firme delle estensioni installate non continuamente, ma circa ogni 24 ore, con il tempo di verifica che è individuale per ogni utente. Di conseguenza, alcune persone hanno avuto problemi immediatamente, mentre altre molto dopo. Abbiamo appreso del problema per la prima volta circa nel momento in cui il certificato è scaduto e abbiamo subito iniziato a cercare una soluzione.
Riduciamo i danni
Appena abbiamo capito cosa fosse successo, abbiamo cercato di non permettere un ulteriormente aggravi della situazione.
In primo luogo, abbiamo smesso di accettare e firmare nuove estensioni. Non ha senso usare un certificato scaduto per questo. Guardando indietro, direi che avremmo potuto lasciare tutto com'era. Ora l'accettazione delle estensioni è stata ripristinata.
In secondo luogo, abbiamo immediatamente inviato una correzione, che ha impedito il controllo quotidiano delle firme. Così abbiamo salvato quegli utenti il cui browser non aveva ancora controllato le estensioni nelle ultime 24 ore. Ora questa correzione è stata revocata, non c'è più bisogno di essa.
Funzionamento parallelo
Teoricamente, risolvere il problema sembra semplice: creiamo un nuovo certificato intermedio valido e ri-firma ogni estensione. Purtroppo, questo non funzionerà:
- non possiamo ri-firmare rapidamente 15.000 estensioni tutte in una volta, il sistema non è progettato per un carico simile
- dopo aver firmato le estensioni, le versioni aggiornate devono essere consegnate agli utenti. La maggior parte delle estensioni viene installata dai server di Mozilla, quindi nelle prossime 24 ore Firefox troverà aggiornamenti, ma alcuni sviluppatori distribuiscono estensioni firmate tramite 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 richiedere) azioni da parte loro.
Abbiamo rapidamente identificato due strategie principali, che abbiamo utilizzato in parallelo:
- Aggiorna Firefox per modificare il periodo di validità del certificato. Questo farà sì che le estensioni esistenti riprendano magicamente a funzionare, ma richiederà l'emissione e la consegna di una nuova versione di Firefox.
- Crea un certificato valido e in qualche modo persuadi Firefox ad accettarlo al posto di quello esistente, il cui periodo di validità è scaduto.
Abbiamo deciso di utilizzare inizialmente la prima opzione, che sembrava decisamente funzionante. Alla fine della giornata, abbiamo rilasciato anche la seconda correzione (un nuovo certificato), di cui parleremo in seguito.
Sostituzione del certificato
Come ho accennato sopra, era necessario:
- creare un nuovo certificato valido
- installarlo da remoto in Firefox
Per capire perché questo funzionerà, esaminiamo più dettagliatamente il processo di verifica dell'estensione. L'estensione stessa è fornita come un insieme di file, inclusa la catena di certificati utilizzati per la firma. Di conseguenza, l'estensione può essere verificata se il browser conosce il certificato radice, che viene integrato in Firefox durante la compilazione. Tuttavia, come sappiamo, il certificato intermedio è scaduto, quindi l'estensione non può essere verificata.
Quando Firefox tenta di verificare un'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 fino a raggiungere il 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 è fornito insieme all'estensione, ma in questo ruolo può anche fungere da qualsiasi certificato nel deposito del browser. Se riusciamo a installare da remoto un nuovo certificato valido nel deposito dei certificati, Firefox cercherà di utilizzarlo. Situazione prima e dopo l'installazione del nuovo certificato.
Dopo aver installato il nuovo certificato, Firefox avrà due opzioni quando verifica la catena dei certificati: utilizzare il vecchio certificato non valido (che non funzionerà) o il nuovo certificato valido (che funzionerà). È importante notare che il nuovo certificato contiene lo stesso nome soggetto e chiave pubblica del vecchio certificato, quindi la sua firma sul certificato finale sarà valida. Firefox è abbastanza intelligente da provare entrambe le opzioni fino a trovare quella funzionante, quindi le estensioni diventeranno nuovamente verificate. Si noti, questa è la stessa logica che utilizziamo 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 più straordinaria di questa correzione è che non richiede di risignare le estensioni esistenti. Una volta che il browser riceve il nuovo certificato, tutte le estensioni riprenderanno a funzionare. Rimane la complessità di consegnare il nuovo certificato agli utenti (automaticamente e da remoto) e far sì che Firefox ricontrolli le estensioni disattivate.
Normandy e il 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 le ricerche agli utenti. Queste ricerche vengono eseguite automaticamente nel browser e hanno accesso esteso alle API interne di Firefox. Le ricerche possono aggiungere nuovi certificati nel deposito dei certificati.
Nota dell'autore: non stiamo aggiungendo certificati con privilegi speciali; sono firmati da un certificato radice, quindi Firefox si fida di essi. Li aggiungiamo semplicemente 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 per gli utenti
- che costringe il browser a ricontrollare le estensioni disattivate affinché riprendano a funzionare
"Ma aspetta" - direte voi - "le estensioni non funzionano, come avviare l'estensione di sistema?" Firmiamola con il nuovo certificato!
Mettiamo tutto insieme… perché ci è voluto così tanto?
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 perché raggiungesse 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 emettere un nuovo certificato intermedio. Come ho già detto, la chiave del certificato radice è conservata in modo autonomo in un modulo di sicurezza hardware. Questo è vantaggioso dal punto di vista della sicurezza, poiché il certificato radice viene utilizzato molto raramente e deve essere protetto in modo affidabile, ma è un po' scomodo quando si deve firmare urgentemente un nuovo certificato. Uno dei nostri ingegneri ha dovuto recarsi nel deposito HSM. Ci sono state poi tentativi infruttuosi di emettere il certificato corretto, e ogni tentativo ha comportato un costo di una o due ore spese nei test.
In secondo luogo, ci è voluto del tempo per sviluppare il componente 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 di essere inviata agli utenti. Inoltre, il componente deve essere firmato, ma il nostro sistema di firma dei componenti era disattivato, quindi abbiamo dovuto cercare una soluzione alternativa.
Infine, dopo aver preparato la ricerca per l'invio, ci è voluto tempo per il dispiegamento. Il browser controlla gli 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.
Passaggi 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 raccolta di dati o la telemetria
- utenti della versione Android (Fennec), dove la funzione non è supportata affatto
- utenti di build customizzate di Firefox ESR in azienda, dove non è possibile attivare la telemetria
- utenti che si trovano dietro proxy MitM, poiché il nostro sistema di installazione dei componenti utilizza il key pinning, che non funziona con tali proxy
- utenti di versioni obsolete di Firefox che non supportano la raccolta di dati
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 vecchie di Firefox perché desiderano eseguire componenti aggiuntivi obsoleti, ma molti di questi componenti sono già stati portati su nuove versioni del browser. Per gli altri utenti abbiamo sviluppato una patch che installerà il nuovo certificato. È stata rilasciata come un aggiornamento di correzione di bug (nota del traduttore: Firefox 66.0.5), quindi le persone lo riceveranno — molto probabilmente lo hanno già ricevuto — attraverso il consueto canale di aggiornamento. Se stai utilizzando una build customizzata di Firefox ESR, contatta il tuo maintainer.
Comprendiamo che tutto ciò non è perfetto. In alcuni casi, gli utenti hanno perso i dati dei componenti aggiuntivi (ad esempio, i dati del componente aggiuntivo Multi-Account Containers).
Non siamo riusciti ad evitare questo effetto collaterale, ma crediamo che a breve termine abbiamo scelto la soluzione migliore per la maggior parte degli utenti. A lungo termine cercheremo approcci architettonici più avanzati.
Lezioni apprese
In primo luogo, il nostro team ha fatto un lavoro straordinario nel creare e inviare una correzione in meno di 12 ore dopo la scoperta del problema. Come persona che era presente alle riunioni, posso affermare che in questa situazione complessa le persone hanno lavorato molto duramente e il tempo speso inutilmente è stato davvero minimo.
È evidente che tutto ciò non sarebbe dovuto accadere. È decisamente il caso di rivedere i nostri processi per ridurre la possibilità di incidenti simili e semplificare la risoluzione delle 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, dovrebbe esserci un modo migliore per monitorare lo stato di ciò che è una potenziale bomba a orologeria. Dobbiamo assicurarci di non trovarci in una situazione in cui una di esse esplode improvvisamente. Stiamo ancora lavorando sui dettagli, ma almeno bisogna tenere traccia di tutte queste questioni.
In secondo luogo, è necessario un meccanismo di consegna rapida degli aggiornamenti agli utenti, anche quando — soprattutto quando — tutto il resto non funziona. È stato fantastico poter utilizzare il sistema delle “indagini”, ma è uno strumento imperfetto e ha alcuni effetti collaterali indesiderati. In particolare, sappiamo che molti utenti hanno attivato gli aggiornamenti automatici, ma preferirebbero non partecipare alle indagini (confesso che anche io li ho disattivati!). Allo stesso tempo, abbiamo bisogno di un modo per inviare aggiornamenti agli utenti, ma quale che sia l'implementazione tecnica interna, gli utenti devono avere la possibilità di abbonarsi agli aggiornamenti (compresi i correttivi rapidi) ma rinunciare a tutto il resto. Inoltre, il canale di aggiornamento deve essere più reattivo di adesso. Anche il 6 maggio c'erano utenti che non hanno utilizzato né il correttivo né la nuova versione. Abbiamo già lavorato su questo problema, ma ciò che è accaduto ha dimostrato quanto sia importante.
Infine, daremo un'occhiata all'architettura di sicurezza delle estensioni, per assicurarci che fornisca un adeguato livello di sicurezza con un rischio minimo di rompere qualcosa.
La prossima settimana esamineremo i risultati di un'analisi più approfondita di quanto accaduto, ma nel frattempo sarò lieto di rispondere alle domande via email: ekr-blog@mozilla.com
Fonte: linux.org.ru
