Há três dias, uma
mensagem de violação em massa
foi gerada na lista de correspondência mozilla.dev.security.policy na geração de certificados TLS. A investigação mostrou que várias autoridades de certificação foram afetadas, incluindo
GoDaddy ,
Apple e
Google . O número total de certificados incorretos excede 1 milhão e talvez muito mais. O GoDaddy
nomeou inicialmente
a figura de 1,8 milhão de certificados e reduziu a classificação em duas ordens de grandeza para 12.000. Um porta-voz da Apple nomeou a figura de
558.000 certificados .
A conclusão é que todas as lesões na CA usaram a solução PKI de código aberto
EJBCA com configurações incorretas, como resultado dos quais números aleatórios do espaço de 63 bits foram usados para números de série do certificado, o que viola
os requisitos mínimos de entropia do
Fórum CA / B (64 bits).
A diferença entre 2
63 e 2
64 excede 9 quintilhões, ou seja, 9 × 10
18 , este é um número muito significativo (embora a diferença seja apenas metade). Todos os certificados devem ser revogados. Para SSL.com e GoDaddy, o procedimento levará 30 dias; para outros, pode demorar aproximadamente o mesmo tempo, embora sejam exigidos pelo padrão RFC5280 para revogar certificados inválidos em cinco dias. Mas eles obviamente não têm tempo para cumprir a norma.
Como isso aconteceu?
Uma análise preliminar mostrou que, para todos os certificados, o comprimento do campo correspondente é exatamente de 64 bits: nem mais nem menos. Se o RNG produz 64 bits de entropia e todos os certificados são exatamente 64 bits, então, à primeira vista, tudo está bem. Mas o problema é que, de acordo com a
RFC5280 :
Número de série
O número de série deve ser um número inteiro positivo atribuído pela CA a cada certificado. Ele deve ser exclusivo para cada certificado emitido por uma CA específica (por exemplo, o nome do editor e o número de série identificam um certificado exclusivo).
As autoridades de certificação devem controlar estritamente o procedimento de emissão do CERT, para que o número de série nunca seja um número inteiro negativo. Os requisitos de exclusividade apresentados acima sugerem que números consecutivos podem ser inteiros longos. Os usuários do CERT devem poder processar um valor no subcampo serialNumber com um comprimento de até 20 octetos (inclusive). As autoridades de certificação que seguem este padrão não devem usar valores no subcampo serialNumber com mais de 20 octetos.
A exigência de um número positivo significa que o bit mais significativo não pode ser definido. Se estiver instalado, não poderá ser usado diretamente como o número de série do certificado.
O popular sistema EJBCA PKI, que é usado por muitas CAs, por padrão gera números de 64 bits e, para números de certificado, simplesmente redefine o bit mais significativo. Na verdade, o RNG deles produz números de 63 bits, e é por isso que muitas autoridades de certificação sofreram.
O requisito padrão de 64 bits para o RNG foi formulado não do zero, mas após o
hack de 2008 , quando um cluster de 200 consoles de jogos PlayStation 3 gerou colisões para o hash MD5, o que
permite criar um centro de autenticação falso no qual todos os navegadores e sistemas operacionais confiarão .
Em 2012,
a arma cibernética americana Flame usou esse truque para se infiltrar no mecanismo de atualização do Windows Update.
No entanto, agora que o SHA256 é usado para geração, é um algoritmo mais moderno comparado ao MD5, portanto o requisito mínimo de 64 bits é adotado mais para fins preventivos. Especialistas
dizem que agora não há chance de encontrar colisões em 63 bits e de alguma forma explorar o erro encontrado com certificados incorretos.
Mas revogar milhões de certificados é uma dor de cabeça para administradores de sistema de muitas empresas.
A perda de 1 bit de entropia não é tão terrível, mas alguém em algum lugar pode encontrar uma vulnerabilidade que rouba outros 1-2 bits e assim por diante. Portanto, todas essas vulnerabilidades devem ser corrigidas imediatamente.
