Si una conexión cifrada puede verse comprometida cuando la clave privada de un servidor es acumulada, ¿por qué los servidores simplemente generan una nueva clave privada para cada sesión única? Parece que eliminaría un punto de vulnerabilidad si se generara según fuera necesario.
Supongo que tiene algo que ver con verificar las cadenas de autoridad, el rendimiento o algo así, pero me preguntaba si alguien sabe con seguridad por qué no se hace de esa manera.
Cuando te conectas a un servidor, hay dos tipos de cifrado en juego.
Primero, hay un par de llaves público-privado asociado con el cifrado asimétrico que se usa para validar su identidad. Por lo general (en el caso de visitar sitios web HTTPS), crea un par de claves de larga duración (una pública y otra privada), envía la parte de la clave pública y la información de identificación a una autoridad de certificación (CA) de confianza, demuestra su identidad al certificado la satisfacción de la autoridad (por ejemplo, verifique que usted controla el dominio para el que se está emitiendo el certificado) y la autoridad de certificación firma el certificado por usted. Ahora usted publica públicamente su certificado firmado por CA en su sitio web. Cualquier persona que se conecte al sitio web por primera vez, cuyo navegador / sistema operativo ya confíe en la CA que firmó su certificado, puede verificar la identidad del sitio web al que se está conectando mediante la emisión de impugnaciones al certificado firmado por la CA que solo puede responder si Controlar la clave privada de los sitios web. Tenga en cuenta que el certificado solo se utiliza para la autenticación de la identidad (al confiar en la cadena de confianza con la autoridad de certificación) al inicio de una conversación.
Para transmitir datos en realidad, no utiliza el cifrado asimétrico, ya que el cifrado asimétrico es lento y solo cifra los mensajes cortos. El cifrado simétrico es mucho más rápido y funciona bien para cifrar mensajes grandes arbitrarios rápidamente. Para la parte del cifrado simétrico, utiliza los protocolos de intercambio de claves como DHE para que ambos servidores negocien una clave simétrica compartida que se usará para cifrar y descifrar mensajes, y el protocolo de intercambio de claves puede negociar una clave simétrica aleatoria sin enviar la clave simétrica compartida a través de la red
Para un ejemplo de un protocolo de intercambio de claves que no envía la clave completa a través de la red para que Alice envíe un mensaje a Bob, primero ambos están de acuerdo en el generador de dos números ( g ) y el módulo ( N ) y cada uno elige un número aleatorio secreto a y b (Alice genera a y Bob genera b ; nota que Alice nunca aprenderá b y Bob nunca aprenderá a ). Luego Bob envía un mensaje a Alice que contiene Kb = g^b mod N . Alice calcula la clave secreta compartida K = g^(ab) mod N calculando K = Kb^a mod N . Alice usa la clave secreta K para cifrar simétricamente su mensaje y lo envía a Bob junto con Ka = g^a mod N que Bob necesitará descifrar. Si una persona que escucha la red, Eve escucha sus mensajes, ven g , N , g^a mod N , g^b mod N y el mensaje cifrado, pero no tienen una forma factible conocida de calcular K sin tener conocimiento adicional a o b . Sin embargo, este intercambio de claves aún es vulnerable a la manipulación activa, donde Alice podría intentar enviarle un mensaje a Bob, pero en cambio Eve pretende ser Bob. Esta es la razón por la que, además del secreto en el inicio de la conversación, necesita que Alice y Bob se identifiquen entre sí (lo que generalmente se hace con los certificados de larga duración firmados por las AC).
El secreto hacia adelante hace su sugerencia de no reutilizar las claves simétricas al azar, sino de renegociarlas con cada mensaje intercambiado.
Lea otras preguntas en las etiquetas key-management tls