Por que os certificados raiz da CA são todos assinados pelo SHA-1 (desde que o SHA-1 foi descontinuado)?

67

Entendo que certificados SSL não podem mais ser assinados usando SHA-1. No entanto, todos os certificados raiz da CA são assinados por SHA-1 (principalmente). Isso significa que o mesmo algoritmo que não é mais confiável para "sua loja SSL da vovó" é bom para o certificado mais seguro do mundo?

Estou esquecendo de algo? (uso da chave? tamanho da chave?)

ssl ssl-certificate certificate-authority

— 131
fonte

9

Não é verdade que "todos" os certificados raiz da CA sejam SHA1.

— Greg Askew

5

Os certificados raiz são como iniciar suposições em uma visão de mundo. É preciso fé para confiar neles.

— Roy Tinker

@RoyTinker, exceto cogito ergo sum (veja a dúvida radical e a resposta: ceticismo cartesiano )?

— Nick T

11

Cruz-stack: security.stackexchange.com/questions/120301/... e superuser.com/questions/1122069/...

— dave_thompson_085

6

@NickT: Play it safe - cogito ergo cogito ;-)

— tonysdg

106

A assinatura dos certificados de CA raiz não importa, pois não há necessidade de verificá-los. Todos são autoassinados.

Se você confia em um certificado de CA raiz, não há necessidade de verificar sua assinatura. Se você não confia, sua assinatura é inútil para você.

Editar: existem alguns comentários muito relevantes abaixo. Não me sinto à vontade para copiá-las ou reformulá-las e receber crédito por elas em vez de por seus autores. Mas saúdo as pessoas a acrescentar explicações a esta resposta.

— user2233709
fonte

3

Traz a questão de por que eles são assinados em tudo

— Richard Tingle

42

Porque o sistema não suporta certificados que não são assinados.

— parar de prejudicar Monica

Parece-me que a preocupação com um certificado raiz quebrável não é "você não sabe de onde obteve o certificado raiz", mas sim "você não sabe quem mais conseguiu quebrar esse certificado e usá-lo para assinar o que quiserem ". E parece da sua resposta que os dois (cert e assinatura de certificado) são preocupações separadas e que o certificado em si é adequadamente seguro e intransponível?

— Dewi Morgan

20

Eu iria ainda mais longe do que "não há necessidade de verificá-los". O objetivo da assinatura em uma cadeia de certificados é que uma autoridade superior ateste uma autoridade inferior. Para uma autoridade de certificação raiz, não há autoridade superior por definição (é isso que "raiz" significa)); portanto, não há ninguém que possa assinar o certificado . Como, como foi mencionado, os certificados devem ser assinados, as CAs raiz são assinadas com uma assinatura "fictícia" e a maneira mais simples de fazer isso é assinar automaticamente. Portanto, não é apenas necessário verificar, a própria idéia de verificar a assinatura de uma autoridade de certificação raiz não faz sentido.

— Jörg W Mittag

13

@DewiMorgan Você não pode "quebrar" um certificado raiz com uma colisão de hash, porque o cliente confia no próprio certificado , não na sua (auto) assinatura. Você precisaria recuperar a chave privada, que é um ataque ao RSA, não ao algoritmo de hash.

— Zwol 15/03

46

No final do dia, um certificado raiz é autoassinado. Nunca é assinado por outra entidade, exceto ela própria. O certificado raiz obtém sua confiança por meio de processos fora de banda, como enviá-lo para uma lista de navegadores de editores confiáveis ou aceitá-lo pela Microsoft para inserção na lista padrão de editores confiáveis do Windows.

Esses certificados (e as empresas que os auto-assinaram) são (supostamente, esperançosamente) minuciosamente examinados por outros meios além das assinaturas.

— Mark Henderson
fonte

2

Sem mencionar, a atualização de um certificado raiz requer passar por esse processo fora de banda novamente.

— 21417 Kaithar

4

+1 para o "supostamente, espero"

— Nathan Osman

6

O único caso em que isso importa é que, se a raiz for assinada pelo SHA-1, ela poderá ser revogada pelo SHA-1. Ou seja, alguém que pode atacar o SHA-1 pode construir uma revogação para a raiz. E tenho certeza absoluta de que o navegador não sabe como persistir com isso, para que o vândalo não tenha realizado mais do que eliminar conexões SSL. Que coxo.

— Joshudson
fonte

11

Esse é um pensamento interessante, mas duvido que isso funcione dessa maneira. Meu palpite é que cada agente teria seu próprio comportamento único, mas duvido que qualquer desenvolvedor tenha a idéia de que a lista de revogação seria usada para gerenciar a revogação de certificados raiz. No mínimo, se isso funcionasse em alguns casos, seria devido à abstração da revogação do software e não intencionalmente pelos desenvolvedores.

— 22416 Peter Oehlert

1

Como observação, algumas CAs já estão atualizando seus certificados raiz e intermediários para o SHA256 de qualquer maneira.

Sei que no ano passado a GlobalSign estava atualizando seus certificados, assim como estávamos atualizando nossos certificados de assinatura de código, então tive que adicionar sua nova cadeia a eles também.

Você pode verificar quais certificados específicos foram atualizados e quais eles foram atualizados, mas também deixaram um certificado SHA1 herdado para aqui => 1

Espero que ajude.

— B.Kaatz
fonte

0

Para a CA raiz, você confia na chave pública da CA - agrupada no CRT - independentemente de sua autoassinatura.

Descrevendo a CA usando o formato de arquivo .CRT em vez de uma chave pública bruta. O PEM permite agrupar mais detalhes nela - por exemplo, nome da CA - (mais uma vez, a assinatura é inútil)

— 131
fonte

-1

Já existem certificados raiz SHA1 fixados muito antigos, principalmente na era de 2006 ou anterior, que os navegadores aceitam, mas nenhum certificado mais recente. Lembra quando o Firefox e o Chrome foram versionados usando um dígito?

Os certificados falham se a CA raiz usar certificados SHA1 com o Not Before definido para algo após 2014. As restrições de data reais dependem do navegador ou de outro aplicativo. O cabforum da WebCA deixou isso claro há vários anos. Teste você mesmo:

Crie uma infraestrutura de Autoridade de Certificação raiz privada assinada com um SHA1, chame-o de rootSHA1
Faça com que o rootSHA1 crie uma autoridade de certificação "emissora" ou "intermediária" que emita certificados com um certificado acorrentado à raiz. Chame de intermediárioSHA256.
Faça com que a CA intermediária do SHA256 gere certificados assinados com um hash sha256 ou superior. Chame isso de webServerSHA256.
Instale o webServerSHA256 no webServerSHA56.mydomain.com.
Instale os certificados rootSHA1, intermediárioSHA256 e webServerSHA256 nos locais apropriados no Google Chrome. Instale a raiz nas autoridades de certificação raiz confiáveis e nas demais com uma cadeia de certificados.
Navegue no Google Chrome para https://webServerSHA256.mydomain.com/ e verifique se não há um cadeado verde para webServerSHA256. O teste falha.

— rjt
fonte

Isto está completamente errado. Certos intermediários (e EE./cartões de folhas) requerem SHA2, mas as raízes não. As próprias cadeias de empresas do Google, por meio de sua CA privada (Google Internet Authority G3), para o GlobalSign Root CA R2 - que é SHA1 - e (sem surpresa) são aceitas pelo Chrome.

— dave_thompson_085 8/07

Sim, esses certificados SHA1 fixados são aceitos, mas nenhum certificado raiz SHA1 novo, mesmo que você o adicione ao seu próprio armazenamento de certificados Raiz Confiável. Adicionado um caso de teste à minha resposta.

— rjt 11/07