Está bien, argumentaré que esa afirmación no es bastante correcta. La declaración es correcta si asumimos que no se están enviando opciones de TCP. En teoría, un atacante que puede espiar paquetes puede inyectar un paquete correctamente diseñado en el servidor y confundir la conexión.
En la práctica, casi todas las conexiones TCP de hoy en día están optimizadas y usan escala de ventana . Definen un tamaño de ventana para recibir datos más rápido, y no necesitan reconocer cada paquete.
Ahora, esto depende de la implementación, pero todos los datos de una ventana deben mantenerse en un búfer en lugar de pasarlos a la aplicación porque puede ocurrir que la ventana completa no se confirme correctamente.
Si un atacante M está escuchando la conexión, solo envía un paquete al servidor S con menos datos que el tamaño de la ventana (lo más probable es que las ventanas suelen ser un puñado de megabytes), ese paquete de datos terminará en el búfer con su ubicación definida por el número de secuencia.
El cliente A ahora envía un paquete al servidor S continuando la conexión, es probable que el contenido del paquete se descargue ciegamente en el búfer que contiene la ventana. Y el atacante no confunde la conexión.
Lo anterior tampoco es estrictamente cierto. Un ACK se puede enviar en cualquier momento durante la recolección de los paquetes para la ventana , no solo cuando se alcanza el tamaño de la ventana. En términos prácticos, esto (lo más probable) significa que:
- El atacante M puede enviar un solo paquete para interferir con una conexión de movimiento lento (mucho tiempo para que el servidor S envíe ACK).
- El atacante M tendrá problemas para interferir con una conexión acelerada donde el servidor S decide esperar a que se llene la ventana en lugar de enviar ACK.
En una conexión de ritmo rápido, el atacante M deberá llenar la ventana con sus datos antes de que lleguen los datos del cliente. Esto todavía es factible si el atacante M está más cerca del servidor S que del cliente A .
Referencias