Nota traductor: per a la comoditat dels lectors, les dates es donen a l'hora de Moscou
Recentment hem perdut la caducitat d'un dels certificats utilitzats per signar complements. Això va provocar que els complements fossin desactivats per als usuaris. Ara que el problema s'ha solucionat majoritàriament, m'agradaria compartir els detalls del que va passar i la feina feta.
Antecedents: addicions i signatures
Els complements han de tenir instal·lats signatura digital, que protegeix els usuaris de complements maliciosos i requereix una revisió mínima dels complements per part del personal de Mozilla. Vam introduir aquest requisit el 2015 perquè estàvem experimentant problemes greus amb complements maliciosos.
Com funciona: cada còpia de Firefox conté un "certificat arrel". La clau d'aquesta "arrel" s'emmagatzema a Mòdul de seguretat de maquinari (HSM)sense accés a la xarxa. Cada pocs anys, es signa un nou "certificat intermedi" amb aquesta clau, que s'utilitza per signar complements. Quan un desenvolupador envia un complement, creem un "certificat final" temporal i el signem amb un certificat intermedi. A continuació, el complement en si es signa amb el certificat final. Esquemàticament sembla així.
Tingueu en compte que cada certificat té un "subjecte" (a qui s'ha emès el certificat) i un "emissor" (qui va emetre el certificat). En el cas d'un certificat arrel, "subjecte" = "emissor", però per a altres certificats, l'emissor del certificat és el subjecte del certificat principal amb el qual està signat.
Un punt important: cada complement està signat per un certificat final únic, però gairebé sempre aquests certificats finals estan signats pel mateix certificat intermedi.
Nota de l'autor: l'excepció són addicions molt antigues. En aquella època s'utilitzaven diversos certificats intermedis.
Aquest certificat intermedi va causar problemes: cada certificat té una validesa durant un període determinat. Abans o després d'aquest període, el certificat no és vàlid i el navegador no utilitzarà complements signats per aquest certificat. Malauradament, el certificat intermedi va caducar el 4 de maig a les 4 del matí.
Les conseqüències no van aparèixer immediatament. Firefox no verifica les signatures dels complements instal·lats constantment, sinó aproximadament una vegada cada 24 hores, i el temps de verificació és individual per a cada usuari. Com a resultat, algunes persones van experimentar problemes immediatament, mentre que altres van experimentar problemes molt més tard. En primer lloc ens vam adonar del problema quan va caducar el certificat i de seguida vam començar a buscar una solució.
Reducció de danys
Un cop ens vam adonar del que havia passat, vam intentar evitar que la situació empitjorés.
En primer lloc, van deixar d'acceptar i signar noves incorporacions. No té sentit utilitzar un certificat caducat per a això. Mirant enrere, diria que ho podríem haver deixat tot tal com estava. Ara hem reprès acceptant suplements.
En segon lloc, van enviar immediatament una solució que impedia que les signatures es controlessin diàriament. Així, vam desar aquells usuaris el navegador dels quals encara no havia tingut temps de comprovar els complements en les últimes XNUMX hores. Aquesta correcció s'ha retirat i ja no és necessària.
Funcionament en paral·lel
En teoria, la solució al problema sembla senzilla: creeu un nou certificat intermedi vàlid i torneu a signar cada complement. Malauradament, això no funcionarà:
- no podem tornar a signar ràpidament 15 mil complements alhora, el sistema no està dissenyat per a aquesta càrrega
- Després de signar les addicions, les versions actualitzades s'han de lliurar als usuaris. La majoria de complements s'instal·len des dels servidors de Mozilla, de manera que Firefox trobarà actualitzacions en les properes XNUMX hores, però alguns desenvolupadors distribueixen complements signats a través de canals de tercers, de manera que els usuaris haurien d'actualitzar aquests complements manualment.
En comptes d'això, vam intentar desenvolupar una solució que arribés a tots els usuaris sense requerir gaire o cap acció per part seva.
Molt ràpidament vam arribar a dues estratègies principals, que vam utilitzar paral·lelament:
- Actualitzeu Firefox per canviar el període de validesa del certificat. Això farà que els complements existents tornin a funcionar de manera màgica, però caldrà llançar i enviar una nova versió de Firefox
- Genereu un certificat vàlid i convenceu d'alguna manera el Firefox perquè l'accepti en lloc de l'existent que ha caducat
Vam decidir utilitzar primer la primera opció, que semblava bastant viable. Al final del dia, van llançar una segona correcció (un nou certificat), del qual parlarem més endavant.
Substitució d'un certificat
Com he comentat anteriorment, era necessari:
- crear un nou certificat vàlid
- instal·lar-lo de forma remota al Firefox
Per entendre per què funciona, fem una ullada més de prop al procés de verificació del complement. El complement en si es presenta com un conjunt de fitxers, inclosa una cadena de certificats utilitzats per signar. Com a resultat, el complement es pot verificar si el navegador coneix el certificat arrel, que està integrat al Firefox en el moment de la creació. Tanmateix, com ja sabem, el certificat intermedi ha caducat, per la qual cosa és impossible verificar el complement.
Quan el Firefox intenta verificar un complement, no es limita a utilitzar els certificats continguts al mateix complement. En canvi, el navegador intenta crear una cadena de certificats vàlida, començant pel certificat final i continuant fins que arriba a l'arrel. En el primer nivell, comencem amb el certificat final i després trobem el certificat el subjecte del qual és l'emissor del certificat final (és a dir, el certificat intermedi). Normalment, aquest certificat intermedi es subministra amb el complement, però qualsevol certificat de l'emmagatzematge del navegador també pot servir com a certificat intermedi. Si podem afegir de forma remota un nou certificat vàlid al magatzem de certificats, Firefox intentarà utilitzar-lo. La situació abans i després d'instal·lar un nou certificat.
Després d'instal·lar el nou certificat, Firefox tindrà dues opcions a l'hora de validar la cadena de certificats: utilitzar l'antic certificat no vàlid (que no funcionarà) o el nou certificat vàlid (que funcionarà). És important que el nou certificat contingui el mateix nom de subjecte i clau pública que el certificat antic, de manera que la seva signatura al certificat final serà vàlida. Firefox és prou intel·ligent com per provar ambdues opcions fins que en trobi una que funcioni, de manera que els complements es tornen a provar. Tingueu en compte que aquesta és la mateixa lògica que utilitzem per validar els certificats TLS.
Nota de l'autor: els lectors familiaritzats amb WebPKI notaran que els certificats creuats funcionen exactament de la mateixa manera.
El millor d'aquesta correcció és que no requereix que torneu a signar els complements existents. Tan bon punt el navegador rebi el nou certificat, tots els complements tornaran a funcionar. Queda el repte de lliurar el nou certificat als usuaris (de manera automàtica i remota) i també aconseguir que Firefox torni a comprovar els complements desactivats.
Normandia i el sistema de recerca
Irònicament, aquest problema es resol amb un complement especial anomenat "sistema". Per dur a terme investigacions, hem desenvolupat un sistema anomenat Normandia que ofereix recerca als usuaris. Aquests estudis es realitzen automàticament al navegador i tenen un accés millorat a les API internes de Firefox. Research pot afegir nous certificats al magatzem de certificats.
Nota de l'autor: no estem afegint un certificat amb cap privilegi especial; està signat pel certificat arrel, de manera que Firefox hi confia. Simplement l'afegim al conjunt de certificats que pot utilitzar el navegador.
Així que la solució és crear un estudi:
- instal·lant el nou certificat que hem creat per als usuaris
- forçant el navegador a tornar a comprovar els complements desactivats perquè tornin a funcionar
"Però espera", dius, "els complements no funcionen, com puc llançar un complement del sistema?" Signem-ho amb un nou certificat!
Ajuntant-ho tot... per què triga tant?
Així doncs, el pla: emetre un nou certificat per substituir l'antic, crear un complement del sistema i instal·lar-lo als usuaris a través de Normandia. Els problemes, com he dit, van començar el 4 de maig a les 4:00, i ja a les 12:44 del mateix dia, menys de 9 hores després, vam enviar una solució a Normandia. Va trigar entre 6 i 12 hores més a arribar a tots els usuaris. No està gens malament, però la gent a Twitter es pregunta per què no hem pogut actuar més ràpid.
En primer lloc, va trigar temps a emetre un nou certificat intermedi. Com he esmentat anteriorment, la clau del certificat arrel s'emmagatzema fora de línia al mòdul de seguretat de maquinari. Això és bo des del punt de vista de la seguretat, ja que l'arrel s'utilitza molt poques vegades i s'ha de protegir de manera fiable, però és una mica incòmode quan necessiteu signar urgentment un nou certificat. Un dels nostres enginyers va haver de viatjar a la instal·lació d'emmagatzematge HSM. Després hi va haver intents infructuosos d'emetre el certificat correcte, i cada intent va costar una o dues hores de prova.
En segon lloc, el desenvolupament del complement del sistema va trigar un temps. Conceptualment és molt senzill, però fins i tot els programes senzills requereixen cura. Volíem assegurar-nos de no empitjorar la situació. La investigació s'ha de provar abans de ser enviada als usuaris. A més, cal signar el complement, però el nostre sistema de signatura de complements estava desactivat, així que vam haver de trobar una solució alternativa.
Finalment, un cop teníem la recerca a punt per enviar-la, el desplegament va trigar un temps. El navegador comprova si hi ha actualitzacions de Normandia cada 6 hores. No tots els ordinadors estan sempre encès i connectats a Internet, de manera que la solució necessitarà temps per estendre's als usuaris.
Passos finals
La investigació hauria de solucionar el problema per a la majoria dels usuaris, però no està disponible per a tothom. Alguns usuaris requereixen un enfocament especial:
- usuaris que han desactivat la recerca o la telemetria
- usuaris de la versió d'Android (Fennec), on la recerca no és compatible en absolut
- usuaris de versions personalitzades de Firefox ESR en empreses on la telemetria no es pot activar
- usuaris asseguts darrere dels servidors intermediaris MitM, ja que el nostre sistema d'instal·lació de complements utilitza la fixació de claus, que no funciona amb aquests servidors intermediaris.
- usuaris de versions heretades de Firefox que no admeten la recerca
No podem fer res amb aquesta darrera categoria d'usuaris; encara haurien d'actualitzar-se a la nova versió de Firefox, perquè els obsolets tenen greus vulnerabilitats sense pegar. Sabem que algunes persones es mantenen amb versions anteriors de Firefox perquè volen executar complements antics, però molts dels complements antics ja s'han portat a versions més noves del navegador. Per a altres usuaris, hem desenvolupat un pedaç que instal·larà un nou certificat. Es va publicar com a versió de correcció d'errors (nota del traductor: Firefox 66.0.5), de manera que la gent l'obtindrà (probablement ja ho ha tingut) a través del canal d'actualització habitual. Si utilitzeu una versió personalitzada de Firefox ESR, poseu-vos en contacte amb el vostre responsable.
Entenem que això no és ideal. En alguns casos, els usuaris van perdre dades de complements (per exemple, dades de complements Contenidors multicompte).
Aquest efecte secundari no es pot evitar, però creiem que a curt termini hem escollit la millor solució per a la majoria d'usuaris. A llarg termini, buscarem altres plantejaments arquitectònics més avançats.
Lliçons
Primer, el nostre equip va fer un treball increïble creant i enviant una solució en menys de 12 hores després de descobrir el problema. Com a persona que va assistir a les reunions, puc dir que en aquesta situació tan difícil la gent va treballar molt i es va perdre molt poc temps.
Evidentment, res d'això hauria d'haver passat en absolut. És evident que val la pena ajustar els nostres processos per reduir la probabilitat d'aquests incidents i facilitar la correcció.
La setmana vinent publicarem una autopsia oficial i una llista dels canvis que volem fer. De moment, compartiré els meus pensaments. En primer lloc, hi ha d'haver una millor manera de controlar l'estat del que és una possible bomba de rellotgeria. Hem d'assegurar-nos que no ens trobem en una situació en què un d'ells funcioni de sobte. Encara estem elaborant els detalls, però com a mínim, cal tenir en compte totes aquestes coses.
En segon lloc, necessitem un mecanisme per oferir ràpidament actualitzacions als usuaris, fins i tot quan, sobretot quan, falla tota la resta. Va ser fantàstic que puguem utilitzar el sistema de "investigació", però és una eina imperfecta i té alguns efectes secundaris no desitjats. En particular, sabem que molts usuaris tenen les actualitzacions automàtiques activades, però preferirien no participar en la recerca (admeto que també les tinc desactivades!). Al mateix temps, necessitem una manera d'enviar actualitzacions als usuaris, però sigui quina sigui la implementació tècnica interna, els usuaris haurien de poder subscriure's a les actualitzacions (incloses les correccions ràpides) però desactivar tota la resta. A més, el canal d'actualització hauria de ser més sensible que ara. Fins i tot el 6 de maig, encara hi havia usuaris que no aprofitaven ni la correcció ni la nova versió. Aquest problema ja s'havia treballat, però el que va passar va demostrar la importància que és.
Finalment, analitzarem més de prop l'arquitectura de seguretat del complement per assegurar-nos que ofereix el nivell de seguretat adequat amb un risc mínim de trencar qualsevol cosa.
La setmana vinent veurem els resultats d'una anàlisi més exhaustiva del que va passar, però mentrestant estaré encantat de respondre les preguntes per correu electrònic: [protegit per correu electrònic]
Font: linux.org.ru