(adecuada) forma de informar al servidor TLS para que abandone la sesión TLS con clientAuth

5

¿Hay alguna forma para que un cliente TLS informe al servidor que ya no pretende reanudar sus sesiones autenticadas?

Ejemplo:

Un cliente estableció una sesión autenticada con el servidor que proporciona su certificado con el uso de la clave clientAuth, luego realizó todo el trabajo a nivel de la aplicación y ahora desea decirle al servidor algo como:

No es necesario mantener mi sesión autenticada por más tiempo; La próxima vez que vea este ID de sesión en un cliente, hola. No reanude la sesión porque ya he terminado mi trabajo aquí

¿Hay una manera de decir eso? Por lo que veo, la alerta close_notify no significa esto, solo informa que la conexión se cerrará o que los datos no protegidos se transferirán a través de ella.

    
pregunta Trueblacker 02.09.2015 - 11:08
fuente

1 respuesta

3
  

¿Hay una manera para que un cliente TLS informe al servidor que ya no pretende reanudar sus sesiones autenticadas?

Sí, enviando una alerta con una gravedad grave.

De RFC 5077 :

  

5.1. Sesiones de invalidación

     

La especificación TLS requiere que las sesiones TLS sean invalidadas   cuando se producen errores.

Esta es una referencia aparente * al siguiente texto de RFC 5246 (énfasis mío):

  

7.2. Protocolo de alerta

     

Uno de los tipos de contenido admitidos por la capa de registro TLS es el   tipo de alerta. Los mensajes de alerta transmiten la severidad del mensaje.   (advertencia o fatal) y una descripción de la alerta. Mensajes de alerta   con un nivel de resultado fatal en la terminación inmediata de la   conexión. En este caso, otras conexiones correspondientes a la   la sesión puede continuar, pero el identificador de sesión DEBE ser invalidado,   evitando que la sesión fallida se use para establecer nuevos   conexiones.

Hablando de manera práctica, elegir terminar la sesión SSL con una alerta fatal en lugar de con una alerta de advertencia close_notify probablemente no causará nada peor que una entrada de registro en el servidor. Debido a que no se cerrará hasta después de que haya concluido el intercambio de datos, es poco probable que la alerta fatal lo afecte. Es el equivalente moral de terminar una conexión TCP con un RST en lugar de un FIN.

(Creo que realmente puedes enviar una alerta close_notify con gravedad grave en lugar de gravedad de advertencia, pero me gustaría probar eso en el cable primero).

Por supuesto, si tiene suficiente control sobre su cliente para afectar la forma en que cierra la sesión, tiene suficiente control para no enviar ID de sesión anteriores en conexiones posteriores, lo que logrará el mismo objetivo. El servidor nunca intentará reanudar una sesión a menos que el cliente haya propuesto primero esa ID de sesión. Pero si, por el contrario, le preocupa que terceros de alguna manera obtengan y reutilicen su ID de sesión, entonces la activación del servidor para purgarlo podría ser razonable.

* Cuando digo 5077 (enero de 2008) referencias 5246 (agosto de 2008), realmente hacía referencia a una versión anterior de la especificación TLS; Solo estoy arrastrando la especificación más reciente para que la veas. De hecho, el lenguaje para "7.2 Alert Protocol" es equivalente para TLS 1.1 (RFC 4346) y TLS 1.0 (RFC 2246) .

    
respondido por el gowenfawr 02.09.2015 - 14:49
fuente

Lea otras preguntas en las etiquetas