Ing. Calogero Bono
A Cloudflare publicou uma análise de acompanhamento sobre as oito chaves criptográficas fracas da autoridade certificadora indiana eMudhra, descobertas em 19 de outubro de 2026. Segundo a empresa, os sistemas mais críticos já estão protegidos e não há sinais de interceptação de suas conexões. No entanto, certificados falsos apareceram em poucas horas, e muitos navegadores, bots e aplicativos incorporados continuam aceitando a cadeia comprometida. Para quem administra sites e serviços online, o risco não é teórico.
Alguns termos, antes de entrarmos nos fatos. CA (certificate authority) é a entidade que emite os certificados nos quais se apoia o cadeado do HTTPS. Chave intermediária é a chave com que a CA assina os certificados dos sites. CRL é a lista de certificados revogados. Certificate Transparency é o registro público dos certificados emitidos, e os SCT são os seus recibos. SAN e SNI indicam os nomes de domínio presentes no certificado e o que o cliente solicita.
O que aconteceu com as chaves da eMudhra?
Segundo a Cloudflare, a eMudhra deveria escolher um número de 115 dígitos para proteger suas chaves e usou o número 4. As outras sete chaves eram igualmente fracas, com valores como 56, 66, 115, 155, 156, 230 e 237.
A Cloudflare explica que as chaves intermediárias podem ser reconstruídas quase imediatamente por qualquer pessoa, a partir dos certificados públicos. Assim, qualquer um pode criar certificados para qualquer domínio, que um cliente desatualizado e sem verificação de Certificate Transparency aceitaria.
Para a empresa, o caso não tem precedentes. Incidentes como DigiNotar, TÜRKTRUST e TrustWave haviam dado o poder de emitir certificados falsos a poucos atores.
Como a Cloudflare reagiu?
Em 19 de outubro começaram as correções nos sistemas de alto impacto, a começar pelos proxies Pingora voltados aos servidores dos clientes, que gerenciam a maior parte das conexões de saída. Em poucas horas, passaram a rejeitar as chaves vulneráveis.
Em paralelo, uma análise de código assistida por IA identificou em quatro horas os outros sistemas que confiavam nessas chaves. Para cada um foi aberto um ticket. As intervenções urgentes precisavam ser feitas imediatamente, as demais até o fim da semana passada. No momento da publicação, restam poucos tickets de baixo impacto a fechar.
As chaves já foram usadas para falsificar certificados?
Sim, segundo a Cloudflare. Desde 21 de outubro, um log no Pingora registra os certificados assinados com as chaves fracas. Em cerca de uma semana, contou aproximadamente 22.000 tentativas de handshake. Dois terços eram direcionadas a sites de teste, quase todo o restante a servidores que parecem ter criado sozinhos um certificado com a intermediária fraca. Todo handshake com verificação ativa foi rejeitado.
Cerca de 160 casos eram anômalos, com nomes de domínio de outras organizações, alguns ligados a dispositivos IoT para consumidores. Alguns certificados tinham validade superior a dois anos, mais do que uma CA pública pode emitir. Um deles é de 20 de outubro às 18:19 UTC, menos de uma hora após a divulgação do aviso da Mozilla.
Para a Cloudflare, porém, parecem certificados padrão dos servidores, não tentativas de interceptação. O caso é semelhante a outros em que uma vulnerabilidade é sondada logo de início, como o da Oracle E-Business Suite.
Quantos visitantes ainda estão vulneráveis?
A Cloudflare não pode testar diretamente os visitantes sem interromper as conexões. Por isso, acrescentou duas sondas às páginas de verificação, uma com certificado eMudhra e outra de controle. Em uma semana, coletou 50 milhões de sondagens.
O quadro que descreve é este.
- Os navegadores modernos e atualizados estão em sua maioria protegidos.
- Bots e navegadores antigos não estão.
- Os aplicativos com navegador incorporado, como o Android WebView, ainda aceitam a cadeia em 30% a 40% dos casos.
- Nas grandes redes, mais da metade das sondas aceita a cadeia comprometida.
Após algum progresso no primeiro fim de semana, a tendência está estável. O tráfego, porém, é desequilibrado por bots não confirmados, e apenas os clientes que executam JavaScript enviam sondas.
Limites a conhecer
A eMudhra declara um erro em um script de geração de chaves, mas ainda não o divulgou. Permanecem sem esclarecimento o papel de revisores e cross-signers e por que uma CRL foi assinada antes com uma chave talvez correta e depois com a fraca. A Cloudflare exclui interceptações apenas com base em sinais indiretos. Uma interceptação direcionada não está descartada. Os dados dos visitantes também são distorcidos pelos bots.
O que muda para quem trabalha com o digital
Se você administra sites, aplicativos ou sistemas de gestão, confira se servidores, bibliotecas e clientes rejeitam as chaves da eMudhra. Também contam os softwares que se conectam a serviços externos, como aplicativos móveis com WebView e scripts automáticos, pois costumam ficar para trás. Quem desenvolve em macOS deve seguir com atenção as instruções indicadas pela Cloudflare. Se você tem uma hospedagem com atualizações de segurança gerenciadas, verifique com o fornecedor o status da correção. O tema também toca quem usa certificados para assinatura digital.
Nossa opinião
O dado mais alarmante não é o bug, mas a lentidão das atualizações. Uma chave que qualquer um pode reconstruir é um erro enorme, e o fato de que mais da metade das sondas ainda aceite a cadeia mostra um problema mais amplo, ou seja, o software que ninguém atualiza. O caso lembra o quanto pesam as chaves criptográficas, como no malware KeyDrift no Cisco SD-WAN. Resta também uma dúvida sobre o sistema de controle, porque auditorias e cross-signing não impediram nada.
Perguntas frequentes
O que são as chaves fracas da eMudhra?
São oito chaves intermediárias de uma CA, geradas com números pequenos como 4 ou 56. Por isso, qualquer pessoa pode reconstruí-las a partir dos certificados públicos e assinar certificados falsos.
A Cloudflare foi comprometida?
Segundo a Cloudflare, não há provas de interceptação de suas conexões. Os sistemas de alta prioridade foram atualizados e restam poucos tickets de baixo impacto.
Qual é o risco para um site ou aplicativo?
Depende do cliente. Um cliente desatualizado e sem verificação de Certificate Transparency pode aceitar certificados falsos para qualquer domínio, permitindo uma possível interceptação.
Quais softwares continuam mais expostos?
Bots, navegadores antigos e navegadores incorporados como o Android WebView. Nestes últimos, segundo a Cloudflare, de 30% a 40% ainda aceitam a cadeia comprometida.
O que devo fazer agora?
Atualize seus sistemas e siga as instruções do site mantido por Dennis Jackson, citado pela Cloudflare. Se você desenvolve em macOS, dê prioridade a essas orientações.
O que acompanhar nas próximas semanas no caso eMudhra
O caso está aberto em duas frentes, as explicações da eMudhra e o ritmo das atualizações. Vale acompanhar as duas.
- Verifique se a eMudhra publica o script de geração de chaves e as conclusões sobre auditorias e cross-signers.
- Acompanhe as atualizações dos navegadores e dos runtimes usados pelos seus aplicativos, em especial os WebViews.
- Confira nos logs dos seus servidores eventuais certificados com nomes de domínio que não correspondam aos solicitados.
