He escuchado que con secreto hacia adelante que los cifrados ECDSA generan claves diferentes para "cada sesión" porque no dependen de la clave privada del servidor. Mi pregunta es ¿cómo se define "cada sesión"? ¿Este enfoque clave diferente significa que ocurre con cada conexión SSL consecutiva / diferente para decir el mismo servidor o ocurre dentro de la conexión SSL existente cuando ocurre una solicitud de renegociación de SSL del lado del servidor?
Cada sesión significa cada sesión SSL. Una sesión SSL puede reutilizarse a través de múltiples conexiones TCP (es decir, conexiones SSL) si tanto el cliente como el servidor implementan la reutilización de la sesión y cada una de las conexiones SSL se cierra de manera limpia.
Una conexión SSL también puede constar de varias sesiones SSL si realiza varias gestiones de SSL completas dentro de la misma conexión.
La clave utilizada para proteger la transmisión de datos no debe utilizarse para obtener claves adicionales, y si la clave utilizada para proteger la transmisión de datos se deriva de algún otro material de claves, no se debe utilizar ese material para derivar más. llaves. De esta manera, el compromiso de una clave única permite el acceso solo a los datos protegidos por esa clave única.
PFS es válido arriba, pero satisface las dos propiedades a continuación:
¿Cómo se define "cada sesión"?
Ephemeral Diffie Hellman se usa para PFS . El uso de Ephemeral Diffie Hellman (DHE / ECDHE) obliga a cada sesión a renegociar su parámetro DH cada vez que se cierra una sola sesión SSL. Así que "cada sesión" significa literalmente, tan pronto como la sesión termina, las claves se destruyen. El servidor no almacena ninguna ID de sesión, por lo que se forzan nuevas claves cada vez.
¿Este enfoque clave diferente significa que sucede con cada Conexión SSL consecutiva / diferente para decir el mismo servidor o lo hace suceda dentro de la conexión SSL existente como servidor SSL solicitud de renegociación sucede?
No importa si es el mismo servidor o si se trata de una nueva negociación en el servidor, el servidor no debería tener claves de sesión almacenadas en caché. Por lo tanto, se necesitan nuevos parámetros DH con las suites de cifrado * DHE. Ahora así es como funciona la teoría. La configuración es una especie de historia diferente. Es posible que algunos servidores tengan que deshabilitar la reanudación de la sesión para garantizar que esto ocurra.
Las implementaciones DEBEN generar una nueva X para cada saludo cuando se usa Conjuntos de cifrado DHE.
Lea otras preguntas en las etiquetas public-key-infrastructure cryptography encryption tls certificates