TLS Tickets de sesión: ¿Cuál es el riesgo de una clave de ticket de servidor divulgada?

2

Por lo tanto, existe este método de reanudación de sesión TLS utilizando Session Tickets que transfiere el estado secreto del servidor TLS al cliente (cifrado y autenticado con una clave que solo el servidor conoce)

Si un cliente desea reanudar una sesión, simplemente incluye el Ticket de sesión en la solicitud, lo que permite que el servidor reanude la sesión.

Preguntas:

  • ¿Qué sucede si la clave de sesión (servidor) es robada?
  • ¿Qué podría hacer un atacante si registra los paquetes TODOS entre el servidor y varios clientes? ¿Podrá él descifrar todo?

¿El Ticket de la sesión incluye el master_secret (que se usa para criptografía simétrica como AES?) ( RFC 5077, página 11 ).

  • ¿Cómo se reutiliza este master_secret después de la reanudación de la sesión? ¿El servidor y el cliente continuarán reutilizando este master_secret para todos los criptogramas simétricos (por ejemplo, AES)?
pregunta Peter Mueller 07.10.2015 - 11:38
fuente

1 respuesta

5

Ticket crypto broken - > PFS roto.

Creo que esta cita de una excelente publicación en el blog de CloudFlare responde a cada una de tus preguntas.

  

esta clave se convierte en [un] único punto crítico de falla para la seguridad TLS: si un adversario la controla, la información clave de la sesión se expone para cada ticket de sesión. Incluso después de la duración de un boleto de sesión, tal pérdida invalidaría el supuesto "secreto perfecto" (como se evangeliza aquí en nuestro blog).

     

Por lo tanto, es importante:
  "Genere claves de ticket de sesión al azar, distribúyalas a los servidores sin tocar el almacenamiento persistente y gírelas con frecuencia". (Adam Langley)

Y se vinculan a una publicación de blog de Adam Langley que da información para esto:

respondido por el StackzOfZtuff 07.10.2015 - 13:14
fuente

Lea otras preguntas en las etiquetas