¿Con qué frecuencia deben rotarse las claves del ticket de sesión de TLS?

RFC 4346 es la fuente de la recomendación "diaria":

  

Se sugiere un límite superior de 24 horas para el tiempo de vida de la ID de sesión,   ya que un atacante que obtiene un master_secret puede ser capaz de   hacerse pasar por la parte comprometida hasta el ID de sesión correspondiente   está retirado.

Si no tiene una mejor guía, probablemente esté bien con las 24 horas. No tengo conocimiento de ninguna investigación o experiencia que sugiera que los tiempos más cortos sean necesarios o apropiados para el tráfico actual.

También puedes ir mucho más bajo. La reanudación de la sesión puede ser un gran problema cuando un cliente lo está atacando con cientos de conexiones en unos pocos minutos. Pero tener que renegociar una vez por hora, por ejemplo, no es oneroso para el cliente o el servidor. Se ahorra el impacto de la CPU de renegociar constantemente, pero hay una brecha enorme entre "todas las conexiones" y una hora, o 30 minutos, o incluso 5 minutos en algunos casos.

Para responder específicamente a tus puntos:

1. 24 horas es el límite superior porque está especificado en RFC 4346. (Obviamente, "porque está en el RFC" no refleja las presiones del mundo real).
2. Dentro de la ventana de 24 horas, solo su tráfico puede guiarlo. ¿Con qué frecuencia se vuelven a conectar los mismos clientes? ¿Se aprovechan de la reanudación si están disponibles? ¿Cuánto tiempo duran sus sesiones en promedio?

Los períodos de validez del certificado no entran en él (ya que 24 horas están muy por debajo de su horizonte de preocupación). Los tiempos de caché de las sesiones de los clientes son interesantes, pero es probable que no estén disponibles para usted, lo que se remonta a lo que dije sobre la frecuencia con la que sus clientes aprovechan la reanudación cuando están disponibles.

Mi consejo personal : puedes jugar en períodos de 1 a 12 horas y probablemente encuentres que todos te brindan el aumento de rendimiento que necesitas con rendimientos decrecientes ( en uso de reanudación) que aparece en algún punto. Encuentre una manera de registrar la reanudación y nuevas negociaciones y cree su caso en las estadísticas de su propio tráfico.

En CloudFlare, los rotamos cada hora . *

Con respecto a su segunda pregunta, debe considerar el soporte de UA. Con los tickets de sesión de larga duración, por ejemplo, las 24 horas, es mucho menos probable que encuentre implementaciones del lado del cliente dañadas. Pero, con los más cortos, como hemos descubierto (con una gran asistencia de clientes y usuarios por igual), comienza a ver sistemas operativos que tienen un soporte RFC 5077 incompleto o incorrecto.

Como este error describe, tanto IE como .NET bloquean cuando su biblioteca de criptografía subyacente (SChannel) intenta procesar el mensaje NewSessionTicket enviado por nuestro borde. Hemos estado en contacto cercano con Microsoft para una solución, pero a veces tiene que solucionar situaciones como esta cuando implementa agresivamente nuevos protocolos y procedimientos de seguridad.

En resumen, vaya tan bajo como quiera, pero esté atento a los problemas del lado del cliente. Si tuviera que adivinar, podrían estar más extendidos que solo Microsoft.

* El enlace discute nuestra implementación de Keyless SSL pero es válido para nuestra terminación estándar de HTTPS