Clave pública en el protocolo SSL

El protocolo de enlace SSL no está cifrado. El servidor simplemente envía su clave pública en el plano. El cliente sabe que puede confiar en él, porque está firmado por una CA confiable totalmente . Un certificado es esencialmente una clave pública con algunos datos asociados, como un dominio, firmado por una CA.

El cliente no necesita poder descifrar el PreMasterSecret (de donde se deriva la clave de sesión), porque eligió su valor y aún lo recuerda.

Eche un vistazo a cómo funciona el protocolo SSL:

  

• fase de negociación:   
  • Un cliente envía un mensaje ClientHello ...
    
  • El servidor responde con un mensaje ServerHello ...
    
  • El servidor envía su mensaje Certificado (según el paquete de cifrado seleccionado, el servidor puede omitirlo). Esto contiene la clave pública
    
  • El servidor envía un mensaje ServerHelloDone , lo que indica que se realiza con la negociación de negociación.
    
  • El cliente responde con un mensaje ClientKeyExchange , que puede contener un PreMasterSecret, una clave pública o nada. Este PreMasterSecret se cifra mediante la clave pública del certificado del servidor.
    
  • El cliente y el servidor luego usan los números aleatorios y '' PreMasterSecret '' para calcular un secreto común, llamado "secreto maestro". Todos los demás datos clave para esta conexión se derivan de este secreto maestro (y de los valores aleatorios generados por el cliente y el servidor)
    
  
• El cliente ahora envía un registro ChangeCipherSpec , que básicamente le dice al servidor, "Todo lo que le diga a partir de ahora se cifrará y autenticará
  
• Finalmente, el cliente envía un mensaje Finalizado autenticado y encriptado, que contiene un hash y un MAC sobre los mensajes de intercambio anteriores.
  
• El servidor intentará descifrar el mensaje Finalizado del cliente y verificar el hash y MAC. Si el descifrado o la verificación falla, se considera que el protocolo de enlace ha fallado y la conexión debe ser interrumpida.
  
• Finalmente, el servidor envía una ChangeCipherSpec , que le dice al cliente, "Todo lo que te diga a partir de ahora será autenticado y cifrado
  
• El servidor envía su mensaje autenticado y cifrado '' 'Finalizado' ''.
  
• El cliente realiza el mismo descifrado y verificación.
  

(Basado en la wikipedia Capa de sockets seguros - Protocolo de enlace TLS simple )

Como puede ver, el cifrado solo se habilita después de la negociación y, por lo tanto, se completa la transferencia de la clave pública.

  

¿Pero de dónde viene esta clave pública?

La clave pública está incorporada en el certificado del servidor.

  

Mientras que la generación de certificados, ¿no estamos generando una clave privada que el servidor usa para descifrar datos?

Eso ya se genera antes de que se haga el certificado. Se crea el par de llaves, luego se escribe un certificado, se envía una solicitud de firma de certificado a una autoridad de certificación y, finalmente, se devuelve al solicitante un certificado firmado.

  

¿Cómo responde el servidor si tiene que usar una clave pública para cifrar la respuesta?

El navegador utiliza la clave pública del servidor para cifrar un valor aleatorio para usar como una clave de cifrado simétrica. Ese valor se envía al servidor. El servidor responde utilizando un cifrado simétrico.

  

¿Cómo va a descifrar el navegador la respuesta cifrada del servidor, ya que no hay una clave privada en el navegador?

Las respuestas no están relacionadas con un par de llaves público / privado. Microsoft hace un trabajo decente al describir el proceso de intercambio: enlace

La clave pública del servidor proviene de su certificado . El certificado contiene la clave pública, y el servidor lo envía al cliente como parte de los pasos iniciales del protocolo. La parte difícil es no conocer la clave pública, pero asegurarse de que esta sea la correcta (esa es toda la problemática de validación de certificados ).

Ver, por ejemplo, esta respuesta y luego that .