Funcionamiento

El handshaking de 3 vías comienza con la primera entidad (A) enviando un paquete de sincronización (SYN) a la segunda entidad (B).

La entidad B recibe el paquete SYN y responde con un paquete SYN-ACK, reconociendo la recepción del paquete SYN y enviando su propio paquete SYN. Finalmente,

La entidad A recibe el SYN-ACK y responde con un ACK, culminando el proceso y estableciendo la conexión.

Ventajas

1. Confiabilidad

Este proceso permite que las partes se aseguren mutuamente de que la información enviada y recibida es correcta y llega en orden. Cada paso requiere una confirmación, garantizando que ambas partes están sincronizadas y listas para la transferencia de datos.

2. Control de Flujo

El handshaking ayuda a establecer el tamaño de la ventana de recepción, un factor importante en el control de flujo que evita la sobrecarga de una de las partes con demasiados paquetes de datos.

3. Seguridad

Al establecer una conexión confirmada, se reduce la posibilidad de ataques de terceros. El proceso requiere un reconocimiento (ACK) de cada transmisión, lo que puede disuadir a los actores malintencionados.

Desventajas

1. Tiempo de latencia

El establecimiento de una conexión a través de un handshaking de 3 vías puede llevar tiempo, especialmente en redes lentas o congestionadas, ya que requiere múltiples intercambios de paquetes antes de que los datos puedan ser transferidos.

2. Uso de recursos

Cada paso en el proceso de handshaking utiliza recursos del sistema, tanto en términos de uso de la red como de capacidad de procesamiento en los dispositivos que establecen la conexión.

3. Vulnerabilidad a ciertos ataques

A pesar de proporcionar una capa de seguridad, el handshaking de 3 vías puede ser vulnerable a ciertos tipos de ataques, como el SYN Flood, en el que un atacante inunda un servidor con solicitudes de conexión, agotando sus recursos.

Ataques más comunes al handshaking de 3 vías

1. Ataque SYN Flood

En un ataque SYN Flood, un atacante inunda un servidor con solicitudes de conexión SYN, pero nunca responde con el ACK final que completa el handshaking de 3 vías.

Esto deja muchas conexiones en un estado “semi-abierto” o “SYN_RECEIVED”, consumiendo recursos del servidor y, finalmente, pudiendo causar que el servidor deje de aceptar nuevas conexiones legítimas.

En 1996, la empresa de telecomunicaciones Panix sufrió un famoso ataque SYN Flood.

El ataque dejó al proveedor de servicios de Internet inoperante durante varios días. En este caso, los atacantes enviaron una gran cantidad de paquetes SYN a Panix, consumiendo todos sus recursos disponibles y dejándolos incapaces de manejar el tráfico legítimo.

Desde entonces, los ataques SYN Flood se han vuelto más sofisticados y continúan siendo una amenaza significativa en la seguridad de la red.

Se han implementado varias técnicas de mitigación, como el uso de cookies SYN o la limitación del número de conexiones semi-abiertas permitidas, pero ninguna de estas soluciones es perfecta y la amenaza de los ataques SYN Flood persiste.

2. Ataque de Secuestro de Sesión TCP (TCP Session Hijacking)

Otra vulnerabilidad del handshaking de 3 vías es el riesgo de secuestro de sesión TCP.

Un atacante puede interceptar los paquetes entre dos entidades durante una sesión TCP y luego falsificar los paquetes para hacerse pasar por una de las partes. Esto permite al atacante inyectar datos maliciosos, alterar los datos transmitidos o incluso cerrar la conexión.

Un ejemplo de esto fue el incidente Kevin Mitnick, en el que Mitnick utilizó el secuestro de sesión TCP para robar software de empresas como Novell y Sun Microsystems en los años 90.

3. TCP Reset Attack

En este tipo de ataque, un atacante envía un paquete RST (reset) a una o ambas partes durante una conexión TCP activa, lo que provoca que la conexión se cierre inmediatamente.

Este tipo de ataque puede ser particularmente perjudicial en conexiones de larga duración, como las VPNs, donde una desconexión inesperada puede tener graves consecuencias.

Un ejemplo documentado de este tipo de ataque ocurrió en 2004, cuando se descubrió que era posible interrumpir las conexiones TCP enviando paquetes RST falsificados.

Esto llevó a la publicación de una serie de parches de seguridad por parte de los proveedores de sistemas operativos para tratar de mitigar este tipo de ataque.