Oito certificados intermédios de eMudhra emSign comprometidos; navegadores bloqueiam

Em 20 de outubro, os principais programas de raízes de navegadores confirmaram que as chaves privadas associadas a oito certificados intermédios emitidos por eMudhra (marca comercial emSign) ficaram comprometidas. Um certificado intermediário pode emitir, por delegação da raiz, certificados válidos para qualquer domínio; quem possui sua chave privada poderia criar certificados que os navegadores aceitariam como legítimos. As assinaturas públicas e a cronologia do aviso permitem reconstruir o que aconteceu e quais impactos concretos cabe esperar, mas há perguntas sem resposta sobre a origem e a extensão da fuga.

Atos confirmados: um pesquisador notificou a detecção da tarde de 17 de outubro (UTC), e o Chrome implementou um bloqueio técnico das chaves nesse mesmo dia entre as 18:05 e as 19:45 UTC; o Firefox recebeu a notificação às 20:06 UTC e distribuiu seu bloqueio (OneCRL) a instalações padrão às 22:59 UTC. Os oito intermediários afetados são: EM DV TLS CA - G3B; EM DV TLS CA - G3C; EM OV TLS CA - G3B; EM OV TLS CA - G3C; EM EV TLS CA - G3B; EM OV CS CA - G3B; e EM OV CS CA - G3C. Foi também confirmado que cada certificado tem uma cópia cross-firmada por Sectigo sob a sua raiz AAA Certificate Services, e que eMudhra revogou os oito certificados após a notificação. Um engenheiro Mozilla, Dennis Jackson, publicou a lista de certificados e os selos que demonstravam a assinatura com as chaves comprometidas.

Tecnicamente, o risco específico dependia de se já existiam certificados emitidos por estes intermediários e se esses certificados tinham sido registados em Certificate Transparency (CT). O Chrome provou que não havia entradas CT conectadas aos seis intermediários usados para TLS antes do bloqueio, portanto, segundo sua verificação, nenhum navegador que exige CT teria estado confiando por defeito em novos certificados assinados por essas chaves. Ainda assim, a existência de cópias cross-firmadas e a presença das raízes em diferentes armazéns complicam o panorama.

Que programas e usuários foram afetados: navegadores que implementam mecanismos de revogação centralizada (Chrome com CRLSet, Firefox com OneCRL e Apple em suas listas) receberam o bloqueio rapidamente e deixaram de confiar nos intermediários; Microsoft e outros fornecedores também bloquearam os certificados. No entanto, muitas aplicações e bibliotecas que validam TLS fora desses navegadores não consultam nem aplicam revogação de forma efetiva. Exemplos relevantes: binários de Go, ambientes que usam a coleção certifi de Python, e pilhas de distribuições de Linux que confiam em armazéns locais de certificados podem continuar validando cadeias enquanto o software não é atualizado ou o bundle não muda.

Acções técnicas já tomadas e seus efeitos: o Google implementou um filtro na biblioteca padrão de Go que detecta e rejeita qualquer cadeia que contenha as chaves comprometidas; essa correção requer recompilar os programas com a versão de Go adesivo. Outros projetos (certifi, webpki-roots, Homebrew) optaram por eliminar a raiz emSign ECC Root CA - G3 de seus pacotes, uma medida efetiva para cortar confiança, mas também quebra a validação para qualquer servidor legítimo que ainda depende dessa raiz. Mozilla e NSS aplicaram a mesma exclusão, e avisaram que alguns servidores deixarão de ser acessíveis para clientes que usam esses repertórios até que esses servidores migrem a certificados encadeados a outras raízes.

Informações ainda incertas: não foi publicado como nem quando exatamente saíram as chaves de eMudhra, nem se a divulgação foi externa ou interna; nem existe evidência pública de abuso prévio, exceto a assinatura que o pesquisador usou para testar a posse (a mensagem assinada com cada chave). Mozilla indica que está trabalhando com a CA em uma pesquisa forense, mas os detalhes do vetor de fuga não foram divulgados.

Consequências práticas: a curto prazo, os navegadores modernos que recebem bloqueio centralizado protegem a maioria dos usuários contra certificados falsos emitidos com essas chaves. Mesmo assim, sistemas que não aplicam revogação ou que não usam os armazéns atualizados continuarão expostos, e a estratégia de retirar a raiz de bundles populares pode produzir indisponibilidade temporária de serviços legítimos até que os seus operadores substituam os certificados. A médio prazo, a confiança no eMudhra/emSign será afectada e os programas que dependem das suas raízes devem avaliar a necessidade de rotação de certificados e auditorias adicionais.

Recomendações concretas - confirmadas e acionáveis - de acordo com o tipo de leitor: para administradores de servidores TLS, primeiro verifique se o seu certificado actual acorrentado a emSign Root TLS CA - G3 ou emSign ECC Root CA - G3; se for assim, obtenha e implementa um novo certificado que encadene a uma raiz diferente e válida o mais rapidamente possível, e confirme que os seus novos certificados estão registados em Certificate Transparency. Ferramentas e pesquisas CT públicas ajudam a detectar emissões inesperadas: consulte a base de dados de Certificate Transparency em https://www.certificate-transparency.org/ e vistas do Google https://transparencyreport.google.com/https/certificates/overview.

Para operadores de software e desenvolvedores: atualize bibliotecas e binários afetados. Se utilizar Go, reconstruya seus projetos com a versão de Go que contém o bloqueio de chaves; Go publica informações de segurança e versões em https://go.dev/security. Se o seu software incorpora bundles externos (certifi, webpki-roots, Homebrew ca-certificates, NSS), atualícelos e provar o impacto em ambientes de staging antes de implantar em produção, porque alguns bundles optaram por retirar a raiz completa e isso pode quebrar conexões.

Para administradores de segurança e responsáveis pela confiança: verifique que seus clientes e agentes confiem em revogação e Remote Settings/atualizações automáticas das listas de bloqueio; se seu ambiente impede que o Firefox ou o Chrome recebam OneCRL/CRLSet, implemente controles adicionais (lista de bloqueio de intermediários por chave pública nos proxies, inspeção TLS) ou considere eliminar temporariamente a confiança nas raízes emSign até que haja certeza de que não existem emissões fraudulentas.

Para usuários finais: mantenha navegadores e sistemas atualizados. Os navegadores citados receberam e aplicado bloqueios que protegem a maioria dos usuários sem intervenção manual; se um site deixar de carregar após as atualizações, é provável que seu operador de servidor deva renovar o certificado.

O que monitorar agora: buscas contínuas no CT para detectar certificados emitidos pelas chaves comprometidas, registro e auditoria do uso de interfaces de emissão pela CA, e comunicados oficiais de eMudhra e programas de raízes. As causas raiz continuam a ser um assunto pendente e justifica que as organizações revejam suas dependências de confiança de terceiros e políticas de revogação para reduzir o impacto de falhas semelhantes no futuro.

Resumo: as chaves de oito intermediários de eMudhra foram rapidamente comprometidas e bloqueadas pelos grandes programas de raízes; navegadores modernos já aplicam mitigações, mas muitas aplicações fora desses clientes continuam vulneráveis até serem atualizadas ou reconstruídas. É imprescindível que administradores renuessem certificados encadeados às raízes afetadas, que desenvolvedores recompilem com versões de livrarias adesivos e que equipes de segurança auditem a aceitação de revogação dentro de seu ambiente.