protocolo TLS, clave de sesión para una conexión segura

2

En Wikipedia, como parte del intercambio de información entre un cliente y un servidor, el servidor envía una clave de cifrado pública como parte del certificado digital. Luego, el cliente utiliza el intercambio de claves Diffie-Hellman para generar de forma segura una clave de sesión única y aleatoria para el cifrado y descifrado. Preguntas:

  1. ¿la clave pública enviada por el servidor está encriptada o sin cifrar? Supongo que está claro, ya que es público
  2. ¿Cómo se relacionan la clave de sesión y la clave pública? ¿El cliente envía clave de sesión al servidor? clave de sesión enviada: f (Random_gen_number, Public_key) donde f es una función de cifrado?
pregunta joseph cesana 04.06.2018 - 00:15
fuente

2 respuestas

2
  

¿la clave pública enviada por el servidor está encriptada o sin cifrar? Supongo que está claro ya que es público

La clave pública del servidor se encuentra en claro en el certificado del servidor que se envía en claro por el servidor, lo que significa que la clave pública también se envía de forma implícita en claro. Tenga en cuenta que este solo es el caso con la autenticación de servidor basada en certificados, que es la forma más común de autenticar el servidor en TLS, pero no la única. Otras formas de autenticar el servidor son, por ejemplo, las claves previamente compartidas (PSK) en las que no intervienen claves públicas.

  

¿Cómo se relacionan la clave de sesión y la clave pública?

El resultado del intercambio de claves es un secreto maestro previo que luego se usa para derivar un secreto maestro que luego se usa para derivar las claves de sesión, es decir, las claves para cifrar y proteger (HMAC) los datos de la aplicación.

Si se utiliza el intercambio de claves Diffie-Hellman como usted indica, no existe ninguna relación entre la clave pública y el secreto maestro previo y, por lo tanto, no entre la clave pública y las claves de sesión. El único uso del certificado en este caso es autenticar el servidor y no desempeña ningún papel en el intercambio de claves. El intercambio de claves Diffie-Hellman también se puede usar para los protocolos de enlace TLS donde no hay ninguna clave pública involucrada, por ejemplo con la autenticación PSK.

  

¿El cliente envía la clave de sesión al servidor? clave de sesión enviada: f (Random_gen_number, Public_key) donde f es una función de cifrado?

Con el intercambio de claves Diffie-Hellman no hay nada que se parezca a esto. Con el intercambio de claves RSA, el cliente en su lugar crea el secreto maestro previo completamente en el lado del cliente (es decir, no es el resultado de un intercambio de claves en el que ambas partes están involucradas, como en el intercambio de claves DH) y lo envía al servidor cifrado con el Clave pública del servidor. El servidor luego desencripta esto con su clave privada (secreta) y por lo tanto puede extraer el secreto pre-maestro. El proceso de derivar el secreto principal y las claves de sesión de este es el mismo que con el intercambio de claves DH.

Este proceso de envío del secreto maestro previo al servidor también significa que el conocimiento de la clave privada del servidor permite recuperar el secreto maestro previo, derivar las claves de sesión y descifrar todo el tráfico. Esto es cierto incluso para el tráfico más antiguo si el tráfico se capturó en algún momento y el atacante o servicio secreto tuvo acceso a la clave privada solo más tarde. Contrariamente a esto, con el intercambio de claves DH no se produce un intercambio real del secreto pre-maestro, sino que se deriva de ambos lados. Tener acceso a la clave privada del servidor no permitirá que un atacante descifre el tráfico detectado, es decir, se necesita un ataque activo y en tiempo real de hombre en el medio. Es por eso que el intercambio de claves DH es el preferido hoy en día y el único soporte que comienza con TLS 1.3.

    
respondido por el Steffen Ullrich 04.06.2018 - 07:18
fuente
0
  1. La clave pública se envía en claro. No se puede cifrar porque el cliente y el servidor aún no han podido establecer un secreto compartido. El secreto compartido se generará como resultado del intercambio de claves. Lea más sobre Diffie Hellman Key Exchange en Wikipedia

  2. El intercambio de claves Diffie-Hellman resultará en un secreto compartido. Esto se utiliza para establecer el secreto maestro. El secreto principal se utiliza para generar claves de cifrado para la sesión. Lea más sobre el master master y las claves de cifrado en RFC 5246.

(P.S. La clave pública no tiene que estar en el certificado, Ephemeral Diffie-Hellman envía la clave en un mensaje de intercambio de clave).

    
respondido por el ztk 04.06.2018 - 04:55
fuente

Lea otras preguntas en las etiquetas