Nota tradutor: para comodidade dos lectores, as datas indícanse na hora de Moscova
Recentemente perdemos a caducidade dun dos certificados utilizados para asinar complementos. Isto provocou que os complementos fosen desactivados para os usuarios. Agora que o problema se solucionou na súa maioría, gustaríame compartir os detalles do que pasou e do traballo que se fixo.
Antecedentes: engadidos e sinaturas
Debe ter os complementos instalados sinatura dixital, que protexe aos usuarios de complementos maliciosos e require unha revisión mínima dos complementos por parte do persoal de Mozilla. Introducimos este requisito en 2015 porque estabamos experimentando problemas graves con complementos maliciosos.
Como funciona: cada copia de Firefox contén un "certificado raíz". A clave desta "raíz" está almacenada Módulo de seguridade de hardware (HSM)sen acceso á rede. Cada poucos anos asínase un novo "certificado intermedio" con esta chave, que se usa ao asinar complementos. Cando un programador envía un complemento, creamos un "certificado de finalización" temporal e asinámolo mediante un certificado intermedio. O complemento en si asínase co certificado final. Esquemáticamente parece así.
Teña en conta que cada certificado ten un "suxeito" (a quen se emitiu o certificado) e un "emisor" (que emitiu o certificado). No caso dun certificado raíz, "subject" = "emisor", pero para outros certificados, o emisor do certificado é o suxeito do certificado principal polo que está asinado.
Un punto importante: cada complemento está asinado por un certificado final único, pero case sempre estes certificados finais están asinados polo mesmo certificado intermedio.
Nota do autor: a excepción son engadidos moi antigos. Daquela utilizáronse diversos certificados intermedios.
Este certificado intermedio causou problemas: cada certificado é válido durante un período determinado. Antes ou despois deste período, o certificado non é válido e o navegador non utilizará complementos asinados por este certificado. Desafortunadamente, o certificado intermedio caducou o 4 de maio ás 4 da mañá.
As consecuencias non apareceron inmediatamente. Firefox non verifica constantemente as sinaturas dos complementos instalados, senón aproximadamente unha vez cada 24 horas, e o tempo de verificación é individual para cada usuario. Como resultado, algunhas persoas experimentaron problemas inmediatamente, mentres que outras experimentaron problemas moito máis tarde. Primeiro decatámonos do problema cando caducou o certificado e inmediatamente comezamos a buscar unha solución.
Redución de danos
Unha vez que nos demos conta do que pasara, tentamos evitar que a situación empeorara.
En primeiro lugar, deixaron de aceptar e asinar novas incorporacións. Non ten sentido usar un certificado caducado para iso. Botando a vista atrás, diría que puidemos ter deixado todo como estaba. Agora retomamos a aceptación de suplementos.
En segundo lugar, enviaron inmediatamente unha corrección que impedía que as firmas fosen revisadas a diario. Así, gardamos aqueles usuarios cuxo navegador aínda non tiña tempo de comprobar os complementos nas últimas XNUMX horas. Esta corrección retirouse agora e xa non é necesaria.
Funcionamento en paralelo
En teoría, a solución ao problema parece sinxela: crear un novo certificado intermedio válido e volver a asinar cada complemento. Desafortunadamente, isto non funcionará:
- non podemos volver a asinar rapidamente 15 mil complementos á vez, o sistema non está deseñado para tal carga
- Despois de asinar as adicións, as versións actualizadas deben ser entregadas aos usuarios. A maioría dos complementos instálanse desde servidores de Mozilla, polo que Firefox atopará actualizacións nas próximas XNUMX horas, pero algúns desenvolvedores distribúen complementos asinados a través de canles de terceiros, polo que os usuarios terían que actualizar estes complementos manualmente.
En vez diso, tentamos desenvolver unha corrección que chegase a todos os usuarios sen requirir moita ou ningunha acción pola súa parte.
Moi rápido chegamos a dúas estratexias principais, que utilizamos en paralelo:
- Actualiza Firefox para cambiar o período de validez do certificado. Isto fará que os complementos existentes volvan funcionar de xeito máxico, pero requirirá lanzar e enviar unha nova versión de Firefox
- Xera un certificado válido e, dalgún xeito, convence a Firefox para que o acepte en lugar do existente que caducou
Decidimos usar primeiro a primeira opción, que parecía bastante viable. Ao final do día, lanzaron unha segunda corrección (un novo certificado), do que falaremos máis tarde.
Substitución dun certificado
Como dixen anteriormente, era necesario:
- crear un novo certificado válido
- instálalo de forma remota en Firefox
Para entender por que isto funciona, vexamos máis de cerca o proceso de verificación do complemento. O complemento en si vén como un conxunto de ficheiros, incluíndo unha cadea de certificados utilizados para a sinatura. Como resultado, o complemento pódese verificar se o navegador coñece o certificado raíz, que está integrado en Firefox no momento da compilación. Non obstante, como xa sabemos, o certificado intermedio caducou, polo que é imposible verificar o complemento.
Cando Firefox tenta verificar un complemento, non se limita a usar os certificados contidos no propio complemento. Pola contra, o navegador tenta crear unha cadea de certificados válida, comezando polo certificado final e continuando ata chegar á raíz. No primeiro nivel, comezamos co certificado final e despois atopamos o certificado cuxo suxeito é o emisor do certificado final (é dicir, o certificado intermedio). Normalmente este certificado intermedio ofrécese co complemento, pero calquera certificado do almacenamento do navegador tamén pode servir como este certificado intermedio. Se podemos engadir remotamente un novo certificado válido ao almacén de certificados, Firefox tentará usalo. A situación antes e despois de instalar un novo certificado.
Despois de instalar o novo certificado, Firefox terá dúas opcións á hora de validar a cadea de certificados: utilizar o certificado antigo non válido (que non funcionará) ou o novo certificado válido (que funcionará). É importante que o novo certificado conteña o mesmo nome de asunto e clave pública que o certificado antigo, polo que a súa sinatura no certificado final será válida. Firefox é o suficientemente intelixente como para probar ambas opcións ata que atope unha que funcione, polo que os complementos volven probar. Teña en conta que esta é a mesma lóxica que usamos para validar os certificados TLS.
Nota do autor: os lectores familiarizados con WebPKI notarán que os certificados cruzados funcionan exactamente do mesmo xeito.
O gran desta corrección é que non require que volvas asinar os complementos existentes. En canto o navegador reciba o novo certificado, todos os complementos funcionarán de novo. O reto restante é entregar o novo certificado aos usuarios (de forma automática e remota), así como conseguir que Firefox volva comprobar os complementos desactivados.
Normandía e o sistema de investigación
Irónicamente, este problema resólvese cun complemento especial chamado "sistema". Para realizar investigacións, desenvolvemos un sistema chamado Normandy que ofrece investigacións aos usuarios. Estes estudos realízanse automaticamente no navegador e teñen acceso mellorado ás API internas de Firefox. Research pode engadir novos certificados ao almacén de certificados.
Nota do autor: non estamos engadindo un certificado con ningún privilexio especial; está asinado polo certificado raíz, polo que Firefox confía nel. Simplemente engadímolo ao grupo de certificados que pode usar o navegador.
Polo tanto, a solución é crear un estudo:
- instalando o novo certificado que creamos para os usuarios
- obrigando ao navegador a comprobar de novo os complementos desactivados para que volvan funcionar
"Pero espera", dis, "os complementos non funcionan, como podo lanzar un complemento do sistema?" Imos asinalo cun novo certificado!
Xuntando todo... por que leva tanto tempo?
Entón, o plan: emitir un novo certificado para substituír o antigo, crear un complemento do sistema e instálao aos usuarios a través de Normandy. Os problemas, como dixen, comezaron o 4 de maio ás 4:00, e xa ás 12:44 do mesmo día, menos de 9 horas despois, enviamos unha solución a Normandía. Tardaron outras 6-12 horas en chegar a todos os usuarios. Non está nada mal, pero a xente en Twitter pregunta por que non puidemos actuar máis rápido.
En primeiro lugar, levou tempo emitir un novo certificado intermedio. Como mencionei anteriormente, a clave do certificado raíz gárdase fóra de liña no módulo de seguridade de hardware. Isto é bo desde o punto de vista da seguridade, xa que a raíz úsase moi poucas veces e debería estar protexida de forma fiable, pero é un pouco inconveniente cando precisa asinar un novo certificado con urxencia. Un dos nosos enxeñeiros tivo que viaxar ao almacén de HSM. Despois houbo intentos infructuosos de emitir o certificado correcto e cada intento custou unha ou dúas horas de proba.
En segundo lugar, o desenvolvemento do complemento do sistema levou algún tempo. Conceptualmente é moi sinxelo, pero incluso programas sinxelos requiren coidado. Queriamos asegurarnos de non empeorar a situación. A investigación debe ser probada antes de ser enviada aos usuarios. Ademais, o complemento debe estar asinado, pero o noso sistema de sinatura de complementos estaba desactivado, polo que tivemos que buscar unha solución.
Finalmente, unha vez que tivemos a investigación lista para a súa presentación, a implantación levou tempo. O navegador busca actualizacións de Normandy cada 6 horas. Non todos os ordenadores están sempre acesos e conectados a Internet, polo que a corrección tardará un tempo en estenderse aos usuarios.
Pasos finais
A investigación debería solucionar o problema para a maioría dos usuarios, pero non está dispoñible para todos. Algúns usuarios requiren un enfoque especial:
- usuarios que teñan desactivado a investigación ou a telemetría
- usuarios da versión de Android (Fennec), onde a investigación non é compatible en absoluto
- usuarios de compilacións personalizadas de Firefox ESR en empresas nas que non se pode habilitar a telemetría
- usuarios sentados detrás dos proxies MitM, xa que o noso sistema de instalación de complementos usa fixación de claves, que non funciona con tales proxies
- usuarios de versións legadas de Firefox que non admiten a investigación
Non podemos facer nada con respecto a esta última categoría de usuarios; aínda deberían actualizarse á nova versión de Firefox, porque os desactualizados teñen graves vulnerabilidades sen parchear. Sabemos que algunhas persoas permanecen en versións antigas de Firefox porque queren executar complementos antigos, pero moitos dos complementos antigos xa foron portados a versións máis novas do navegador. Para outros usuarios, desenvolvemos un parche que instalará un novo certificado. Foi lanzado como unha versión de corrección de erros (Nota do tradutor: Firefox 66.0.5), polo que a xente o conseguirá, probablemente xa o teña a través da canle de actualización habitual. Se está a usar unha versión personalizada de Firefox ESR, póñase en contacto co seu mantedor.
Entendemos que isto non é o ideal. Nalgúns casos, os usuarios perderon datos de complementos (por exemplo, datos de complementos Contedores con varias contas).
Este efecto secundario non se puido evitar, pero cremos que a curto prazo eliximos a mellor solución para a maioría dos usuarios. A longo prazo, buscaremos outros enfoques arquitectónicos máis avanzados.
Leccións
En primeiro lugar, o noso equipo fixo un traballo incrible creando e enviando unha solución en menos de 12 horas despois de que se descubrise o problema. Como quen asistiu ás xuntanzas, podo dicir que nesta difícil situación a xente traballou moito e se perdeu moi pouco tempo.
Obviamente, nada disto debería pasar en absoluto. É evidente que paga a pena axustar os nosos procesos para reducir a probabilidade de tales incidentes e facilitar a súa corrección.
A vindeira semana publicaremos unha autopsia oficial e unha lista de cambios que pretendemos facer. De momento, vou compartir os meus pensamentos. En primeiro lugar, debe haber unha mellor forma de controlar o estado do que é unha posible bomba de reloxería. Temos que asegurarnos de non atoparnos nunha situación na que un deles funcione de súpeto. Aínda estamos traballando os detalles, pero, como mínimo, é necesario ter en conta todas estas cousas.
En segundo lugar, necesitamos un mecanismo para entregar rapidamente actualizacións aos usuarios, mesmo cando, especialmente cando, todo o demais falla. Foi xenial que puidésemos usar o sistema de "investigación", pero é unha ferramenta imperfecta e ten algúns efectos secundarios non desexados. En particular, sabemos que moitos usuarios teñen as actualizacións automáticas activadas, pero preferirían non participar na investigación (admítoo que tamén as teño desactivadas!). Ao mesmo tempo, necesitamos unha forma de enviar actualizacións aos usuarios, pero calquera que sexa a implementación técnica interna, os usuarios deberían poder subscribirse ás actualizacións (incluídas as correccións rápidas) pero desactivar todo o demais. Ademais, a canle de actualización debería ser máis sensible que agora. Aínda o 6 de maio, aínda houbo usuarios que non aproveitaron nin a corrección nin a nova versión. Este problema xa foi traballado, pero o que pasou demostrou o importante que é.
Finalmente, analizaremos a arquitectura de seguranza do complemento para asegurarnos de que ofrece o nivel de seguridade correcto cun risco mínimo de romper calquera cousa.
A vindeira semana veremos os resultados dunha análise máis exhaustiva do acontecido, pero mentres tanto responderei as preguntas por correo electrónico: [protexido por correo electrónico]
Fonte: linux.org.ru