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.
Perguntas e respostas
O que um comprometimento da chave de uma CA intermediária permite que um atacante faça?
Quem controla a chave privada de uma intermediária pode assinar certificados sob essa autoridade, e a assinatura é matematicamente válida, mesmo que o signatário não seja confiável. No caso eMudhra, a Mozilla verificou o controlo da chave e recuperou as chaves independentemente. Oito chaves foram afetadas, seis usadas para ligações web e duas para assinatura de software. O relatório de Dennis Jackson afirma que o uso indevido real contra outro software ainda é desconhecido.
Por que um navegador pode rejeitar uma cadeia de certificados que uma aplicação de servidor ainda confia?
Os navegadores recebem listas de bloqueio de emergência que podem rejeitar uma intermediária comprometida enquanto ainda reconhecem a sua raiz. Essa regra viaja separadamente da loja de CA empacotada de uma aplicação. O relatório regista a ação do Firefox e Chrome na sexta-feira, seguida pela Apple e Microsoft. Alguns clientes verificam cadeias contra raízes confiáveis sem consumir informações de revogação de emergência e podem continuar a aceitar uma cadeia revogada.
Quais atualizações transportam a desconfiança da eMudhra para aplicações Python e Node.js?
O lançamento certifi 2026.10.19 do Python é uma atualização a jusante, e o seu commit também restaura raízes emSign não afetadas após uma remoção anterior. O Node 24.22.1 foi enviado com raízes atualizadas, como um lançamento de segurança para os ramos discutidos. Bundles de CA personalizados e outros ramos de tempo de execução precisam das suas próprias verificações, porque um bundle personalizado pode mudar qual loja de confiança o processo usa.
Como verifico se uma correção de desconfiança de CA realmente chegou à minha aplicação implementada?
Comece com o contentor em execução ou ambiente virtual e encontre o bundle de CA que ele realmente usa. Aplique a atualização mantida relevante, depois reconstrua e reinicie o processo para que ele carregue o material de confiança alterado. Teste com as cadeias de teste públicas dos mantenedores no ambiente real do cliente, e mantenha um erro de certificado separado de um tempo limite de rede, pois um tempo limite sozinho não mostra que a validação rejeitou uma cadeia.
As equipas devem considerar o incidente eMudhra encerrado assim que os navegadores bloquearem as intermediárias?
O veredicto do The Daily Diff foi NEEDS REVIEW. O episódio quer a confiança do cliente implementado verificada antes que alguém encerre o incidente. Uma lista de bloqueio do navegador e a loja de CA empacotada de uma aplicação seguem caminhos de atualização separados, então o processo implementado e a sua configuração decidem se a correção chegou. A Mozilla confirmou chaves privadas recuperáveis, enquanto o uso indevido contra outros clientes permanece desconhecido.
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



