Apache Tomcat tiene la capacidad de usar el ID de sesión TLS en lugar de una cookie de sesión o JSESSIONID en la cadena de consulta. Mi sitio es HTTPS en todas partes.
Esto parece útil porque no tengo que preocuparme por el robo de cookies de sesión, y puedo usar sesiones para agentes de usuarios que no hacen cookies.
¿Soy inmune al secuestro de sesión / a la fijación de sesión aquí?
¿Alguna otra cuestión que deba preocuparte?
Los identificadores de sesión SSL son de texto simple y son visibles para cualquiera que vea los bits que vuelan a través de la red. Si te preocupa el secuestro, esta no sería una buena idea.
Supongo que se refiere al ID de sesión TLS como se especifica en RFC 4507
No, no creo que esto te dé lo que necesitas. El ID de sesión TLS es un ticket proporcionado por el servidor al cliente que permitirá al cliente reanudar una sesión más tarde (es decir, después de que la sesión existente haya cesado). Esto se enfoca en la capa TLS, que puede considerarse como una capa debajo de su capa de aplicación. La capa TLS consiste en establecer la conexión segura y no sabe nada sobre el nivel de su aplicación.
Cuando se conecta por primera vez a un servicio habilitado para TLS, hay un proceso de intercambio entre el servidor y el cliente que se utiliza para establecer la conexión segura. Con el uso de la ID de sesión, el proceso de intercambio puede reducirse en las conexiones subsiguientes; al proporcionar una ID de sesión válida, el cliente esencialmente dice "Oye, vamos a conectarnos nuevamente y usamos las mismas claves de cifrado, etc. que usamos la última vez. El servidor puede decir "Oye, genial, vamos" o puede decir: "Lo siento, ha pasado demasiado tiempo, tenemos que volver a negociar".
Como esta es una capa debajo de su aplicación, el ID de sesión TLS no sabe si está autenticado con la aplicación o cuál es su nivel de autorización. Normalmente, esto solo ocurrirá después de que se haya negociado y establecido la conexión TLS. No puede agregar esta información a la ID de sesión TLS ya que este es un valor cifrado generado por la capa TLS del lado del servidor. Esto también significa que su aplicación no puede determinar las credenciales de usuario a partir del ID de sesión TLS.
Si sus usuarios necesitan ser autenticados y autorizados, realmente necesita administrar eso en una sesión o cookie de nivel de aplicación, debe poder verificar que no se ha modificado y debe incluir protección adicional, como Los tokens de protección CSRF y usted necesita verificar todo esto en cada solicitud.
Lea otras preguntas en las etiquetas web-application tls session-management