Observação tradutor: para conveniência dos leitores, as datas são fornecidas no horário de Moscou
Recentemente, perdemos a expiração de um dos certificados usados para assinar complementos. Isso resultou na desativação de complementos para os usuários. Agora que o problema foi praticamente resolvido, gostaria de compartilhar os detalhes do que aconteceu e do trabalho que foi realizado.
Antecedentes: acréscimos e assinaturas
Os complementos instalados devem ter assinatura digital, que protege os usuários contra complementos maliciosos e exige uma revisão mínima dos complementos pela equipe da Mozilla. Introduzimos esse requisito em 2015 porque estávamos enfrentando problemas sérios com complementos maliciosos.
Como funciona: Cada cópia do Firefox contém um “certificado raiz”. A chave para esta “raiz” está armazenada em Módulo de segurança de hardware (HSM)sem acesso à rede. A cada poucos anos, um novo “certificado intermediário” é assinado com esta chave, que é usada ao assinar complementos. Quando um desenvolvedor envia um complemento, criamos um “certificado final” temporário e o assinamos usando um certificado intermediário. O próprio complemento é então assinado com o certificado final. Esquematicamente Se parece com isso.
Observe que cada certificado possui um “sujeito” (para quem o certificado foi emitido) e um “emissor” (quem emitiu o certificado). No caso de um certificado raiz, "subject" = "issuer", mas para outros certificados, o emissor do certificado é o sujeito do certificado pai pelo qual ele é assinado.
Um ponto importante: cada complemento é assinado por um certificado final único, mas quase sempre esses certificados finais são assinados pelo mesmo certificado intermediário.
Nota do autor: A exceção são acréscimos muito antigos. Naquela época, vários certificados intermediários eram usados.
Este certificado intermediário causou problemas: cada certificado é válido por um determinado período. Antes ou depois deste período, o certificado é inválido e o navegador não utilizará complementos assinados por este certificado. Infelizmente, o certificado intermediário expirou em 4 de maio às 4h.
As consequências não apareceram imediatamente. O Firefox não verifica as assinaturas dos complementos instalados constantemente, mas aproximadamente uma vez a cada 24 horas, e o tempo de verificação é individual para cada usuário. Como resultado, algumas pessoas tiveram problemas imediatamente, enquanto outras tiveram problemas muito mais tarde. Tomamos conhecimento do problema pela primeira vez quando o certificado expirou e imediatamente começamos a procurar uma solução.
Reduzindo danos
Assim que percebemos o que havia acontecido, tentamos evitar que a situação piorasse.
Em primeiro lugar, deixaram de aceitar e assinar novas adições. Não faz sentido usar um certificado expirado para isso. Olhando para trás, eu diria que poderíamos ter deixado tudo como estava. Agora voltamos a aceitar suplementos.
Em segundo lugar, eles enviaram imediatamente uma correção que impedia a verificação diária das assinaturas. Assim, salvamos aqueles usuários cujo navegador ainda não teve tempo de verificar os add-ons nas últimas XNUMX horas. Esta correção foi retirada e não é mais necessária.
Operação paralela
Em teoria, a solução para o problema parece simples: criar um novo certificado intermediário válido e assinar novamente cada complemento. Infelizmente isso não funcionará:
- não podemos assinar novamente 15 mil complementos rapidamente de uma vez, o sistema não foi projetado para tal carga
- Depois de assinarmos os acréscimos, as versões atualizadas precisam ser entregues aos usuários. A maioria dos complementos são instalados a partir de servidores Mozilla, então o Firefox encontrará atualizações nas próximas XNUMX horas, mas alguns desenvolvedores distribuem complementos assinados através de canais de terceiros, então os usuários teriam que atualizar esses complementos manualmente
Em vez disso, tentamos desenvolver uma solução que alcançasse todos os usuários sem exigir muita ou nenhuma ação da parte deles.
Rapidamente chegamos a duas estratégias principais, que usamos em paralelo:
- Atualize o Firefox para alterar o período de validade do certificado. Isso fará com que os complementos existentes funcionem magicamente novamente, mas exigirá o lançamento e o envio de uma nova versão do Firefox
- Gere um certificado válido e de alguma forma convença o Firefox a aceitá-lo em vez do existente que expirou
Decidimos usar primeiro a primeira opção, que parecia bastante viável. No final das contas, eles lançaram uma segunda correção (um novo certificado), da qual falaremos mais tarde.
Substituindo um certificado
Como mencionei acima, era necessário:
- criar um novo certificado válido
- instale-o remotamente no Firefox
Para entender por que isso funciona, vamos dar uma olhada mais de perto no processo de verificação de complementos. O complemento em si vem como um conjunto de arquivos, incluindo uma cadeia de certificados usados para assinatura. Como resultado, o complemento pode ser verificado se o navegador conhece o certificado raiz, que está incorporado no Firefox no momento da construção. Porém, como já sabemos, o certificado intermediário expirou, sendo impossível verificar o add-on.
Quando o Firefox tenta verificar um complemento, ele não se limita a usar os certificados contidos no próprio complemento. Em vez disso, o navegador tenta criar uma cadeia de certificados válida, começando com o certificado final e continuando até chegar à raiz. No primeiro nível, começamos com o certificado final e depois encontramos o certificado cujo sujeito é o emissor do certificado final (ou seja, o certificado intermediário). Normalmente, esse certificado intermediário é fornecido com o complemento, mas qualquer certificado do armazenamento do navegador também pode servir como certificado intermediário. Se pudermos adicionar remotamente um novo certificado válido ao armazenamento de certificados, o Firefox tentará usá-lo. A situação antes e depois da instalação de um novo certificado.
Após instalar o novo certificado, o Firefox terá duas opções ao validar a cadeia de certificados: usar o antigo certificado inválido (que não funcionará) ou o novo certificado válido (que funcionará). É importante que o novo certificado contenha o mesmo nome de entidade e chave pública do certificado antigo, para que a sua assinatura no certificado final seja válida. O Firefox é inteligente o suficiente para tentar as duas opções até encontrar uma que funcione, para que os complementos sejam testados novamente. Observe que esta é a mesma lógica que usamos para validar certificados TLS.
Nota do autor: Os leitores familiarizados com o WebPKI notarão que os certificados cruzados funcionam exatamente da mesma maneira.
A melhor coisa sobre essa correção é que ela não exige que você assine novamente os complementos existentes. Assim que o navegador receber o novo certificado, todos os complementos funcionarão novamente. O desafio restante é entregar o novo certificado aos usuários (automática e remotamente), bem como fazer com que o Firefox verifique novamente os complementos desativados.
Normandia e o sistema de pesquisa
Ironicamente, este problema é resolvido por um complemento especial chamado “sistema”. Para realizar pesquisas, desenvolvemos um sistema chamado Normandy, que entrega pesquisas aos usuários. Esses estudos são realizados automaticamente no navegador e possuem acesso aprimorado às APIs internas do Firefox. A pesquisa pode adicionar novos certificados ao armazenamento de certificados.
Nota do autor: Não estamos adicionando um certificado com privilégios especiais; ele é assinado pelo certificado raiz, então o Firefox confia nele. Simplesmente o adicionamos ao conjunto de certificados que podem ser usados pelo navegador.
Então a solução é criar um estudo:
- instalando o novo certificado que criamos para usuários
- forçando o navegador a verificar novamente os complementos desativados para que funcionem novamente
“Mas espere”, você diz, “os complementos não funcionam, como posso iniciar um complemento do sistema?” Vamos assiná-lo com um novo certificado!
Juntando tudo... por que está demorando tanto?
Então, o plano: emitir um novo certificado para substituir o antigo, criar um complemento do sistema e instalá-lo aos usuários via Normandia. Os problemas, como disse, começaram no dia 4 de maio às 4h, e já às 00h12 do mesmo dia, menos de 44 horas depois, enviamos uma correção para a Normandia. Demorou mais 9 a 6 horas para chegar a todos os usuários. Nada mal, mas as pessoas no Twitter estão perguntando por que não poderíamos ter agido mais rápido.
Primeiro, demorou para emitir um novo certificado intermediário. Como mencionei acima, a chave do certificado raiz é armazenada offline no módulo de segurança de hardware. Isso é bom do ponto de vista da segurança, já que a raiz é usada muito raramente e deve ser protegida de forma confiável, mas é um pouco inconveniente quando você precisa assinar um novo certificado com urgência. Um de nossos engenheiros teve que viajar até o depósito do HSM. Depois, houve tentativas malsucedidas de emitir o certificado correto e cada tentativa custou uma ou duas horas gastas em testes.
Em segundo lugar, o desenvolvimento do complemento do sistema demorou algum tempo. Conceitualmente é muito simples, mas mesmo programas simples requerem cuidados. Queríamos ter certeza de que não pioraríamos a situação. A pesquisa precisa ser testada antes de ser enviada aos usuários. Além disso, o complemento deve ser assinado, mas nosso sistema de assinatura de complementos foi desativado, então tivemos que encontrar uma solução alternativa.
Finalmente, depois de termos a pesquisa pronta para envio, a implantação demorou algum tempo. O navegador verifica atualizações da Normandia a cada 6 horas. Nem todos os computadores estão sempre ligados e conectados à Internet, por isso levará algum tempo até que a correção se espalhe entre os usuários.
Etapas finais
A pesquisa deve resolver o problema para a maioria dos usuários, mas não está disponível para todos. Alguns usuários exigem uma abordagem especial:
- usuários que desativaram pesquisa ou telemetria
- usuários da versão Android (Fennec), onde a pesquisa não é suportada de forma alguma
- usuários de versões personalizadas do Firefox ESR em empresas onde a telemetria não pode ser habilitada
- usuários atrás de proxies MitM, já que nosso sistema de instalação de complementos usa fixação de chave, que não funciona com tais proxies
- usuários de versões legadas do Firefox que não suportam pesquisas
Não podemos fazer nada em relação a esta última categoria de usuários - eles ainda devem atualizar para a nova versão do Firefox, porque os desatualizados apresentam sérias vulnerabilidades não corrigidas. Sabemos que algumas pessoas permanecem em versões mais antigas do Firefox porque desejam executar complementos antigos, mas muitos dos complementos antigos já foram portados para versões mais recentes do navegador. Para outros usuários, desenvolvemos um patch que instalará um novo certificado. Foi lançado como uma versão de correção de bug (nota do tradutor: Firefox 66.0.5), então as pessoas irão obtê-lo - provavelmente já o obtiveram - através do canal de atualização regular. Se você estiver usando uma versão personalizada do Firefox ESR, entre em contato com seu mantenedor.
Entendemos que isso não é o ideal. Em alguns casos, os usuários perderam dados complementares (por exemplo, dados complementares Recipientes com várias contas).
Este efeito colateral não pôde ser evitado, mas acreditamos que no curto prazo escolhemos a melhor solução para a maioria dos usuários. No longo prazo, procuraremos outras abordagens arquitetônicas mais avançadas.
Уроки
Primeiro, nossa equipe fez um trabalho incrível criando e enviando uma correção em menos de 12 horas após a descoberta do problema. Como alguém que participou nas reuniões, posso dizer que nesta situação difícil as pessoas trabalharam muito e muito pouco tempo foi desperdiçado.
Obviamente, nada disso deveria ter acontecido. É evidente que vale a pena ajustar os nossos processos para reduzir a probabilidade de tais incidentes e facilitar a remediação.
Na próxima semana publicaremos uma autópsia oficial e uma lista das alterações que pretendemos fazer. Por enquanto, vou compartilhar meus pensamentos. Primeiro, deve haver uma maneira melhor de monitorar o status daquilo que é uma potencial bomba-relógio. Precisamos ter certeza de que não nos encontraremos em uma situação em que um deles funcione repentinamente. Ainda estamos acertando os detalhes, mas no mínimo é preciso levar em conta todas essas coisas.
Em segundo lugar, precisamos de um mecanismo para fornecer atualizações rapidamente aos usuários, mesmo quando — especialmente quando — todo o resto falhar. Foi ótimo podermos usar o sistema de “pesquisa”, mas é uma ferramenta imperfeita e tem alguns efeitos colaterais indesejados. Em particular, sabemos que muitos usuários têm as atualizações automáticas ativadas, mas preferem não participar da pesquisa (admito, também as desativei!). Ao mesmo tempo, precisamos de uma forma de enviar atualizações aos usuários, mas seja qual for a implementação técnica interna, os usuários devem ser capazes de assinar atualizações (incluindo hot fixes), mas optar por não receber todo o resto. Além disso, o canal de atualização deve ser mais responsivo do que é agora. Mesmo no dia 6 de maio, ainda havia usuários que não aproveitavam nem a correção nem a nova versão. Esse problema já foi trabalhado, mas o que aconteceu mostrou o quanto ele é importante.
Por fim, examinaremos mais de perto a arquitetura de segurança do complemento para garantir que ele forneça o nível certo de segurança com risco mínimo de quebrar alguma coisa.
Na próxima semana veremos os resultados de uma análise mais aprofundada do que aconteceu, mas enquanto isso terei prazer em responder perguntas por e-mail: [email protegido]
Fonte: linux.org.ru