En SSL, el cliente y el servidor pueden participar en un handshake abreviado solo si el cliente y el servidor recuerde los "parámetros del protocolo de enlace" (en particular, el secreto pre-master negociado). El "ID de sesión" es la forma en que el cliente y el servidor anuncian su recuerdo: el cliente envía en su ClientHello una copia del ID de sesión anterior, y el servidor lo envía para confirmar que esta sesión será reutilizada.
No puede eliminar el ID de sesión del mensaje del cliente sin romper las operaciones criptográficas subsiguientes, porque los mensajes Finished al final del protocolo de enlace se calculan como valores hash en todos los mensajes intercambiados anteriormente, que incluyen el ClientHello . Por lo tanto, el cliente y el servidor DEBEN "ver" el mismo ClientHello . (Sin embargo, ver más abajo).
Por lo tanto, para evitar un apretón de manos abreviado, debe imponer el olvido. Los servidores SSL pueden configurarse para no recordar sesiones más allá de un tiempo de espera de inactividad; por ejemplo, vea Apache mod_ssl directives SSLSessionCache y SSLSessionCacheTimeout . Apagar y reiniciar el servidor también puede vaciar la memoria caché, siempre que la memoria caché se mantenga en la RAM (con servidores de múltiples frentes, la memoria caché se puede compartir con una base de datos común o algo similar, en cuyo caso la purga de la memoria caché puede ser más compleja ).
En el lado del cliente, las sesiones SSL normalmente se guardan en la RAM. Internet Explorer, por ejemplo, consiste internamente en un proceso varios que se comunican entre sí, y debe eliminarlos todos para que se olvide de una sesión SSL (en la práctica, esto ocurre solo cuando se ha cerrado < em> all las ventanas de IE).
Sin embargo, tu cita es extraña:
Usando herramientas como Wireshark, es posible descifrar el tráfico SSL como el cliente al registrar el secreto (pre) maestro, sin usar un ataque mitm o la clave privada del servidor.
Wireshark no puede hacer eso. Wireshark inspecciona los paquetes de datos en tránsito y, a partir de estos paquetes, no puede deducir el secreto maestro previo sin tener una copia de la clave privada del servidor. Ese es el punto entero de SSL: para evitar que los intrusos puedan entender los datos intercambiados. Para poder ingresar a la sesión SSL desde el punto de vista del "interceptor de red", debe hacer un Ataque Man-in-the-Middle , con doble personificación; y esto puede suceder solo si pasa por alto el modelo de seguridad del certificado: debe convencer al usuario humano (cliente SSL) para que instale una clave de CA falsa o falsa, o para "hacer clic" en rojo y aterrador advertencia de que el navegador se muestra cuando advierte que el supuesto certificado del servidor es funky.
Si puede "registrar el secreto pre-maestro", esto significa que tiene acceso privilegiado a los contenidos de RAM del cliente o del servidor; ese acceso no usaría Wireshark, sino un depurador. Lo que ofrece Wireshark es la posibilidad de usar algún secreto pre-maestro capturado (por ejemplo, ver esta página ); Con esta información, Wireshark podrá descifrar los datos. Sin embargo, no (y no puede) hacer la captura por sí misma: esto requiere acceso directo a la memoria RAM del cliente o servidor, o un cliente o servidor modificado para filtrar la información. Para hacer una analogía, no puedes hacer una cirugía cerebral por teléfono.
Si sí tiene un acceso similar al depurador al cliente (o al servidor), entonces debería poder manipular al cliente (servidor respectivamente) para que se "olvida" de una sesión SSL anterior, lo que obliga a un nuevo saludo completo.