¿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.