Reanudación de sesión SSL / TLS con tickets de sesión

6

Ya tenemos habilitada la reanudación de sesión SSL utilizando un caché de sesión. Sobre la base de un informe de rendimiento interno, se recomienda habilitar la reanudación de la sesión utilizando los tickets de sesión.

¿El aumento de rendimiento obtenido de esto vale el riesgo de seguridad adicional? (Por lo que entiendo, solo hay un problema si el cliente está comprometido. ¿Podría un compromiso de uno o varios clientes hacer que todo el tráfico cifrado se vea comprometido?)

¿Habría fallas / problemas si no todos los clientes admitieran esto? (Por lo que puedo ver, el cliente anunciará que admite Tickets de sesión y luego el servidor reaccionará en consecuencia, los clientes que no lo admitan no se verán afectados)

    
pregunta rudolfv 27.11.2014 - 12:16
fuente

1 respuesta

12

Si un cliente está comprometido, entonces ese cliente está comprometido. Los tickets de sesión no cambian de una manera u otra ...

Los tickets de sesión son una extensión TLS por la cual el servidor inserta el contexto de la sesión en el cliente. Desde el punto de vista del cliente, el ticket es opaco. Para evitar la falsificación o alteración de los tickets por parte de clientes malintencionados, se supone que el servidor debe emplear un cierto control de encriptación e integridad al crear el ticket. Si el servidor hace su trabajo correctamente (por ejemplo, como se recomienda en en el RFC ), los tickets de la sesión no se presentan cualquier debilidad extra. Un cliente comprometido / malicioso no aprenderá nada que le permita descifrar las sesiones TLS de otros clientes o falsificar tickets.

La única situación en la que no se recomiendan los tickets de sesión es cuando los servidores desean un control preciso sobre la duración máxima de la sesión para cada cliente, independientemente de otros clientes (por ejemplo, si la administración de la sesión de su sitio web depende de la sesión TLS en lugar de alguna cookie de nivel HTTP o algo similar). Cuando el contexto de la sesión se guarda del lado del servidor, es fácil que el servidor simplemente olvide ese contexto. Con los tickets de sesión, no puede imponer el olvido en el lado del cliente. Pero no estamos hablando de debilidades , solo funcionalidades.

Dado que los tickets de sesión de TLS son una extensión TLS , no afectan a los clientes que no los conocen. Una conexión TLS dada utilizará un ticket solo si el cliente anuncia explícitamente el soporte para la extensión en el mensaje ClientHello . Si un cliente no admite los tickets de sesión TLS (por ejemplo, IE en Windows 7), entonces no hablará de los tickets de sesión en su ClientHello , y el servidor tampoco dirá nada sobre los tickets de sesión.

La consecuencia, sin embargo, es que incluso si activa los tickets de sesión, esta es una optimización oportunista. El servidor todavía debe poder manejar sesiones "normales" para clientes que no admiten tickets de sesión. No debe desactivar las sesiones sin boleto hasta que todos los clientes hayan implementado el nuevo soporte. Debido a que la implementación de TLS en Windows 7 no tiene conocimiento de los tickets de sesión, es probable que tenga que seguir admitiendo sesiones sin ticket durante algunos años.

    
respondido por el Thomas Pornin 27.11.2014 - 13:19
fuente

Lea otras preguntas en las etiquetas