X509 / certificados SSL en la práctica

Question

X509 / certificados SSL en la práctica

#1 de Maarten Bodewes (1 votos)

0

Después de aprender la teoría detrás de la criptografía, tengo algunos problemas para entender cómo funcionan los certificados SSL o X509 en la práctica y simplemente no puedo encontrar información útil en Internet.

A mi entender, un servidor web necesita un certificado SSL para demostrar al cliente que él es quien dice ser (por ejemplo, www.company.com). Además de eso, asumo que también se usa para intercambiar una clave de sesión temporal por cifrado simétrico (probablemente AES) por algún sistema de distribución de claves asimétricas como diffie-helmann?

En ese caso: ¿El certificado que tiene el servidor web contiene varias claves públicas para todos estos sistemas criptográficos, por ejemplo, una clave RSA para firmas RSA, los parámetros de DL para Diffie-Hellmann? ¿O necesita varias claves (también para múltiples tamaños de clave)?

Estaría muy agradecido si alguien pudiera decirme qué sucede exactamente (paso a paso), cuando un cliente se conecta a una dirección https. ¡Muchas gracias!

public-key-infrastructure cryptography tls

pregunta netik 19.05.2016 - 21:58

fuente

1 respuesta

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

¿Es seguro obtener la autorización TOKEN del servidor con javascript? ¿Usa John the Ripper para permutar casos en una contraseña?

score 1 · Answer 1

No, solo hay una clave pública en el certificado. Obviamente, el servidor también debe tener la clave privada que pertenece a la clave pública en el certificado.

La clave de sesión se recupera usando el establecimiento de clave. Básicamente hay dos formas:

el secreto maestro se genera y luego el cliente lo cifra mediante la clave pública del servidor, el servidor ahora puede descifrar el secreto maestro y derivar las claves de la sesión;
el secreto principal se deriva mediante el acuerdo de clave Diffie-Hellman, los marcos requeridos para el acuerdo de clave son firmados por el servidor mediante la clave privada y verificados por el cliente para realizar la autenticación.
en principio, el certificado también puede contener una clave Diffie-Hellman estática pero en la práctica esto no se usa (mucho); en este caso, el acuerdo clave se verifica automáticamente.

Las claves de sesión luego se derivan del secreto maestro utilizando la derivación de clave con la PRF (identificada al final del conjunto de cifrado).

Tipo 1 es utilizado por las suites de cifrado que comienzan con, por ejemplo, %código%. El tipo 2 es utilizado por conjuntos de cifrado que comienzan con RSA_ o ECDHE_ . El tipo 3 se identifica con DHE_ o ECDH_ .

En el caso de la autenticación del cliente, el cliente también debe realizar la autenticación de los marcos intercambiados.

TLS 1.3 solo permitirá el establecimiento de claves de tipo 2, ya que solo se basa en la generación de firmas para el certificado. Además, proporciona secreto de reenvío porque las claves DH efímeras (temporales) se destruyen después de que se haya realizado el establecimiento de la clave. Esto hace que sea imposible romper el establecimiento de la clave, volver a calcular las claves de la sesión y descifrar los marcos cifrados con el texto sin formato dentro de la sesión.