En primer lugar, esta es una pregunta puramente académica. Mi primera respuesta sería que no puede, ya que no tiene la clave de sesión.
¿Podría al menos matar la conexión, como por ejemplo enviando solicitudes FIN falsas o algo así?
Casi cualquier ataque activo lleva a una conexión abortada. Esto incluye interrumpir la conexión TCP según sugiera, o manipular la carga útil, lo que desencadena un error de MAC, que a su vez interrumpe la conexión.
Las interrupciones de TCP han ocurrido en la práctica. Si bien esto fue contra las conexiones de bittorrent, y no protegidas por SSL, SSL sobre TCP no puede evitar este tipo de ataque.
Según pruebas independientes, Comcast inyectó paquetes de restablecimiento en las conexiones de igual a igual, lo que provocó que un cierto número limitado de conexiones salientes finalizara de inmediato. Este método de administración de red se describió en el artículo "Comunicaciones IEEE de mayo de 2000" Control de admisión de conexión TCP no intrusiva para la administración de ancho de banda de un enlace de acceso a Internet "
Es importante tener en cuenta que el software que usa TLS puede distinguir las conexiones interrumpidas de las conexiones que se cerraron correctamente, porque una conexión cerrada con gracia termina con un mensaje "BYE" de TLS, que no puede ser falsificado por un atacante.
DTLS sobre UDP puede ser más robusto ya que no puede interrumpir la conexión TCP. Pero, por supuesto, un atacante puede simplemente tragar todos los mensajes que impiden que la conexión continúe.
SSL 2.0 no incluía un protocolo de terminación verificado, por lo que cualquier parte involucrada en una conexión SSL 2.0 que recibe un cierre en el nivel TCP no podría determinar de manera confiable si el par realmente quería cerrar la sesión SSL o no. Este fue un gran problema, especialmente con HTTP porque, en HTTP 1.0, se le permite no enviar un encabezado Content-Length , en lugar de depender de la terminación del medio de transporte subyacente para marcar el final de los datos. Por lo tanto, el truncamiento silencioso era posible.
Esto se ha corregido en SSL 3.0 y versiones posteriores (es decir, TLS, porque TLS 1.0 es SSL 3.1). Se intercambian un par de mensajes de "Alerta" SSL del tipo close_notify , y estos mensajes, como todo lo demás en el túnel, se benefician de la protección de la criptografía (en particular, la integridad comprobada).
Si asumimos que TLS 1.2 es correcto y seguro, hay poco que pueda hacer un atacante, excepto interrumpir el servicio. Puede forzar una conexión cerca (a nivel de TCP) pero ambas partes sabrán que algo sucedió. Más insidiosamente, un atacante con control total de uno de los enrutadores podría ralentizar la conexión, eliminando paquetes (forzando a las implementaciones de TCP a emitir nuevamente) y haciendo otros trucos desagradables (por ejemplo, obligando a las partes a envíe paquetes más pequeños enviando paquetes falsos de ICMP que afirman que un paquete dado no se pudo reenviar porque es demasiado grande). El atacante puede enviar a los usuarios de SSL persiguiendo gansos durante mucho tiempo, sin hacer nada tan burdo y visible como la terminación de una conexión. Debido a la naturaleza muy flexible de TCP, el atacante podría reducir el ancho de banda a, por ejemplo, 30 bytes por segundo (emulando un módem de 300 baudios ...), que es bastante similar a la interrupción total en la práctica, excepto que los sistemas informáticos en ambos extremos todavía creería que la conexión estaba viva y bien, y no la abandonaría para iniciar una nueva.
No tengo conocimiento de ningún método para manipular una sesión SSL / TLS establecida. Un ataque de este tipo puede tener éxito si un atacante puede obtener acceso (o interrumpir) de alguna manera el establecimiento de la clave de sesión simétrica. Por lo tanto, si la sesión SSL / TLS es de larga duración o almacenada en caché y el adversario de alguna manera pudo obtener acceso a la clave de la sesión, entonces es posible que el adversario manipule la sesión existente.
Al subir algunas capas, generalmente es mucho más fácil instalar algún * ware en el dispositivo víctima para interceptar / manipular el tráfico en los puntos finales. Si baja algunas capas, entonces la finalización de la sesión es bastante trivial, pero no necesariamente calificaría como manipulación de la sesión. Sin embargo, bajar una capa y lanzar un ataque l1 / l2 es posible. Básicamente, MITM en l2 (envenenamiento de caché arp) o l1 (puente físico) se conecta a la secuencia.