¿Por qué todos los certificados raíz de CA están firmados con SHA-1 (dado que SHA-1 está en desuso)?

67

Entiendo que los certificados SSL ya no se pueden firmar con SHA-1. Sin embargo, todos los certificados raíz de CA están firmados con SHA-1 (principalmente). ¿Significa que el mismo algoritmo en el que ya no se confía para "su abuela SSL shop" está bien para el certificado más seguro del mundo?

¿Me estoy perdiendo de algo? (¿uso de clave? ¿tamaño de clave?)

ssl ssl-certificate certificate-authority

— 131
fuente

9

No es cierto que "todos" los certificados raíz de CA sean SHA1.

— Greg Askew

55

Los certificados raíz son como suposiciones iniciales en una cosmovisión. Se necesita fe para confiar en ellos.

— Roy Tinker

@RoyTinker excepto por cogito ergo sum (ver duda radical, y su respuesta: escepticismo cartesiano )?

— Nick T

1

Cruz-pila: security.stackexchange.com/questions/120301/... y superuser.com/questions/1122069/...

— dave_thompson_085

66

@NickT: Juega seguro - cogito ergo cogito ;-)

— tonysdg

106

La firma de los certificados de CA raíz no tiene ninguna importancia, ya que no es necesario verificarlos. Todos son autofirmados.

Si confía en un certificado de CA raíz, no es necesario verificar su firma. Si no confías en él, su firma no tiene valor para ti.

Editar: hay algunos comentarios muy relevantes a continuación. No me siento cómodo copiando o reformulando y tomando crédito por ellos en lugar de sus autores. Pero doy la bienvenida a las personas para que agreguen explicaciones a esta respuesta.

— usuario2233709
fuente

3

Trae la pregunta de por qué están firmados

— Richard Tingle,

42

Porque el sistema no admite certificados que no están firmados.

— Deja de dañar a Monica el

Me parece que la preocupación con un certificado raíz descifrable no es "no sabes de dónde sacaste el certificado raíz", sino "no sabes quién más ha podido descifrar este certificado y usarlo para firmar lo que quieran ". ¿Y parece por su respuesta que los dos (certificado y firma del certificado) son preocupaciones separadas, y que el certificado en sí es adecuadamente seguro e indescifrable?

— Dewi Morgan

20

Yo iría incluso más allá de "no hay necesidad de verificarlos". El propósito de la firma en una cadena de certificados es que una autoridad superior certifique una autoridad inferior. Para una CA raíz, no existe una autoridad superior por definición (eso es lo que significa "raíz"), por lo que no hay nadie que pueda firmar el certificado . Como, como se mencionó anteriormente, los certificados deben estar firmados, las CA raíz están firmadas con una firma "ficticia", y la forma más sencilla de hacerlo es autofirmarse. Por lo tanto, no solo no hay necesidad de verificar, la idea misma de verificar la firma de una CA raíz no tiene sentido.

— Jörg W Mittag

13

@DewiMorgan No puede "descifrar" un certificado raíz con una colisión hash, porque el cliente confía en el certificado en sí , no en su (auto) firma. Tendría que recuperar la clave privada, que es un ataque a RSA, no al algoritmo hash.

— zwol

46

Al final del día, un certificado raíz está autofirmado. Nunca está firmado por otra entidad, excepto por sí mismo. El certificado raíz obtiene su confianza a través de procesos fuera de banda, como enviarlo a una lista de navegadores de editores confiables o hacer que Microsoft lo acepte para insertarlo en la lista predeterminada de editores confiables de Windows.

Estos certificados (y las compañías que los firmaron) son (supuestamente, con suerte) examinados exhaustivamente por otros medios además de sus firmas.

— Mark Henderson
fuente

2

Sin mencionar que actualizar un certificado raíz requiere volver a pasar por ese proceso fuera de banda.

— Kaithar

44

+1 para el "supuestamente, con suerte"

— Nathan Osman

6

El único caso en el que esto es importante es que si la raíz está firmada por SHA-1, SHA-1 puede revocarla. Es decir, alguien que pueda atacar SHA-1 puede construir una revocación para la raíz. Y estoy absolutamente seguro de que el navegador no sabe cómo persistir, por lo que el vandalismo no ha logrado más que soltar las conexiones SSL. Que vergonzoso.

— joshudson
fuente

1

Este es un pensamiento interesante, pero dudo que funcione de esta manera. Supongo que cada agente tendría su propio comportamiento único, pero dudo que los desarrolladores tengan la idea de que la lista de revocación se utilizará para administrar la revocación de los certificados raíz. Por lo menos, si esto funcionó en algunos casos, sería debido a la abstracción de la revocación del software y no intencionalmente por los desarrolladores.

— Peter Oehlert

1

Como nota al respecto, ALGUNAS CA ya han estado actualizando sus certificados raíz e intermedios a SHA256 de todos modos.

Sé que el año pasado GlobalSign estaba actualizando sus certificados a medida que estábamos actualizando nuestros certificados de firma de código, por lo que también tuve que agregar su nueva cadena.

Puede verificar qué certificados específicos se actualizaron y cuáles actualizaron, pero también dejaron un certificado SHA1 heredado aquí => 1

Espero que ayude.

— B.Kaatz
fuente

0

Para la CA raíz, confía en la clave pública de la CA incluida en el CRT, independientemente de su firma propia.

La descripción de CA utilizando el formato de archivo .CRT en lugar de una clave pública sin formato .PEM permite agrupar más detalles en ella, por ejemplo, el nombre de CA (una vez más, la firma no vale nada)

— 131
fuente

-1

Hay certificados raíz SHA1 anclados muy antiguos, en su mayoría de 2006 o anteriores , que los navegadores aceptan, pero no los certificados más nuevos. ¿Recuerdas cuando Firefox y Chrome se versionaron con un solo dígito?

Los certificados fallan si la CA raíz usa los certificados SHA1 con Not Before establecido en algo después de 2014. Las restricciones de fecha reales dependen del navegador u otra aplicación. El foro de WebCA dejó esto en claro hace varios años. Pruebe esto usted mismo por:

Cree una infraestructura de entidad de certificación raíz privada firmada con un SHA1, llámela rootSHA1
Haga que rootSHA1 cree una CA "emisora" o una CA "intermedia" que emita certificados con un certificado encadenado a la raíz. Llámelo intermedio SHA256.
Haga que la CA emisora intermediaria SHA256 genere certificados firmados con un hash sha256 o superior. Llámelo webServerSHA256.
Instale webServerSHA256 en webServerSHA56.mydomain.com.
Instale los certificados rootSHA1, intermedioSHA256 y webServerSHA256 en las ubicaciones apropiadas en Google Chrome. Instale la raíz en las Autoridades de certificación raíz de confianza y las demás con una cadena de certificados.
Navegue Google Chrome a https://webServerSHA256.mydomain.com/ y verifique que no haya un candado verde para webServerSHA256. La prueba falla.

— rjt
fuente

Esto está bastante mal. Los certificados intermedios (y los certificados de EE. UU. / Hoja) requieren SHA2, pero las raíces no. Los propios certificados de Google se encadenan a través de su CA privada (Google Internet Authority G3) a GlobalSign Root CA R2, que es SHA1, y (no es de extrañar) son aceptados por Chrome.

— dave_thompson_085

Sí, se aceptan los certificados SHA1 anclados, pero no se aceptan nuevos certificados raíz SHA1, incluso si los agrega a su propio almacén de certificados de Trusted Root. Agregué un caso de prueba a mi respuesta.

— Rjt