Uma empresa de certificados na Índia criou oito chaves privadas. O valor de uma delas era 4.
Na sexta-feira passada, às 20h06, um pesquisador chamado Wayne informou o ocorrido ao Firefox e ao Chrome. Às 21h48 daquela noite, a equipe da Mozilla já tinha calculado as oito chaves por conta própria. Nem perguntou que método a outra parte tinha usado. Às 22h59, a lista de bloqueio já tinha sido distribuída para o Firefox, que a aplica por padrão. Menos de três horas.
Essas chaves deveriam ser chaves privadas da curva P-384, cujo espaço de busca normalmente equivale a um número decimal de 116 dígitos.
Os valores medidos foram 4, 56 e 115; o maior chegou a apenas 237. Todos abaixo de 256. O pesquisador Scott Helme disse que extraiu as oito chaves dos certificados públicos em menos de um segundo. Extraiu. Foi rápido assim.
Muita gente acha que um problema com certificados significa que houve uma invasão. Não foi o caso desta vez. Na verdade, ninguém entrou no centro de dados, nenhum dado foi perdido e todos os controles físicos e lógicos permaneceram intactos. Foi o que a eMudhra escreveu no comunicado à Bolsa de Valores de Bombaim e à Bolsa Nacional da Índia. Então, como essa chave ficou fraca? Um erro no script de geração. Na cerimônia de geração de chaves de 30 de abril do ano passado — uma cerimônia conduzida sem pular nenhuma etapa, usando módulos de hardware de nível 3 segundo a norma FIPS 140-2 —, a etapa de wrap e unwrap gerou um conjunto extra de chaves fracas. Por azar, os rótulos eram parecidos. Depois, ao preparar a solicitação de assinatura, escolheram o conjunto errado e enviaram o fraco.
Depois de passar por auditorias por dois anos, em meados de 2025, a empresa entrou na lista de confiança dos navegadores. E, durante dezoito meses, ninguém percebeu. As auditorias verificavam se o processo tinha seguido a documentação, não se a chave tinha aleatoriedade suficiente.
O problema também está na estrutura da cadeia de confiança. Os certificados assinados por uma CA intermediária são aceitos por todos os sistemas abaixo dela. Das oito chaves intermediárias, seis eram usadas para TLS e duas para assinatura de código. Yash Kadakia, da Security Brigade, estima que cerca de trinta mil certificados legítimos ainda em uso precisarão ser migrados. Ele também diz que, na cadeia de confiança da internet global, um erro de uma empresa pode arrastar para o problema organizações que nunca tiveram contato com ela.
Vale observar a velocidade de reação dos quatro navegadores. Chrome e Firefox bloquearam os certificados no dia 17. A Apple, no dia 19. A Microsoft, no dia 20. A Cloudflare recebeu o aviso no dia 19 e publicou um relatório no dia 20. O Google bloqueou o hash da chave pública, então também foram bloqueados os certificados cross-signed feitos com a mesma chave. Nem foi preciso reiniciar. Essa parte foi resolvida de forma eficiente.
O que realmente ficou de fora foi tudo o que não é navegador. Serviços escritos em Go, programas Python que usam certifi, webpki-roots do Rust, uma série de aplicativos Android com seus próprios repositórios de certificados incluídos, sistemas Java antigos em centros de dados, gateways corporativos, câmeras, roteadores: as listas de confiança deles não são as mesmas do Chrome. Enquanto os navegadores resolveram o problema em três horas, esses componentes precisam esperar pela atualização da própria versão. A rapidez da correção depende da frequência com que cada componente é atualizado, não tanto da gravidade do incidente. Com que frequência o roteador da sua casa recebe atualizações? Você sabe? Ninguém contabilizou isso e, até agora, não há uma resposta clara.
Dennis Jackson, da Mozilla, publicou uma página de teste que permite verificar se o seu cliente ainda confia nesses certificados. Leva algumas dezenas de segundos. Vá lá e confira.
O que resta é o que vale a pena pensar. Todo o sistema HTTPS é, na verdade, baseado numa lista: eu lhe dou uma lista de empresas em que confio, e não confio nas que estão fora dela. Quando algo dá errado, a medida mais forte possível é riscar um nome. Dá para riscá-lo. A lista está nas mãos dos navegadores, não da empresa onde ocorreu o problema.
O sistema on-chain funciona ao contrário. No Bitcoin, não existe uma empresa que assine algo e faça todos aceitarem. Cada nó verifica por conta própria todo o histórico, começando pela primeira transação. Lento. Pouco prático. Consome energia. Mas, se algo der errado, não é preciso esperar que quatro navegadores publiquem listas separadamente. O custo também é real: na blockchain, simplesmente não existe revogação. Se algo for registrado por engano, fica para sempre no livro-razão.
As assinaturas múltiplas de uma ponte entre blockchains, os preços fornecidos por um oráculo e as provas de reservas de uma stablecoin fazem exatamente o mesmo que uma CA intermediária. Alguém assina em cima, e quem está abaixo confia. Se der problema, a situação não vai ser muito diferente desta.
A diferença está em saber se é possível recalcular tudo depois. Na cadeia de certificados, você só pode esperar pela atualização da lista. Na cadeia do livro-razão, você pode verificar cada transação novamente.
Na prática, há duas coisas a fazer. Revise os serviços que ficam sempre ligados e veja se algum ainda depende de um certificado antigo. Depois, confira a lista de endereços autorizados para saques na sua carteira e na corretora: os signatários dessas três assinaturas múltiplas estão sendo gerenciados pelo mesmo escritório, pela mesma nuvem ou pelo mesmo número de telefone? Se duas dessas três coisas coincidirem, o nível de segurança restante é o de apenas uma.
$BTC $ETH $LINK
#比特币 #以太坊 #网络安全 #cadeiadecertificados
Na sexta-feira passada, às 20h06, um pesquisador chamado Wayne informou o ocorrido ao Firefox e ao Chrome. Às 21h48 daquela noite, a equipe da Mozilla já tinha calculado as oito chaves por conta própria. Nem perguntou que método a outra parte tinha usado. Às 22h59, a lista de bloqueio já tinha sido distribuída para o Firefox, que a aplica por padrão. Menos de três horas.
Essas chaves deveriam ser chaves privadas da curva P-384, cujo espaço de busca normalmente equivale a um número decimal de 116 dígitos.
Os valores medidos foram 4, 56 e 115; o maior chegou a apenas 237. Todos abaixo de 256. O pesquisador Scott Helme disse que extraiu as oito chaves dos certificados públicos em menos de um segundo. Extraiu. Foi rápido assim.
Muita gente acha que um problema com certificados significa que houve uma invasão. Não foi o caso desta vez. Na verdade, ninguém entrou no centro de dados, nenhum dado foi perdido e todos os controles físicos e lógicos permaneceram intactos. Foi o que a eMudhra escreveu no comunicado à Bolsa de Valores de Bombaim e à Bolsa Nacional da Índia. Então, como essa chave ficou fraca? Um erro no script de geração. Na cerimônia de geração de chaves de 30 de abril do ano passado — uma cerimônia conduzida sem pular nenhuma etapa, usando módulos de hardware de nível 3 segundo a norma FIPS 140-2 —, a etapa de wrap e unwrap gerou um conjunto extra de chaves fracas. Por azar, os rótulos eram parecidos. Depois, ao preparar a solicitação de assinatura, escolheram o conjunto errado e enviaram o fraco.
Depois de passar por auditorias por dois anos, em meados de 2025, a empresa entrou na lista de confiança dos navegadores. E, durante dezoito meses, ninguém percebeu. As auditorias verificavam se o processo tinha seguido a documentação, não se a chave tinha aleatoriedade suficiente.
O problema também está na estrutura da cadeia de confiança. Os certificados assinados por uma CA intermediária são aceitos por todos os sistemas abaixo dela. Das oito chaves intermediárias, seis eram usadas para TLS e duas para assinatura de código. Yash Kadakia, da Security Brigade, estima que cerca de trinta mil certificados legítimos ainda em uso precisarão ser migrados. Ele também diz que, na cadeia de confiança da internet global, um erro de uma empresa pode arrastar para o problema organizações que nunca tiveram contato com ela.
Vale observar a velocidade de reação dos quatro navegadores. Chrome e Firefox bloquearam os certificados no dia 17. A Apple, no dia 19. A Microsoft, no dia 20. A Cloudflare recebeu o aviso no dia 19 e publicou um relatório no dia 20. O Google bloqueou o hash da chave pública, então também foram bloqueados os certificados cross-signed feitos com a mesma chave. Nem foi preciso reiniciar. Essa parte foi resolvida de forma eficiente.
O que realmente ficou de fora foi tudo o que não é navegador. Serviços escritos em Go, programas Python que usam certifi, webpki-roots do Rust, uma série de aplicativos Android com seus próprios repositórios de certificados incluídos, sistemas Java antigos em centros de dados, gateways corporativos, câmeras, roteadores: as listas de confiança deles não são as mesmas do Chrome. Enquanto os navegadores resolveram o problema em três horas, esses componentes precisam esperar pela atualização da própria versão. A rapidez da correção depende da frequência com que cada componente é atualizado, não tanto da gravidade do incidente. Com que frequência o roteador da sua casa recebe atualizações? Você sabe? Ninguém contabilizou isso e, até agora, não há uma resposta clara.
Dennis Jackson, da Mozilla, publicou uma página de teste que permite verificar se o seu cliente ainda confia nesses certificados. Leva algumas dezenas de segundos. Vá lá e confira.
O que resta é o que vale a pena pensar. Todo o sistema HTTPS é, na verdade, baseado numa lista: eu lhe dou uma lista de empresas em que confio, e não confio nas que estão fora dela. Quando algo dá errado, a medida mais forte possível é riscar um nome. Dá para riscá-lo. A lista está nas mãos dos navegadores, não da empresa onde ocorreu o problema.
O sistema on-chain funciona ao contrário. No Bitcoin, não existe uma empresa que assine algo e faça todos aceitarem. Cada nó verifica por conta própria todo o histórico, começando pela primeira transação. Lento. Pouco prático. Consome energia. Mas, se algo der errado, não é preciso esperar que quatro navegadores publiquem listas separadamente. O custo também é real: na blockchain, simplesmente não existe revogação. Se algo for registrado por engano, fica para sempre no livro-razão.
As assinaturas múltiplas de uma ponte entre blockchains, os preços fornecidos por um oráculo e as provas de reservas de uma stablecoin fazem exatamente o mesmo que uma CA intermediária. Alguém assina em cima, e quem está abaixo confia. Se der problema, a situação não vai ser muito diferente desta.
A diferença está em saber se é possível recalcular tudo depois. Na cadeia de certificados, você só pode esperar pela atualização da lista. Na cadeia do livro-razão, você pode verificar cada transação novamente.
Na prática, há duas coisas a fazer. Revise os serviços que ficam sempre ligados e veja se algum ainda depende de um certificado antigo. Depois, confira a lista de endereços autorizados para saques na sua carteira e na corretora: os signatários dessas três assinaturas múltiplas estão sendo gerenciados pelo mesmo escritório, pela mesma nuvem ou pelo mesmo número de telefone? Se duas dessas três coisas coincidirem, o nível de segurança restante é o de apenas uma.
$BTC $ETH $LINK
#比特币 #以太坊 #网络安全 #cadeiadecertificados