Reanudación de sesión SSL e ID

9

Algunos sitios, como se ve en el informe para www.mbank.com.pl [ssllabs.com] o report for aliorbank.pl [ssllabs.com] no admite "Reanudación de sesión", ya sea porque los ID están asignados pero no son aceptados (primer caso) o porque los ID están vacíos (segundo caso).

No está relacionado con la renegociación segura, como se puede ver en informe para poczta.interia.pl [ssllabs.com] donde la reanudación de la sesión no está disponible, mientras que la renegociación se realiza de manera segura.

Pregunta: ¿Por qué está en rojo? ¿Es una vulnerabilidad de seguridad?

    
pregunta Hubert Kario 20.07.2011 - 23:22
fuente

2 respuestas

8

No admitir la reanudación de la sesión es no una vulnerabilidad de seguridad; pero implica un nuevo protocolo de enlace por conexión, que puede aumentar la latencia (un protocolo completo implica más viajes de ida y vuelta que una sesión reanudada) y el costo de la CPU (principalmente en el servidor, con el intercambio de claves RSA común).

El primer servidor es un tanto descortés, ya que devuelve un ID de sesión no vacío que rechazará de todos modos; lo que hace el segundo servidor (devolver un ID vacío) es lo que recomienda el SSL / TLS standard . Sin embargo, devolver un ID de sesión no vacío para una sesión que no se puede resumir no es un error verdadero.

Presumiblemente, ssllabs.com usa el color rojo aquí porque es relativamente poco frecuente desactivar la reanudación de la sesión, y por lo tanto esto puede ser un "error de configuración" que vale la pena informar (aunque el rojo puede desviarse demasiado por el miedo) .

    
respondido por el Thomas Pornin 21.07.2011 - 02:31
fuente
2

Como ya señaló Thomas, deshabilitar la reanudación de la sesión no es una vulnerabilidad. La reanudación de la sesión es en realidad una función de rendimiento para reducir la latencia de las solicitudes posteriores al mismo servidor realizado en un corto período de tiempo.

Hay una razón por la que algunos servidores devuelven una ID de sesión y luego se niegan a aceptarla (de lo que se queja esta prueba). Recuerdo que este comportamiento es una solución alternativa para al menos un navegador que no pudo manejar correctamente la falta de una ID de sesión [cita requerida].

En cuanto a su conexión, deshabilitar la reanudación de la sesión puede mejorar la seguridad. La reanudación de la sesión puede perjudicar la eficacia de secreto hacia adelante al continuar reutilizando las sesiones.

En algunos casos, un servidor mal configurado puede anular por completo todos los beneficios del secreto de retransmisión configurando su servidor para almacenar los detalles de reanudación durante un largo período de tiempo. RFC4346 sugiere un límite superior de 24 horas en el tiempo de vida de una sesión, sin embargo, todavía se sugiere que los navegadores acepten cualquier tiempo de vida que use el servidor.

    
respondido por el anthonyryan1 24.03.2014 - 11:28
fuente

Lea otras preguntas en las etiquetas