¿Qué es el parámetro de ID de sesión que se indica en los mensajes de saludo del cliente y servidor?

  

¿Puede ser capturado por un atacante?

Sí, pero no les sirve de mucho.

Es una referencia indirecta a los algoritmos y claves acordados previamente (y de forma segura), que son recordados por el servidor / cliente. Entonces, si el atacante le confirma a su servidor que desea reanudar la sesión, su servidor reanudará con el texto cifrado que el cliente del atacante no sabe cómo descifrar.

(Puede haber cierto alcance para escalar esto a un DOS contra un solo cliente, pero eso es una conjetura de mi parte. Y si el atacante puede detectar el tráfico, hay formas más fáciles de subvertir la conexión .)

La sesión TLS no tiene nada que ver con las sesiones HTTP, por lo que incluso si el atacante pudo descifrar los datos, esto no es suficiente para controlar la sesión de los usuarios en la aplicación.

  

El primer mecanismo de reanudación de identificadores de sesión (RFC 5246) fue   introducido en SSL 2.0, lo que permitió al servidor crear y enviar un   Identificador de sesión de 32 bytes como parte de su mensaje de ServerHello durante   La negociación TLS completa que vimos anteriormente. Con el ID de sesión en su lugar,   Tanto el cliente como el servidor pueden almacenar la sesión negociada previamente   parámetros —adaptados por ID de sesión— y reutilizarlos para una posterior   sesión.

Específicamente, el cliente puede incluir el ID de sesión en el mensaje de ClientHello para indicar al servidor que aún recuerda el conjunto de cifrado negociado y las claves del protocolo de enlace anterior y puede reutilizarlos. A su vez, si el servidor puede encontrar los parámetros de sesión asociados con la ID anunciada en su caché, entonces puede tener lugar un protocolo de intercambio abreviado. De lo contrario, se requiere una nueva negociación de sesión completa, lo que generará un nuevo ID de sesión.

Fuente: enlace