Hace unos días leí una publicación de blog sobre la reanudación de sesiones en nginx.
En ese texto, el autor afirma que nginx no ofrece la posibilidad de borrar periódicamente el caché de la sesión. Una vez que "ssl_session_timeout" ha expirado, la sesión ya no se usa, pero el archivo todavía está en el disco duro y un atacante podría leerlo, por lo que "Forward Secrecy" sería inútil en este momento.
En lugar de utilizar ID de sesión, sugiere desactivar la caché de sesión y utilizar tickets de sesión. Para ello, se debe crear al menos una vez al día una "ticket_key" con 80 bytes de aleatoriedad.
Busqué en Internet más información pero no encontré nada útil.
P1: ¿Cuál es la ubicación del caché de sesión de nginx y cómo puedo verificar si los datos (sesiones) de conexión TLS están en el disco duro?
P2: ¿Es recomendable utilizar Tickets de Sesión?
Respuesta1
No puedo responder a la primera pregunta pero puedo hablar un poco sobre la segunda.
Esta publicación de blog brinda buena información sobre las fallas con los tickets de sesión en TLSv1.2:https://blog.filippo.io/we-need-to-talk-about-session-tickets/.
Entonces, como dice Michael, ambos tienen sus problemas y solo si usas TLSv1.3 (literalmente acaba de cerrar la sesióny por lo tanto está disponible en implementaciones al momento de escribir este artículo) ¿puede usar la reanudación de TLS de manera completamente segura?
Sin embargo, decir que el costo de rendimiento de no utilizar la reanudación de la sesión TLS es significativo y, en mi humilde opinión, los riesgos son relativamente bajos (si alguien tiene acceso a su servidor, en lo que a mí respecta, se acabó el juego). Por ahora recomiendo usar tanto identificadores de sesión como tickets de sesión. Especialmente porque algunos clientes (Safari e IE en Windows 7 y versiones anteriores) no admiten tickets de sesión. Safari en particular todavía tiene muchos usuarios en dispositivos móviles y tabletas. ¿Realmente deseas ralentizar significativamente a todos los usuarios de iOS?