Comprometimento da CA intermédia eMudhra: listas de bloqueio do navegador e a lacuna de confiança em tempo de execução
Oito chaves de assinatura intermédias da eMudhra foram comprometidas, incluindo seis usadas para TLS e duas para assinatura de código.
Oito chaves de assinatura intermédias da eMudhra foram comprometidas, incluindo seis usadas para TLS e duas para assinatura de código. O episódio segue a confirmação da Mozilla, o bloqueio do navegador e as atualizações a jusante para explicar por que uma aplicação implementada precisa que a sua própria configuração de confiança seja verificada. Um relatório separado do Tor mostra um aviso de identidade de host SSH a fazer o seu trabalho.
Ler a edição escrita (Inglês) ↗
O que este vídeo aborda
- As chaves comprometidas pertencem a signatários intermédios. A desconfiança da raiz pode mitigar uma cadeia sem provar que a chave privada da raiz foi comprometida.
- Uma lista de bloqueio de emergência do navegador e o armazenamento de CA incorporado de uma aplicação podem seguir caminhos de atualização separados. Verifique o processo em execução e a sua configuração de confiança real.
- A Mozilla confirmou independentemente as chaves privadas recuperáveis. O relatório não descreve entradas CT para os intermediários afetados; o uso indevido real contra outros clientes permanece desconhecido.
- Os lançamentos primários verificam certifi 2026.10.19 e Node 24.22.1 para os ramos discutidos. Pacotes de CA personalizados e outros ramos em tempo de execução precisam das suas próprias verificações.
- A conta do pesquisador do Tor com 333 retransmissores diz respeito a um incidente anterior de outubro publicado em 20 de outubro. Aproximadamente dez por cento é uma contagem de retransmissores, não uma medição de tráfego intercetado.
- Um tempo limite de rede por si só não estabelece que a validação de certificados rejeitou uma cadeia comprometida. Preserve a verificação e distinga erros de transporte de falhas de autenticação.
Transcrição traduzida
Traduzido da narração original em inglês. Áudio e legendas disponíveis são controlados pelo YouTube.
Por que um navegador corrigido pode deixar uma aplicação exposta?
0:00 A correção do navegador eMudhra soa como um sinal de tudo limpo. Oito chaves de assinatura comprometidas ainda deixam o software com decisões de confiança obsoletas. Neste vídeo, quem pode assinar? Por que os clientes discordam? E qual atualização realmente chega à sua aplicação? Uma pequena dependência mantém a sua própria lista de confiança. Voltaremos ao processo que decide se a sua correção chegou. É quarta-feira, vinte e um de outubro, e este é o The Daily Diff.
0:22 eMudhra é uma autoridade de certificação. Assina certificados digitais que ajudam o software a autenticar sites e serviços. As chaves comprometidas incluem seis usadas para conexões web e duas para assinatura de software. Um intermédio é um signatário delegado sob uma raiz confiável. Na sexta-feira, um repórter chamado Wayne enviou provas aos programas de raiz. Até terça-feira, a página do incidente público explicava a limpeza. Hoje, os desenvolvedores descobrem quantas cópias de confiança a sua aplicação perfeitamente normal coletou.
O que uma chave intermédia autoriza?
0:49 Aqui está a cadeia comum. Um site apresenta um certificado, um intermédio assina-o, e o seu cliente segue a cadeia até uma raiz em que já confia. A raiz é o seu ponto de partida local. Quem controla a chave privada do intermédio pode assinar sob essa autoridade. Uma assinatura matematicamente válida pode ter um signatário completamente não confiável. O validador precisa de uma forma de retirar a confiança após um comprometimento. Wayne assinou a mensagem, Temos um problema aqui, Wayne,
1:12 com cada chave. A Mozilla verificou o controlo da chave e, em seguida, recuperou as chaves de forma independente. A resposta de emergência começou com uma frase que soa como se alguém tivesse notado que a impressora do escritório estava a fumegar.
O que está provado e o que permanece desconhecido?
1:22 O relatório público diz que as chaves foram geradas incorretamente e recuperáveis dos certificados, criados em abril do ano passado. O uso indevido real contra outro software ainda é desconhecido. A autoridade de assinatura recuperável é suficientemente urgente sem uma lista de vítimas inventada. Há um limite importante aqui. O relatório não encontrou entradas de transparência de certificados para esses intermediários durante esse período. Isso significa que os navegadores que aplicam a transparência não poderiam ter sido atacados por
1:42 esta via. Essa verificação extra do navegador ajuda a explicar por que apenas o título exagera a situação. A eMudhra disse à Mozilla que cerca de trinta mil certificados precisavam de ser migrados para outra cadeia. São serviços em funcionamento cujos proprietários devem substituir os certificados durante a limpeza. Em algum lugar, um convite de calendário acabou de se tornar uma dependência de produção. Os fornecedores de navegadores distribuem listas de bloqueio de emergência.
Por que o navegador e o tempo de execução discordam?
2:03 O relatório regista a ação do Firefox e do Chrome na sexta-feira, seguida pela Apple e Microsoft. Esses clientes podem rejeitar o intermediário comprometido enquanto reconhecem a sua raiz. Essa regra viaja separadamente do pacote da sua aplicação. Alguns clientes verificam uma cadeia contra raízes confiáveis sem consumir informações de revogação de emergência. A autoridade pode publicar uma revogação, e esse cliente pode continuar a aceitar a cadeia. Colocar uma placa na porta funciona melhor quando o visitante lê as placas.
2:27 A Mozilla diz que alguns perfis Android não aplicaram a lista de bloqueio atualizada no arranque. Uma correção foi lançada no Firefox um cinquenta e oito ponto zero dois. Portanto, mantenha o navegador atualizado também. O anúncio não pode inventariar o seu telefone. Os mantenedores podem remover uma âncora de confiança quando os clientes não possuem bloqueio mais restrito. O tópico da Mozilla descreve a desconfiança de emergência da raiz emSign ECC, geração três. Remover uma raiz de um armazenamento de confiança bloqueia as cadeias que dependem dela, mesmo quando a chave privada da raiz em si nunca foi comprometida.
2:54 A versão mais recente do certifi do Python é uma atualização a jusante. O seu commit também restaura as raízes emSign não afetadas após uma remoção anterior.
Quais atualizações chegaram ao Python e ao Node?
3:01 Apagar tudo o que tem o nome da empresa é um substituto péssimo para o pacote mantido. Quer que a cadeia perigosa seja rejeitada e que os clientes legítimos continuem a trabalhar. O histórico de lançamentos preserva ambas as decisões. A limpeza de segurança tem o trabalho glamoroso de ser urgente, precisa, e culpada por qualquer serviço que falhe durante o almoço. A versão vinte e quatro ponto vinte e dois ponto um do Node foi lançada hoje com raízes atualizadas. Verifique o aviso do seu próprio ramo e a configuração de CA real.
3:26 Um pacote personalizado pode mudar qual armazenamento de confiança o processo usa. No Tor, um pesquisador publicou ontem um relato de trezentos e trinta e três retransmissores de saída comprometidos.
O que o aviso de chave de host do Tor apanhou?
3:36 A interceção começou no início deste mês. Os retransmissores foram sinalizados e desativados dias depois, antes da chegada do relatório. O SSH avisou o pesquisador que a identidade do servidor havia mudado. Ele relatou à equipa de saúde da rede do Tor. O aviso do operador confirma relatos de interceção. Esse aviso estava a fazer exatamente a coisa inconveniente que a autenticação deveria fazer. Aproximadamente dez por cento contavam retransmissores com capacidades diferentes,
3:57 deixando a partilha de tráfego não medida. O roteamento Tor e a identidade do servidor SSH têm trabalhos separados. Verifique uma chave de host alterada através de um canal confiável antes de aceitá-la e iniciar sessão. De volta à sua aplicação, comece com o contentor ou ambiente virtual em execução. Encontre o pacote de CA que realmente usa e aplique a atualização mantida relevante.
Como verificar a correção implementada?
4:12 Reconstrua e reinicie o processo implementado para que possa carregar o material de confiança alterado. Use as cadeias de teste públicas dos mantenedores no ambiente real do cliente. Mantenha o erro de certificado separado de um tempo limite de rede. Uma conexão falhada no Wi-Fi do hotel é um excelente teste do Wi-Fi do hotel. A pequena dependência é um armazenamento de confiança empacotado separadamente, como o certifi. O seu navegador de desktop nunca edita essa dependência dentro de um contentor antigo. O processo implementado e a sua configuração decidem se a correção chegou. Esse é o local para verificar a sua atualização.
4:42 Se preferir ler isto a ouvir-me dizer, o diff chega à sua caixa de entrada todas as manhãs, gratuitamente em the daily diff dot dev, link abaixo. Então, o veredicto de hoje é NEEDS REVIEW.
O que recebe o selo NEEDS REVIEW?
4:51 Quero que a confiança do cliente implementado seja verificada antes que alguém encerre este incidente. Subscreva, clique no sino e diga-me nos comentários se o teria carimbado de forma diferente. E esse é o diff de hoje. Sou o Niko da Axrisi. Unir com responsabilidade. Unir com responsabilidade.
Fontes
- eMudhra Intermediate CA CompromiseDennis Jackson
- Private key compromise of eMudhra Intermediate CertificatesMozilla Bugzilla
- certifi 2026.10.19 releasecertifi
- Restore unaffected emSign rootscertifi
- Node 24.22.1 security releaseNode.js
- Update root certificates to NSS 3.131.1Node.js
- How I got over 300 Tor exit nodes removedKABA
- Security incident affecting some relay operatorsTor Project network health



