certificados SSL y correspondencia de conjuntos de cifrado

Question

certificados SSL y correspondencia de conjuntos de cifrado

#1 de Thomas Pornin (19 votos)

19

He estado aprendiendo sobre el protocolo SSL / TLS (de enlace ) y tengo algunas preguntas conceptuales sobre el protocolo .

El cliente y el servidor intercambian mensajes de "saludo" durante los cuales eligen la versión SSL / TLS y las suites de cifrado. Más específicamente, el cliente sugiere una lista de suites de cifrado y la el servidor elige uno (si el servidor no elige nada, el falla el apretón de manos). Ahora, ¿el servidor elige la suite de cifrado ¿Corresponde a los utilizados en el certificado?

Por ejemplo: ejecutar openssl x509 -in <server_cert>.pem -text -noout le brinda información sobre el certificado del servidor. En un certificado de muestra, veo que el algoritmo de clave pública es rsaEncryption (2048bit) y el algoritmo de firma es sha256WithRSAEncryption. ¿Esto ya no predetermina parte del conjunto de cifrado utilizado en el protocolo de enlace?
Supongamos que el servidor y el cliente acuerdan un conjunto de cifrado. Ahora, también veo que los clientes también pueden presentar un certificado más adelante en el apretón de manos. ¿Eso significa que los cifrados en el certificado del cliente deben ser compatibles con el conjunto de cifrado elegido?

(Pregunta similar, pero no responde a lo que quiero: Escogiendo conjuntos de cifrado para HTTPS )

public-key-infrastructure tls openssl

pregunta iart 29.05.2015 - 20:22

fuente

1 respuesta

Lea otras preguntas en las etiquetas public-key-infrastructure tls openssl

Posible vulnerabilidad de secuencias de comandos entre sitios, el sitio acepta pero devuelve una respuesta vacía cuando se envía una secuencia de comandos completa ¿Cómo configurar un malware de nivel de firmware para Android?

score 19 · Answer 1

Para el certificado del servidor: el conjunto de cifrado indica el tipo de intercambio de claves, que depende del tipo de clave del certificado del servidor. Básicamente tienes lo siguiente:

Para los conjuntos de cifrado TLS_RSA_ *, el intercambio de claves utiliza el cifrado de un valor aleatorio elegido por el cliente con la clave pública RSA del servidor, por lo que la clave pública del servidor debe ser del tipo RSA, y debe ser apropiada para el cifrado (la el certificado no debe incluir una extensión Key Usage que dice "solo firma").
Para las suites de cifrado TLS_DHE_RSA_ *, el intercambio de claves utiliza un Diffie-Hellman efímero, y el servidor firma su parte del intercambio de claves DH con su clave RSA. Por lo tanto, la clave pública del servidor debe ser del tipo RSA y debe ser adecuada para las firmas (nuevamente, el certificado no debe restringir el uso de la clave solo al cifrado).
Los conjuntos de cifrado TLS_DHE_DSS_ * y TLS_DHE_ECDSA_ * utilizan un intercambio de claves efímero Diffie-Hellman, y la clave del servidor debe ser del tipo, DSA y EC, respectivamente, y debe ser adecuada para las firmas.
Los conjuntos de cifrado TLS_ECDHE_ * son similares a los conjuntos de cifrado TLS_DHE_ *, excepto que el intercambio de claves Diffie-Hellman es una variante de curva elíptica. Las condiciones en el certificado del servidor siguen siendo las mismas.
Los conjuntos de cifrado TLS_DH_ * y TLS_ECDH_ * son diferentes (tenga en cuenta la falta de 'E' después de 'DH'). Para estas suites, el certificado del servidor contiene directamente una clave pública Diffie-Hellman (o una variante de curva elíptica de la misma), y la suite de cifrado luego califica el algoritmo utilizado por la CA emisora para firmar el certificado. Por ejemplo, TLS_DH_RSA_ * significa "el servidor tiene una clave pública DH almacenada en un certificado que fue firmado por alguna CA con RSA". Este es el único caso en el que el tipo de firma en el certificado tiene alguna relación con el conjunto de cifrado. Como en la práctica nadie usa ese tipo de certificado, este caso puede ser descuidado.

Para el certificado del cliente: el cliente presenta un certificado cuando el servidor lo solicita. El tipo de certificado de cliente no tiene relación alguna con el conjunto de cifrado (excepto en el caso extremadamente raro de los certificados DH estáticos, pero nunca he visto que se usen en la práctica). El certificado del cliente debe ser apropiado para las firmas. Como parte del mensaje de reconocimiento que solicita un certificado de cliente, el servidor envía información sobre los algoritmos compatibles (consulte la estándar ). De hecho, TLS 1.2 amplía aún más ese mecanismo al proporcionar una lista flexible de combinaciones de algoritmos y funciones hash compatibles.