TLS: ¿podrían la sesión reanudada y la sesión original en la misma conexión?

1

En tls 1.2, sabemos que cada conexión está asociada con una sesión, y la reanudación de la sesión se puede usar para establecer una nueva conexión rápidamente utilizando el ID de sesión de la sesión original de una conexión antigua. Además, la sesión reanudada No es una nueva sesión.    Sin embargo, si es cierto que solo hay una sesión en una conexión, el motivo por el cual TLS puede renegociar dentro de una conexión existente para crear una nueva sesión, y podemos usar la reanudación de la sesión para actualizar las claves en una conexión existente ya que la sesión reanudada no es una nueva. ¿sesión?

    
pregunta xinyu 08.06.2015 - 14:54
fuente

1 respuesta

0

No hay ningún problema en tener varias sesiones en una sola conexión, por supuesto que no simultáneamente, pero si dentro de una conexión se realiza un nuevo saludo (una "renegociación"), ese nuevo saludo puede reanudar una sesión existente , incluido el que estaba activo antes de ese nuevo apretón de manos. Al igual que con cualquier reanudación de sesión, esto solo funciona si tanto el cliente como el servidor están de acuerdo, y recuerdan los parámetros de la sesión de alguna manera (si tickets de sesión se utilizan, la memoria del servidor puede estar realmente descargada en el cliente).

Sin embargo, esto plantea la pregunta de por qué renegociaría, si es solo para mantener la sesión actual en ejecución. Un caso común de renegociación es cuando IIS (servidor web de Microsoft) está configurado para usar la autenticación de cliente basada en certificados. IIS, de forma predeterminada, utiliza certificados de cliente por directorio, no para todo el servidor; así, las cosas van normalmente de la siguiente manera:

  • El cliente se conecta al servidor. Se realiza un saludo "normal", sin solicitud de un certificado de cliente.
  • Una vez que se realiza el protocolo de enlace, el cliente envía la solicitud HTTP. En ese punto , el servidor aprende la ruta de destino exacta para la solicitud (hasta ese momento, el servidor conocía, en el mejor de los casos, el servidor deseado nombre , a través de extensión SNI , pero no la ruta completa).
  • Si la ruta de destino está configurada para usar certificados de cliente, entonces el servidor amortigua la solicitud e inicia un nuevo protocolo de enlace ( HelloRequest y así sucesivamente).
  • El cliente responde con un ClientHello y normalmente intenta reanudar la sesión en curso. Sin embargo, el servidor se niega, y en su lugar inicia una nueva sesión. Esto es así porque el punto principal (en esa situación) de comenzar un nuevo saludo es solicitar un certificado de cliente, y esto solo puede ocurrir con un saludo completo, es decir, con una nueva sesión.
  • Una vez que se completa el nuevo protocolo de enlace y se autentica el cliente, se procesa la solicitud almacenada en búfer (esto es seguro siempre y cuando el cliente y el servidor implementen opción de renegociación segura , que fue diseñada exactamente para ese uso).

Lo que estoy señalando aquí es que el cliente realmente intenta reanudar la misma sesión, según lo permiten los estándares, y el servidor rechaza la reanudación porque provocó un nuevo protocolo de enlace precisamente para que se pueda abrir una nueva sesión. En la práctica, las personas que sienten que deben "renovar las llaves" por alguna razón mal justificada pueden realizar un nuevo apretón de manos pero reanudar la misma sesión. Estamos más en el dominio de la Tradición que de la Ciencia aquí. Conceptualmente, hacer un nuevo saludo con la misma sesión podría usarse como una forma de intercambiar algunas nuevas extensiones TLS, pero actualmente casi no hay ninguna extensión definida para lo que tenga sentido (pero las extensiones son, por definición, abiertas). así que esto puede ser útil algún día).

    
respondido por el Thomas Pornin 08.06.2015 - 16:12
fuente

Lea otras preguntas en las etiquetas