¿Las sesiones del navegador SSL se mantienen activas en todas las solicitudes?

TL; DR: las sesiones HTTP y las sesiones SSL son entidades diferentes y no hay asignación de una a otra.

Sobre los detalles ...

  

Cuando un cliente solicita un recurso web SSL a través de un navegador (es decir, una solicitud de inicio de sesión) y luego realiza solicitudes adicionales, ¿se ejecutan todas las solicitudes en la misma sesión SSL?

El servidor o el cliente pueden terminar una conexión SSL, pero, por razones de rendimiento, las sesiones existentes se reutilizan cuando es posible.

  

los servidores realizan un seguimiento del estado de la sesión a través de estas solicitudes únicamente a través de cookies que están cifradas a través del protocolo SSL o hay alguna funcionalidad proporcionada a través de SSL donde los servidores saben que la solicitud inicial provino del mismo navegador que las siguientes solicitudes

Las cookies suelen ser el único mecanismo de mantenimiento de la sesión cuando se comunican con un navegador. Las alternativas pueden ser identificaciones de sesión pasadas como campos ocultos o sesiones administradas por JavaScript personalizado existente en la página. De hecho, los clientes pueden multiplexar sesiones múltiples en una sola conexión SSL. La única excepción a las sesiones de multiplexación es cuando se utiliza autenticación mutua . Cuando esto ocurre, el cliente se autentica durante el protocolo de enlace TLS. Establecer identidad no es lo mismo que establecer una sesión, pero ciertamente están relacionados.

  

¿Si es solo a través de las cookies cifradas, evitará que alguien falsifique el valor de la cookie de alguna manera y realice una solicitud con esa cookie falsificada, haciéndose pasar por el usuario original?

Se refiere a secuestro de sesión . Algunas estrategias que se utilizan para evitar el secuestro de sesiones son elegir un ID de sesión difícil de adivinar (generalmente, lo mejor es aleatorio y largo), solo aprobar la cookie de ID de sesión a través de SSL para evitar la indagación de la red, y no permite el acceso a la cookie de ID de sesión a través de JavaScript . Desafortunadamente, a pesar de todas esas defensas, Autenticación rota y gestión de sesión sigue siendo el segundo más común defecto de seguridad según el Top-10 de OWASP 2013.

Las sesiones HTTP y las sesiones TLS son independientes.

HTTP realiza un seguimiento de la sesión generalmente con cookies HTTP. Las solicitudes de una sola sesión HTTP pueden enviarse a través de múltiples conexiones TLS, cada una con sus propias sesiones TLS.

La sesión TLS se rastrea con el ticket de sesión TLS. El ticket de sesión realiza un seguimiento de los parámetros de cifrado (qué cifrado utilizar, clave de sesión, etc.); los parámetros de cifrado generalmente están asociados con una sola conexión TLS, pero TLS también puede reanudar una sesión TLS para crear una nueva conexión TLS con Los mismos parámetros de cifrado que una conexión anterior.

Además, si tiene un servidor proxy, puede multiplexar múltiples solicitudes de diferentes clientes en una sola conexión TLS, y esto significa que puede tener varias sesiones HTTP en una sola conexión TLS.

  

Cuando un cliente solicita un recurso web SSL a través de un navegador (es decir, una solicitud de inicio de sesión) y luego realiza solicitudes adicionales, ¿se ejecutan todas las solicitudes en la misma sesión SSL? ¿O el navegador crea y destruye la sesión con cada solicitud?

Esta es la implementación definida. Los agentes de usuario pueden optar por utilizar múltiples conexiones y / o sesiones TLS si cree que hacerlo será beneficioso para el rendimiento. El navegador moderno normalmente abrirá varias conexiones TLS para realizar solicitudes HTTP / 1.1 simultáneamente hasta un límite (generalmente 4-8 conexiones concurrentes), y luego reutiliza esas conexiones tanto como sea posible. Los navegadores modernos usualmente usarán una sola conexión TLS para solicitudes HTTP / 2 ya que HTTP / 2 admite la multiplexación de solicitudes de forma nativa.

  

Y los servidores rastrean el estado de la sesión a través de estas solicitudes únicamente a través de cookies que están cifradas a través del protocolo SSL

Los servidores HTTP rastrean la sesión HTTP solo a través de cookies HTTP. La parte TLS del servidor web rastrea las conexiones TLS, pero esto es independiente de las sesiones HTTP. Algunos servidores web también pueden usar la autenticación mutua para autenticar al usuario a través del certificado de cliente SSL; y esto también se puede usar para rastrear las sesiones si el servidor está configurado para pasar información sobre el certificado del cliente a la solicitud HTTP -autenticación-detrás-inversa-proxy / inicio "> como encabezados HTTP ).

  ¿

o hay alguna funcionalidad provista a través de SSL donde los servidores saben que la solicitud inicial provino del mismo navegador que las siguientes solicitudes?

TLS tiene tickets de sesión para realizar un seguimiento de las sesiones de TLS.

  

¿Si es solo a través de las cookies cifradas, evitará que alguien falsifique el valor de la cookie de alguna manera y realice una solicitud con esa cookie falsificada, haciéndose pasar por el usuario original?

Si un atacante puede obtener la cookie del navegador de su usuario, ya está perdido.