Respuesta corta: puede ser , pero es complicada y depende del tipo de certificado que tenga el servidor y de los conjuntos de cifrado TLS que está configurado para usar.

Esta respuesta es básicamente una copia de esta página wiki de openssl . Veamos algunos ejemplos.

RSA puro

Para estos, el certificado del servidor contendrá una clave RSA y usted usará una suite de cifrado como

  

TLS_RSA_WITH _....

La clave de sesión se generará en el lado del cliente y se enviará al servidor cifrado con la clave RSA del servidor. Para la parte de autenticación del protocolo de enlace, el servidor usará la misma clave RSA para producir una firma (creo).

DH estático - anónimo

Para estos, el servidor utiliza las mismas claves DH para cada conexión, sin embargo, no hay certificado, por lo que el cliente no puede verificar que esta clave pertenece realmente al servidor y no a un administrador. . Utilizará una suite de cifrado como

  

TLS_DH_anon_WITH _....

Nota: claramente esto es inseguro.

DH estático - con certificado

Para estos, el servidor usa las mismas claves DH para cada conexión y la clave pública se colocará en el certificado del servidor (un certificado DH en lugar del certificado RSA más común). Utilizará una suite de cifrado como

  

TLS_DH_RSA_WITH _...

Como se señala aquí , el algoritmo de firma (RSA / DSS) indica qué algoritmo de firma usó la AC para firmar el certificado y no hay firma como parte del apretón de manos; Si el servidor llega a la misma clave de sesión, debe tener la clave privada DH correspondiente.

Nota: esto es antiguo y está en desuso, la gente prefiere DHE ahora.

DHE + RSA efímero

Para estos, el certificado del servidor contendrá una clave RSA y usted usará una suite de cifrado como

  

TLS_DHE_RSA_WITH _...

Dado que el DH es efímero, se generará una nueva clave DH para cada nueva conexión, por lo que no es necesario colocarlo en un certificado. La clave RSA se usa para firmar una respuesta de desafío para demostrar que el servidor es quien dice ser. Estos son los cifrados preferidos en estos días.

CloudFlare explica que Diffie-Hellman y RSA, ambos utilizados en mecanismos de intercambio de claves, tienen ventajas. Keyless SSL: los detalles técnicos de Nitty Gritty .

  

Los apretones de manos RSA y DH tienen sus ventajas y desventajas. El protocolo de enlace RSA solo utiliza una operación de algoritmo de clave pública, RSA. Un handshake DH con un certificado RSA requiere la misma operación RSA, pero con una operación DH adicional. Dado que el certificado es RSA, el protocolo de enlace RSA es más rápido de calcular. Los algoritmos de clave pública como RSA y DH usan una gran cantidad de CPU y son la parte más lenta del protocolo de enlace TLS. Una computadora portátil solo puede realizar un par de cientos de encriptaciones RSA por segundo frente a unos diez millones por segundo del cifrado simétrico AES.

     

El protocolo de enlace de DH requiere dos algoritmos para ejecutarse, pero la ventaja que ofrece es que permite que el establecimiento de claves se realice independientemente de la clave privada del servidor. Esto da a la conexión el secreto hacia adelante, una propiedad útil que evita que las conversaciones se descifren después de que la clave privada esté expuesta de alguna manera. La versión DH del protocolo de enlace también abre la posibilidad de utilizar certificados no RSA que pueden mejorar el rendimiento, incluidas las claves ECDSA. Las curvas elípticas proporcionan la misma seguridad con menos sobrecarga computacional. Un acuerdo de DH con un certificado DSA de curva elíptica y una curva elíptica. El acuerdo de clave Diffie-Hellman puede ser más rápido que un saludo de RSA de una sola operación.

Creo que Diffie-Hellman y su uso de TLS / SSL explicará con más detalle.

Suponiendo que la "clave pública del servidor" se usa para la autenticación, entonces no. La clave pública DH y la clave pública del servidor son no las mismas. Sin embargo, he visto opiniones muy variadas sobre este asunto. TLS 1.2 parece utilizar DH y RSA para el mecanismo de intercambio de claves. DH se utiliza para producir la clave simétrica para un algoritmo simétrico. DH en sí mismo no es necesariamente un algoritmo de cifrado de datos, sino una forma de acordar una clave secreta a través de una red pública.