CA intermediária comprometida: a cadeia de confiança racha

Aqui vai uma opinião que parece às avessas: os piores incidentes com autoridades certificadoras não são os em que um atacante invade o sistema. O recente comprometimento de CA intermediária da eMudhra prova isso. Oito chaves de CA intermediária podiam ser recuperadas a partir dos próprios certificados, sem nenhuma intrusão, porque a cerimônia de geração de chaves da própria CA produziu chaves privadas tão fracas que uma delas era literalmente o número 4. Ninguém roubou essas chaves. Elas já nasceram comprometidas. E isso é um modo de falha mais assustador do que qualquer violação, porque você não resolve rotacionando credenciais e tapando um buraco. A confiança em si era defeituosa desde o primeiro dia.

Se você roda qualquer coisa que faz conexões TLS fora de um navegador — e você roda — este caso merece sua atenção. Os navegadores foram protegidos em poucos dias. O resto do ecossistema, as chamadas curl nos seus cron jobs, os serviços Python que fixam o certifi, os binários Go com raízes embutidas, ainda está correndo atrás. Deixa eu explicar o que realmente aconteceu, por que o comprometimento de uma intermediária é categoricamente pior que o de um certificado folha e o que a remediação desigual nos diz sobre o estado da revogação na internet moderna.

O Que Deu Errado de Fato na eMudhra

Segundo a avaliação preliminar da própria CA no rastreador de incidentes da Mozilla, a história é quase dolorosamente banal. Um script de cerimônia de geração de chaves — o processo controlado e auditado pelo qual uma CA cria suas chaves mais sensíveis — foi modificado com um desvio aprovado para testar um procedimento de wrap/unwrap de chave para exportação. Uma falha nesse código modificado fez com que um segundo conjunto de chaves ECC fosse gerado no HSM, e essas chaves eram fracas. Não era um caso de “entropia reduzida”. Era fraqueza do tipo recuperável trivialmente a partir do certificado público.

Pense no que isso significa. Uma chave privada ECC deveria ser um número aleatório de 256 bits. A segurança de todo o esquema depende do problema do logaritmo discreto: dada a chave pública, encontrar o escalar privado deveria ser computacionalmente inviável. Mas se o seu escalar “aleatório” é um único byte, a chave pública é apenas o ponto gerador multiplicado por esse byte, e qualquer um pode testar todas as 256 possibilidades em microssegundos num notebook. Uma das oito chaves era, segundo relatos, o inteiro 4. Isso não é um comprometimento no sentido tradicional; é um certificado que nunca foi realmente seguro, emitido sob uma raiz confiada pela Mozilla, Microsoft, Apple e Chrome.

O pesquisador que reportou o problema, identificado como Wayne, comprovou a posse assinando uma mensagem com cada uma das oito chaves privadas e enviando as assinaturas aos programas de raiz. Qualquer pessoa podia verificar a prova com alguns comandos do OpenSSL: extrair a chave pública de cada certificado intermediário e checar se a assinatura da mensagem valida com ela. Essa é a coisa elegante e assustadora da prova criptográfica de posse de chave: não há ambiguidade, nem nevoeiro de PR do tipo “levamos a segurança a sério”. A matemática fecha ou não fecha. Fechou.

Por Que o Comprometimento de uma Intermediária É Pior que o de um Folha

Quando a chave privada de um certificado folha vaza — digamos que a chave do seu api.example.com acaba num repositório público no GitHub — o raio de impacto é um hostname, talvez alguns se for wildcard. Você revoga o certificado, emite um novo e segue em frente. Irritante, não existencial.

Uma chave de CA intermediária é um bicho totalmente diferente. A Web PKI funciona como uma cadeia de assinaturas: uma CA raiz (mantida offline, protegida como material nuclear) assina intermediárias, e as intermediárias assinam os certificados folha que os servidores de fato apresentam. Quem detém a chave privada de uma intermediária é aquela CA, para todos os efeitos criptográficos. Essa pessoa pode emitir um certificado válido para google.com, para o seu banco, para o domínio de SSO interno da sua empresa — e todo cliente que confia na cadeia vai aceitar sem reclamar. Não há limite de taxa, nenhuma autoridade central para consultar, nenhuma forma de distinguir uma assinatura fraudulenta-mas-válida de uma legítima.

O incidente da eMudhra multiplicou isso por oito intermediárias, algumas com assinatura cruzada através de raízes da Sectigo, encadeadas a repositórios de confiança distribuídos em bilhões de dispositivos. Por cerca de um ano e meio — desde a criação dos certificados falhos até a divulgação — qualquer cliente que confiasse nessas intermediárias e não exigisse Certificate Transparency poderia ter sido personificado por quem se desse ao trabalho de recuperar as chaves. Essa é a janela. Não sabemos se alguém a explorou e, sem uma detecção feliz nos logs de CT ou um ataque observado, talvez nunca saibamos.

É por isso que os programas de raiz tratam incidentes com intermediárias com uma gravidade que incidentes com certificados folha nunca recebem. Desconfiar de uma intermediária significa que todo certificado que ela já emitiu se torna inválido — milhares de sites quebrando de uma vez. A saga da desconfiança da Symantec, que se desenrolou ao longo de anos, é o exemplo canônico de quão dolorosa fica a remediação completa quando as operações de uma CA são consideradas não confiáveis. O sistema funciona, mas funciona como amputação, não como cirurgia.

Certificate Transparency Foi o Herói Acidental

A parte da história que merece mais atenção: Chrome, Safari, Firefox e Edge foram, sem dúvida, protegidos antes de alguém saber que havia um problema. Não por causa da revogação — por causa do Certificate Transparency.

Navegadores que exigem CT só aceitam certificados publicamente confiáveis que estejam registrados em logs públicos de CT, somente de inclusão. As intermediárias comprometidas da eMudhra não têm entradas nos logs de CT para o período em questão, o que significa que qualquer certificado folha que um atacante tivesse emitido com essas chaves seria rejeitado por clientes que exigem CT — chegaria sem timestamps de certificado assinados válidos. A fraude precisaria ser publicada para ser acreditada, e publicá-la a exporia imediatamente.

O CT foi projetado para pegar emissões indevidas depois do fato, para tornar certificados fraudulentos detectáveis. Neste incidente, funcionou como um controle preventivo: tornou as chaves comprometidas quase inúteis contra a população de navegadores, que é o conjunto de alvos de maior valor para interceptação em massa. É uma boa notícia genuína para uma peça de infraestrutura em que a maioria dos engenheiros nunca pensa.

Mas — e aqui eu admito os limites do meu otimismo — a exigência de CT é essencialmente um luxo dos navegadores. A grande maioria dos clientes TLS na internet não verifica SCTs. Sua chamada curl não verifica. Sua chamada Python requests não verifica. A frota de IoT que se conecta à nuvem de um fornecedor não verifica. Para todos esses, a única proteção era que os dados de revogação chegassem ao repositório de confiança a tempo, e é aí que a história fica feia.

A Lacuna da Revogação: Navegadores vs. Todo o Resto

Os fornecedores de navegadores lidaram bem com isso, e merecem crédito pela infraestrutura construída há uma década. A Mozilla distribui o OneCRL — um mecanismo push para desconfiar de certificados intermediários e raiz — há mais de dez anos, e remediou este incidente para usuários do Firefox em poucas horas, sem necessidade de atualização do navegador. Os CRLSets do Chrome e os mecanismos equivalentes da Apple fizeram o mesmo nas suas plataformas em alguns dias. A CA revogou as intermediárias. Do ponto de vista do usuário de navegador, este incidente acabou quase antes de começar.

Agora olhe para o mundo fora do navegador. A lista de remediação parece um inventário da cadeia de suprimentos de software: pacotes ca-certificates atualizados para Ubuntu, Debian, Fedora, Alpine, Arch, Gentoo; uma nova versão do NSS; um novo bundle de CAs do curl; certifi para Python; rustls-webpki e webpki-roots para Rust; releases pontuais do Go; versões de patch do Electron em três linhas de release; o ca-bundle do Composer; o castore do Elixir. Cada um desses é um artefato separado, com um cronograma de release separado, consumido por um mecanismo de atualização separado. Alguns ainda estavam pendentes dias após a divulgação.

E aí está a categoria que me tira o sono: software que embute o próprio repositório de CAs dentro do binário. Um serviço Go com linkagem estática construído ano passado carrega suas raízes no artefato compilado. Reconstruir e reimplantar é a única correção — não há pacote do sistema para atualizar. Multiplique isso por cada imagem de contêiner no seu registro com uma camada /etc/ssl/certs embutida, cada app Electron em cada desktop, cada imagem de firmware em cada dispositivo conectado, e você vê a forma do problema. O repositório de confiança do sistema é a parte fácil. Já escrevemos sobre como dispositivos embarcados e OT transformam incidentes de segurança em sagas de vários anos; uma CA comprometida é exatamente o tipo de evento em que esses dispositivos simplesmente nunca são corrigidos.

A Cauda Longa dos Repositórios de Confiança que Ninguém Possui

Há um caso especial deste incidente que merece um parágrafo próprio porque ilustra perfeitamente o ponto: o macOS. A plataforma da Apple bloqueou as intermediárias comprometidas no nível do sistema operacional, e prontamente. Mas o /usr/bin/curl embutido verifica contra /etc/ssl/cert.pem — um arquivo que não foi atualizado — e não verifica revogação. Ou seja, você pode ter um Mac totalmente atualizado onde o Safari rejeita um certificado forjado e o curl da mesma máquina aceita sem problemas. Duas decisões de confiança, uma máquina, respostas opostas.

Essa fragmentação é a verdadeira lição. Costumamos falar da “Web PKI” como se fosse um sistema só. São dezenas de sistemas com propriedades muito diferentes:

• Navegadores: revogação por push (OneCRL, CRLSets), exigência de CT, atualizações automáticas. Remediação medida em horas a dias.
• Repositórios de confiança do SO: atualizações gerenciadas por pacotes (ca-certificates, ca_root_nss). A remediação depende do cronograma de release da distro e de a máquina algum dia ser atualizada.
• Ecossistemas de linguagem: certifi, webpki-roots, raízes embutidas do Go, o repositório Mozilla empacotado do Node. Remediar significa lançar uma nova versão e esperar atualizações de dependências em milhares de projetos.
• Artefatos compilados e imagens: binários, contêineres, firmware. Remediar significa reconstruir e reimplantar, o que na prática significa uma longa cauda vulnerável que se estende por anos.
• IoT e embarcados: muitas vezes sem nenhum caminho de atualização. Exposição praticamente permanente.

Os navegadores passaram uma década investindo exatamente nesse cenário. Quase ninguém mais investiu. Um comentário de upstream do lado da Mozilla resumiu sem rodeios: fora do ecossistema dos navegadores, houve pouco ou nenhum investimento em revogação, e para esses clientes esse tipo de incidente é um problema enorme. Isso bate com tudo que vi rodando infraestrutura. Se você já lidou com os pontos cegos de como os eventos de autenticação em nuvem são registrados em log, vai reconhecer o padrão: o caminho crítico é bem instrumentado e a cauda longa é um quarto escuro.

Como Verificar se Seus Clientes Ainda Estão Vulneráveis

Teoria à parte, você deveria de fato testar o seu parque de sistemas, e o bom do TLS é que dá para testar empiricamente. Membros da comunidade subiram hosts servindo certificados assinados pelas intermediárias comprometidas; se o seu cliente conecta sem erro de certificado, ele ainda confia nelas. O padrão geral para testar curl ou qualquer ferramenta de linha de comando fica assim:

# A certificate error here means you're protected.
# A successful response means this client still trusts a compromised intermediate.
curl -v https://dv-g3b-emudhra.we-have-a-problem.com/
# You can also test whether a client will accept a forged cert for an
# arbitrary hostname by pointing it at a test server:
curl -v https://example.org --connect-to example.org::2.29.126.86:

Execute isso em todos os contextos que importam: seus notebooks de desenvolvedor, seus runners de CI, suas imagens base de contêiner, seus servidores. A resposta vai variar entre eles, e as diferenças são o ponto. Para um inventário rápido do que precisa ser atualizado:

• Serviços Go: reconstrua com Go 1.27.3 ou 1.26.10 ou posterior — as raízes estão compiladas dentro.
• Python: certifi 2026.10.19 ou posterior (confira as versões do pip e do uv também, pois eles empacotam os próprios).
• Rust: rustls-webpki 0.103.16 e webpki-roots / webpki-root-certs 1.0.10.
• Node.js e Electron: releases pendentes ou de patch por linha de release; verifique cada artefato distribuído.
• Repositórios do sistema: pacotes ca-certificates atualizados já estão disponíveis para Ubuntu, Debian, Fedora, Alpine, Arch, Gentoo; o ca_root_nss do FreeBSD estava pendente no momento em que escrevi.

Se você não pode esperar por um pacote, a maioria das distros Linux permite desconfiar manualmente das raízes afetadas. No Debian/Ubuntu basta marcar os certificados com um prefixo ! em /etc/ca-certificates.conf e executar update-ca-certificates; na família Fedora/RHEL você extrai as raízes para /etc/pki/ca-trust/source/blocklist/ e executa update-ca-trust. O NixOS tem uma opção declarativa limpa:

security.pki.caCertificateBlacklist = [
"Comodo AAA Services root"
"emSign ECC Root CA - G3"
];

Repare no que você de fato está desconfiando nesses contornos: as raízes às quais essas intermediárias se encadeiam. Essa é a realidade de instrumento contundente da remediação de PKI. Na maioria das ferramentas de repositório de confiança não existe uma primitiva do tipo “desconfie só desta intermediária”, então você bloqueia uma raiz e aceita o dano colateral em certificados não relacionados. É a escolha certa numa emergência, mas continua sendo uma escolha com custo.

Onde Minha Tese Contrária Não Se Sustenta

Comecei argumentando que falhas de geração de chaves autoinfligidas são piores que violações. Deixa eu ser honesto sobre onde isso quebra. Uma violação tradicional — pense na DigiNotar — pelo menos pressupõe que a CA operava com competência até um atacante levar a melhor, e CAs competentes são justamente o que todo o sistema aposta. Uma cerimônia de chaves que emite a chave privada “4” indica que os controles auditados, os procedimentos do HSM, as caixinhas de conformidade, nada disso pegou um defeito catastrófico na operação mais sensível que uma CA realiza. Isso não é um problema de adversário; é um problema de garantia, e garantia é todo o produto que uma CA vende.

Onde a tese realmente falha: violações são mais difíceis de se defender e podem ficar silenciosas por mais tempo. Um atacante que rouba cuidadosamente a chave de uma intermediária pode usá-la com parcimônia, para interceptação direcionada, e nunca tocar num cliente que exige CT. Chaves fracas, por outro lado, são descobertas por qualquer um que escaneie certificados públicos — que é exatamente como este caso veio à tona. Há um argumento de que o catastrófico-mas-óbvio vence o sutil-mas-direcionado. Não compro totalmente essa ideia, mas também não consigo descartá-la. A verdade é que os dois modos de falha caem no mesmo lugar: uma intermediária que precisa ser desconfiada e uma cauda longa de clientes que não vão receber o recado por meses.

O Que Você Deveria Fazer a Respeito

Você não consegue consertar a Web PKI. Mas pode reduzir sua exposição à próxima falha:

• Teste, não presuma. Sonde seus clientes contra hosts que servem as cadeias comprometidas. Isso leva uma tarde e vai te surpreender.
• Reconstrua os artefatos compilados. Binários Go e imagens de contêiner carregam seus repositórios de confiança consigo. “Atualizamos a imagem base” não significa nada até você reimplantar.
• Faça um inventário dos seus repositórios de confiança. Você não consegue remediar o que não enumerou. Conte cópias do certifi, bundles vendorizados e apps Electron como se importassem, porque importam.
• Prefira repositórios de confiança do sistema sempre que possível. Cada bundle vendorizado é um patch que você vai esquecer de enviar. Centralizar no repositório do SO não elimina o problema, mas te dá um único ponto de controle.
• Acompanhe o ecossistema de CT e revogação. Projetos que buscam levar revogação de nível navegador para clientes fora dos navegadores existem e merecem apoio; este incidente é o melhor argumento que eles jamais terão para conseguir financiamento.
• Trate incidentes de CA como incidentes de segurança. Eles devem acionar alguém, disparar uma rodada de inventário e gerar um registro por escrito — igual a uma credencial vazada. Porque é isso que eles são.

O resumo incômodo: o freio de emergência da Web PKI funciona lindamente exatamente nos clientes que menos precisavam dele, porque o CT já os cobria. Os clientes que precisavam do freio — headless, embarcados, vendorizados, esquecidos — quase todos não têm nenhum. A próxima comprometida de CA intermediária é uma questão de quando, não de se. A única variável sob seu controle é se o seu próprio parque de sistemas vai perceber.