¿Qué es un Handshake? Protocolo de Enlace en Redes y Criptografía

Cada vez que abres Instagram, revisas tu correo bancario o envías un mensaje por WhatsApp, algo invisible ocurre en milisegundos: dos dispositivos se dan la mano digitalmente. Ese apretón de manos electrónico se llama handshake (protocolo de enlace), y sin él, Internet sería un caos de datos perdidos, conexiones falsas y ciberseguridad inexistente.

En términos simples: el handshake es el ritual de acuerdo inicial entre dos equipos antes de intercambiar información. Define quién habla primero, a qué velocidad, en qué idioma y cómo asegurarse de que nadie escucha. En redes, es como dos operadores de radio acordando una frecuencia; en criptografía, es como dos espías intercambiando claves secretas sin que el enemigo las vea.

Pero no te quedes con la analogía. En este artículo vas a aprender paso a paso cómo funciona un handshake TCP (el más común), qué ocurre en el famoso «three-way handshake», cómo SSL/TLS añade capas de cifrado, y por qué entender esto es clave para cualquier estudiante de redes, ciberseguridad o desarrollo backend.

El problema que resuelve el handshake: ¿por qué no basta con «conectar»?

Imagina que llamas por teléfono a un amigo. Si ambos empiezan a hablar al mismo tiempo, no se entienden. Si uno susurra y el otro grita, la comunicación falla. Y si un extraño se une a la línea, tu secreto queda expuesto.

En redes de datos pasa igual. Cuando tu ordenador quiere hablar con un servidor en Tokio, no basta con enviar paquetes al azar. Necesitas:

1. Verificar que el servidor realmente existe y está escuchando (no enviar datos a un fantasma).
2. Acordar parámetros comunes (tamaño de ventana, número de secuencia, timeout).
3. Establecer un canal seguro si la información es sensible (contraseñas, datos médicos, pagos).

El handshake resuelve estos tres problemas en menos de 100 milisegundos. Sin él, tu «Hola» podría llegar cuando el servidor no espera nada, o peor: un atacante podría hacerse pasar por el servidor y robar tus credenciales.

El handshake en redes: TCP y el famoso «Three-Way Handshake»

El protocolo más extendido en Internet es TCP (Transmission Control Protocol). Su handshake de tres vías es obligatorio para conexiones HTTP, HTTPS, SSH, FTP y casi todo lo que requiere fiabilidad.

Paso a paso del Three-Way Handshake

Supongamos que tu equipo (Cliente A) quiere conectarse a un servidor web (Servidor B). Los mensajes son segmentos TCP con banderas (flags) especiales.

Paso 1 – SYN
El cliente envía un segmento con la bandera SYN (synchronize) activada. Incluye un número de secuencia inicial (ISN) aleatorio, por ejemplo, SEQ=100.
Traducción: «Hola servidor, quiero hablar contigo. Empezaré contando desde 100.»

Paso 2 – SYN-ACK
El servidor responde con SYN+ACK. Reconoce el número de secuencia del cliente (ACK=101) y envía su propio número de secuencia (SEQ=300).
Traducción: «Recibí tu 100, espero el 101. Yo empezaré a contar desde 300. ¿De acuerdo?»

Paso 3 – ACK
El cliente envía un ACK puro (ACK=301).
Traducción: «Recibido tu 300, espero el 301. Conexión establecida.»

A partir de este momento, ambos pueden enviar datos. Si faltara alguno de estos tres mensajes, la conexión no nace.

¿Por qué tres y no dos?

Si solo fueran dos pasos (SYN y SYN-ACK), el servidor quedaría con recursos reservados sin confirmación real del cliente. Un atacante podría inundar al servidor con falsos SYN (ataque SYN Flood). El tercer paso (ACK) valida que el cliente realmente existe y quiere la conexión.

Ejemplo visual para estudiantes

text

CLIENTE                                 SERVIDOR
   | --- SYN (SEQ=100) ---------------> |
   | <--- SYN+ACK (SEQ=300, ACK=101) --- |
   | --- ACK (SEQ=101, ACK=301) -------> |
   |                                     |
   | === DATOS SEGUROS ===>              |

Este esquema es clásico en exámenes de redes. Memorízalo: SYN, SYN-ACK, ACK.

Más allá de TCP: handshakes en otros protocolos

No solo TCP usa handshakes. Aquí tienes otros ejemplos relevantes:

• UDP (sin handshake formal): UDP es como lanzar cartas al viento sin confirmación. No hay protocolo de enlace. Por eso es rápido pero poco fiable (usado en streaming y VoIP). Aun así, aplicaciones sobre UDP (como QUIC) implementan sus propios handshakes.
• Wi-Fi (4-way handshake): Cuando te conectas a una red WPA2/WPA3, ocurre un intercambio de 4 mensajes entre tu dispositivo y el punto de acceso. Allí se deriva la clave de sesión sin enviar la contraseña por el aire.
• Bluetooth: Define un handshake de págin y escaneo antes de emparejar dispositivos.
• HTTP/2 y HTTP/3: Sobre TLS, añaden handshakes adicionales para negociar protocolos y priorizar flujos.

Pero el más importante después del TCP es el handshake criptográfico, al que dedicamos el siguiente bloque.

Handshake en criptografía: SSL/TLS, el guardián del candado verde

Cuando ves el candado 🔒 en la barra de direcciones, has presenciado un TLS handshake (antes llamado SSL). Este protocolo de enlace ocurre dentro de la conexión TCP ya establecida. Su misión es triple:

• Autenticar al servidor (y opcionalmente al cliente).
• Negociar los algoritmos de cifrado (cifrados simétricos, asimétricos, funciones hash).
• Generar claves de sesión compartidas sin transmitirlas explícitamente.

El TLS Handshake resumido (versión 1.2 y 1.3)

Paso 0 – ClienteHello
El cliente envía: lista de cifrados que soporta (por ejemplo, AES-256-GCM, ChaCha20), un número aleatorio (Client Random) y la versión de TLS.

Paso 1 – ServerHello
El servidor elige un cifrado común, envía su propio número aleatorio (Server Random) y su certificado digital (con su clave pública).

Paso 2 – Verificación del certificado
El cliente valida que el certificado sea emitido por una autoridad confiable (CA), que no esté revocado y que el dominio coincida. Aquí se previenen ataques «man-in-the-middle».

Paso 3 – Intercambio de claves
Usando algoritmos como Diffie-Hellman (o RSA en versiones antiguas), ambas partes calculan un «secreto maestro» sin enviarlo directamente. Luego derivan claves simétricas para el resto de la sesión.

Paso 4 – Finished
Ambos envían un mensaje cifrado con toda la conversación previa hasheada. Si coincide, el handshake ha sido íntegro.

Resultado: a partir de ahora, todos los datos viajan cifrados simétricamente (rápido). El handshake asimétrico solo ocurre al inicio.

TLS 1.3: menos latencia, más seguridad

TLS 1.3 (estándar desde 2018) reduce el handshake de 2 viajes (2-RTT) a solo 1-RTT en el mejor caso, e incluso 0-RTT para reconexiones. Además elimina cifrados débiles (RSA, CBC, SHA-1). Para el estudiante: prefiere siempre TLS 1.3.

Diferencias clave entre handshake de red (TCP) y criptográfico (TLS)

En la práctica, una conexión HTTPS completa combina ambos: primero el TCP handshake, luego el TLS handshake dentro del mismo canal. Solo después comienza el envío de datos HTTP.

Vulnerabilidades y ataques conocidos al handshake

Estudiar el handshake también implica conocer cómo atacarlo. Estos son los más famosos:

• SYN Flood: El atacante envía muchos SYN sin completar el ACK. El servidor agota su cola de conexiones semiabiertas. Mitigación: SYN cookies.
• TCP Reset attack: Un atacante inyecta un paquete RST (reset) con números de secuencia adivinados para cortar la conexión.
• SSL/TLS downgrade attack: Forzar al cliente y servidor a usar versiones viejas e inseguras (como SSL 3.0). Mitigación: TLS_FALLBACK_SCSV.
• Heartbleed (no es un ataque al handshake per se, sino a la extensión heartbeat de TLS, pero explotaba la memoria tras el handshake).
• Man-in-the-Middle (MITM) en handshake: Si el cliente no valida el certificado, el atacante puede interponerse y negociar dos handshakes separados (uno con el cliente, otro con el servidor). Por eso la validación de certificados es obligatoria.

Simulación práctica para estudiantes (usando Wireshark o tcpdump)

No hay mejor forma de aprender que verlo en vivo. Sigue estos pasos:

1. Instala Wireshark.
2. Inicia una captura con filtro: tcp.port == 443 (para HTTPS) o tcp.port == 80.
3. Abre https://example.com en el navegador.
4. Detén la captura y busca los paquetes con colores especiales.
5. Identifica:
   • Los tres paquetes TCP (SYN, SYN-ACK, ACK) – verás flags en la columna «Info».
   • Luego los paquetes TLS: «Client Hello», «Server Hello», «Certificate», «Key Exchange», «Finished».
   • Observa cómo el ACK del TCP handshake y el Client Hello a menudo viajan juntos.

Este ejercicio es habitual en cursos CCNA, CompTIA Network+ y ciberseguridad.

Aplicaciones del mundo real (no solo navegadores)

El concepto de handshake trasciende a la web:

• APIs REST y GraphQL: Cada petición HTTP/2 o HTTP/3 sobre TLS inicia con handshake (aunque se reutiliza conexión con Keep-Alive).
• Bases de datos remotas (PostgreSQL, MySQL): Usan handshake propio para autenticar y negociar cifrado.
• SSH: Su handshake negocia algoritmos de intercambio de claves, autenticación (usuario/contraseña o clave pública) y cifrado.
• VPN (IPsec/IKE): El protocolo IKE (Internet Key Exchange) es un handshake complejo que establece SA (Security Associations) para cifrar todo el tráfico.
• Blockchain (nodos Bitcoin/Ethereum): Al conectarse entre pares, realizan un handshake de versión/verack para intercambiar inventario de bloques.

Mitos comunes sobre el handshake

• Mito 1: «El handshake solo ocurre al principio».
  Realidad: En TCP puede haber renegociación (ej: ventana cero), y en TLS hay re-handshakes si cambian las credenciales.
• Mito 2: «Tener un handshake significa que la conexión es segura».
  Realidad: TCP handshake no cifra nada; TLS handshake sí, pero si usas cifrados obsoletos o certificados autofirmados, la seguridad es falsa.
• Mito 3: «UDP no puede tener handshake».
  Realidad: A nivel de protocolo base no, pero aplicaciones sobre UDP (como QUIC, WebRTC o TFTP) implementan sus propios mecanismos de saludo.

El futuro: handshakes más rápidos y post-cuánticos

La evolución del handshake busca dos cosas: menos latencia (especialmente en móviles y IoT) y resistencia a computadoras cuánticas.

• TCP Fast Open (TFO): Permite enviar datos en el primer SYN, ahorrando un RTT. Requiere soporte en ambos extremos.
• TLS 1.3 0-RTT: En reconexiones, el cliente envía datos cifrados junto al ClientHello. Riesgo: ataques de repetición.
• Handshakes post-cuánticos: Algoritmos como Kyber (NIST finalista) reemplazarán a Diffie-Hellman y RSA para resistir ataques con ordenadores cuánticos. IETF ya trabaja en extensiones para TLS.

Como estudiante, te recomiendo seguir los RFCs: RFC 793 (TCP), RFC 8446 (TLS 1.3) y RFC 7413 (TCP Fast Open).

Resultados de aprendizaje

Después de leer este artículo completo, el estudiante será capaz de:

1. Definir con precisión qué es un handshake (protocolo de enlace) y diferenciar sus usos en redes vs. criptografía.
2. Describir paso a paso el three-way handshake de TCP, incluyendo los flags SYN, ACK y los números de secuencia.
3. Explicar por qué el handshake TCP requiere tres mensajes y no dos, identificando el riesgo de ataque SYN Flood.
4. Diferenciar el handshake de red (capa de transporte) del handshake criptográfico TLS (capa de sesión/aplicación).
5. Enumerar los mensajes clave de un TLS handshake: ClientHello, ServerHello, Certificate, Key Exchange y Finished.
6. Identificar vulnerabilidades clásicas (downgrade attack, MITM por certificados inválidos) y sus mitigaciones.
7. Analizar una captura de Wireshark para reconocer paquetes SYN, SYN-ACK, ACK y mensajes TLS.
8. Aplicar el concepto de handshake a otros ámbitos como SSH, VPN, Wi-Fi (4-way handshake) y blockchain.
9. Comparar las mejoras de latencia en TLS 1.3 y TCP Fast Open frente a versiones anteriores.
10. Evaluar la importancia de la validación de certificados en un handshake TLS para prevenir ataques Man-in-the-Middle.

Rodrigo Ricardo Editor y fundador