¿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) .