Módulo 15 – BONUS: El Handshake TCP y TLS explicado de forma sencilla
+==============================================================================+
| MÓDULO 15 (BONUS): HANDSHAKE TCP + TLS (HTTPS) |
| Duración estimada: 1 hora | Nivel: Principiante absoluto |
+==============================================================================+
Tabla de contenidos
- ¿Por qué esta página?
- El vocabulario básico – Las “banderas” TCP
- El handshake TCP en 3 pasos (SYN / SYN-ACK / ACK)
- ¿Y después del handshake? El intercambio de datos (PSH, ACK)
- ¿Cómo se cierra la conexión? (FIN / FIN-ACK)
- Resumen completo de una conexión TCP
- El handshake TLS – Añadir el candado
- Ejemplo concreto: Abrir https://google.com
- Lo que ve en Wireshark
- Resumen final – La analogía completa
¿Por qué esta página?
Cuando usted abre un sitio web, su navegador y el servidor se comunican. Pero antes de intercambiar cualquier cosa, deben:
- Verificar que pueden comunicarse (handshake TCP)
- Ponerse de acuerdo sobre cómo cifrar (handshake TLS, si es HTTPS)
- Intercambiar los datos (la página web)
- Colgar correctamente (cierre de la conexión)
Todos estos intercambios utilizan pequeñas banderas (flags) en los paquetes de red. Es lo que vamos a explicar aquí, como si usted nunca hubiera hecho redes.
Volver a la tabla de contenidos
El vocabulario básico – Las “banderas” TCP
Imagine que cada mensaje de red es una carta enviada por correo. En cada sobre, hay uno o varios sellos (banderas) que indican qué tipo de mensaje es.
Aquí están las principales banderas TCP:
| Bandera | Nombre completo | Analogía simple | Significado técnico |
|---|---|---|---|
| SYN | Synchronize | 📞 «¿Hola? ¿Estás ahí?» | «Quiero abrir una conexión» |
| ACK | Acknowledge | ✅ «¡Recibido!» | «He recibido tu mensaje» |
| PSH | Push | 📦 «¡Aquí está el paquete, ábrelo de inmediato!» | «Aquí hay datos, procésalos inmediatamente» |
| FIN | Finish | 👋 «Adiós, cuelgo» | «Quiero cerrar la conexión» |
| RST | Reset | ❌ «¡STOP! ¡Colgado a la fuerza!» | «Conexión cancelada / rechazada bruscamente» |
Lo más importante a recordar
- SYN = «quiero empezar»
- ACK = «he entendido / recibido»
- PSH = «aquí están los datos reales»
- FIN = «he terminado, adiós»
Volver a la tabla de contenidos
El handshake TCP en 3 pasos (SYN / SYN-ACK / ACK)
La analogía del teléfono
Imagine que llama a un amigo:
┌─────────────────────────────────────────────────────────────────────┐
│ LLAMADA TELEFÓNICA │
│ │
│ Usted (Cliente) Su amigo (Servidor) │
│ │
│ 1. 📞 «¿Hola? ¿Me oyes?» ──────► │
│ (El teléfono suena) │
│ │
│ ◄────── 2. 📞 «¡Sí, te oigo! │
│ ¿Y tú, me oyes?» │
│ │
│ 3. 📞 «¡Perfecto, podemos hablar!» ──────► │
│ │
│ ═══════════════════════════════════════════════════════════════ │
│ ✅ CONVERSACIÓN ESTABLECIDA — ¡Pueden conversar! │
└─────────────────────────────────────────────────────────────────────┘
Lo mismo en TCP
┌─────────────────────────────────────────────────────────────────────┐
│ HANDSHAKE TCP (3-WAY HANDSHAKE) │
│ │
│ Cliente (su PC) Servidor (ej: google.com)│
│ │
│ PASO 1: SYN │
│ ──────────────────────────────────────► │
│ «Quiero conectarme. Mi número de │
│ secuencia inicial es 100.» │
│ │
│ PASO 2: SYN-ACK │
│ ◄────────────────────────────────────── │
│ «OK, acepto (ACK tu 100). │
│ Mi número de secuencia es 300.» │
│ │
│ PASO 3: ACK │
│ ──────────────────────────────────────► │
│ «Perfecto, recibido (ACK tu 300). │
│ ¡Podemos empezar!» │
│ │
│ ═══════════════════════════════════════════════════════════════ │
│ ✅ CONEXIÓN TCP ESTABLECIDA │
│ ❌ ¡Pero NADA está cifrado por ahora! │
└─────────────────────────────────────────────────────────────────────┘
¿Por qué 3 pasos y no 1?
Es para verificar que la comunicación funciona en ambos sentidos:
| Paso | Demuestra que... |
|---|---|
| SYN (Cliente → Servidor) | El cliente puede enviar al servidor |
| SYN-ACK (Servidor → Cliente) | El servidor ha recibido Y puede responder |
| ACK (Cliente → Servidor) | El cliente ha recibido la respuesta del servidor |
Sin estos 3 pasos, no sabríamos si las dos máquinas realmente se entienden.
Volver a la tabla de contenidos
¿Y después del handshake? El intercambio de datos (PSH, ACK)
Una vez abierta la conexión, circulan los datos reales. Es aquí donde vemos PSH y ACK:
La analogía de la entrega de paquetes
┌─────────────────────────────────────────────────────────────────────┐
│ INTERCAMBIO DE DATOS (después del handshake) │
│ │
│ Cliente (navegador) Servidor (sitio web) │
│ │
│ 📦 PSH,ACK: «Aquí está mi solicitud: │
│ quiero la página de inicio» ──────────────► │
│ (= solicitud HTTP GET /) │
│ │
│ ◄────────────── ✅ ACK: │
│ «Solicitud recibida» │
│ │
│ ◄────────────── 📦 PSH,ACK: │
│ «¡Aquí está la página HTML!» │
│ (= respuesta HTTP 200 OK) │
│ │
│ ✅ ACK: «Página recibida, │
│ ¡gracias!» ──────────────► │
│ │
│ ═══════════════════════════════════════════════════════════════ │
│ 📄 ¡La página se muestra en su navegador! │
└─────────────────────────────────────────────────────────────────────┘
¿Por qué PSH + ACK juntos?
A menudo verá PSH,ACK en Wireshark (ambas banderas al mismo tiempo). Es normal:
| Bandera | Rol en este paquete |
|---|---|
| PSH | «Aquí hay datos, procésalos de inmediato» |
| ACK | «Por cierto, he recibido tus mensajes anteriores» |
PSH = «Envío un paquete»
ACK = «Y acuso recibo de lo que me enviaste antes»
¡Ambos juntos = eficiencia: hacemos dos cosas en un solo paquete!
¿Y si no se pone PSH?
Sin PSH, los datos llegan pero el sistema podría esperar antes de procesarlos (los pone en "buffer"/almacén temporal). Con PSH, es «¡procésalo inmediatamente!».
Piense en la diferencia entre:
- 📬 Poner una carta en el buzón (sin PSH → el cartero la procesará cuando quiera)
- 🚨 Tocar la puerta y decir «es urgente, ¡léelo ya!» (con PSH)
Volver a la tabla de contenidos
¿Cómo se cierra la conexión? (FIN / FIN-ACK)
Cuando la conversación termina, se cuelga correctamente:
┌─────────────────────────────────────────────────────────────────────┐
│ CIERRE DE CONEXIÓN (4-WAY) │
│ │
│ Cliente Servidor │
│ │
│ 👋 FIN,ACK: «He terminado, │
│ quiero colgar» ──────────────► │
│ │
│ ◄────────────── ✅ ACK: │
│ «OK, entendido» │
│ │
│ ◄────────────── 👋 FIN,ACK: │
│ «Yo también he terminado» │
│ │
│ ✅ ACK: «OK, ¡adiós!» ──────────────► │
│ │
│ ═══════════════════════════════════════════════════════════════ │
│ 🔌 CONEXIÓN CERRADA CORRECTAMENTE │
└─────────────────────────────────────────────────────────────────────┘
¿Y RST en todo esto?
RST (Reset), es cuando se cuelga bruscamente, sin despedirse:
| Situación | Lo que ocurre |
|---|---|
| El puerto está cerrado en el servidor | El servidor responde RST → «¡Este servicio no existe!» |
| El firewall bloquea la conexión | O bien RST, o ninguna respuesta (timeout) |
| La aplicación falla | El sistema envía RST para cortar la conexión |
FIN = colgar educadamente 👋
RST = colgar el teléfono en la cara ❌
Volver a la tabla de contenidos
Resumen completo de una conexión TCP
Aquí está todo el ciclo de vida de una conexión TCP, de principio a fin:
┌─────────────────────────────────────────────────────────────────────┐
│ CICLO DE VIDA COMPLETO DE UNA CONEXIÓN TCP │
│ │
│ ╔═══════════════════════════════════════════════════════════╗ │
│ ║ FASE 1: APERTURA (3-way handshake) ║ │
│ ║ ║ │
│ ║ Cliente ──── SYN ────────► Servidor ║ │
│ ║ Cliente ◄─── SYN,ACK ──── Servidor ║ │
│ ║ Cliente ──── ACK ────────► Servidor ║ │
│ ╚═══════════════════════════════════════════════════════════╝ │
│ │ │
│ ▼ │
│ ╔═══════════════════════════════════════════════════════════╗ │
│ ║ FASE 2: INTERCAMBIO DE DATOS ║ │
│ ║ ║ │
│ ║ Cliente ──── PSH,ACK ───► Servidor (solicitud) ║ │
│ ║ Cliente ◄─── ACK ──────── Servidor (acuso de recibo) ║ │
│ ║ Cliente ◄─── PSH,ACK ──── Servidor (respuesta) ║ │
│ ║ Cliente ──── ACK ────────► Servidor (acuso de recibo) ║ │
│ ╚═══════════════════════════════════════════════════════════╝ │
│ │ │
│ ▼ │
│ ╔═══════════════════════════════════════════════════════════╗ │
│ ║ FASE 3: CIERRE (4-way) ║ │
│ ║ ║ │
│ ║ Cliente ──── FIN,ACK ───► Servidor ║ │
│ ║ Cliente ◄─── ACK ──────── Servidor ║ │
│ ║ Cliente ◄─── FIN,ACK ──── Servidor ║ │
│ ║ Cliente ──── ACK ────────► Servidor ║ │
│ ╚═══════════════════════════════════════════════════════════╝ │
│ │
│ 🏁 FIN — Conexión terminada correctamente │
└─────────────────────────────────────────────────────────────────────┘
Volver a la tabla de contenidos
El handshake TLS – Añadir el candado
¿Cuándo interviene TLS?
TLS se sitúa entre el handshake TCP y los datos:
Paso 1: Handshake TCP → «Se abre la puerta»
Paso 2: Handshake TLS → «Se pone el candado + se verifica la identidad»
Paso 3: Datos cifrados → «Se conversa, pero nadie puede escuchar»
La analogía del banco
Imagine que quiere enviar un mensaje secreto a su banco:
┌─────────────────────────────────────────────────────────────────────┐
│ HANDSHAKE TLS (simplificado) │
│ │
│ Usted (Cliente) El Banco (Servidor) │
│ │
│ PASO 1 — ClientHello │
│ ──────────────────────────────────────► │
│ «¡Hola! Quisiera comunicarme en secreto. │
│ Aquí están los métodos de cifrado que conozco: │
│ AES-256, ChaCha20, etc.» │
│ │
│ PASO 2 — ServerHello + Certificado │
│ ◄────────────────────────────────────── │
│ «¡OK! Usaremos AES-256. │
│ Y aquí está mi CARNÉ DE IDENTIDAD (certificado): │
│ - Soy realmente "Banco Nacional" │
│ - Firmado por una autoridad de confianza (Let's Encrypt, etc.) │
│ - Válido hasta 2026-12-31» │
│ │
│ PASO 3 — Verificación (lado cliente) │
│ 🔍 Usted verifica el carné de identidad: │
│ ✅ ¿El nombre corresponde al sitio? │
│ ✅ ¿Firmado por una autoridad reconocida? │
│ ✅ ¿No está caducado? │
│ → Si todo está OK, se continúa. Si no = error de certificado. │
│ │
│ PASO 4 — Intercambio de claves │
│ ──────────────────────────────────────► │
│ 🔐 El cliente y el servidor se ponen de acuerdo en un │
│ SECRETO COMPARTIDO (¡sin enviarlo nunca en claro!) │
│ Método: Diffie-Hellman o similar. │
│ │
│ Analogía: imagine que cada uno mezcla un color │
│ de pintura en secreto. Intercambian el resultado, │
│ y ambos llegan al MISMO color final, │
│ pero alguien que observa NO puede adivinarlo. │
│ │
│ PASO 5 — Finished │
│ ◄─────────── (ambos lados) ──────────► │
│ «Tenemos las mismas claves secretas. │
│ ¡A partir de ahora, TODO está cifrado!» │
│ │
│ ═══════════════════════════════════════════════════════════════ │
│ 🔒 TÚNEL TLS ESTABLECIDO — ¡Toda la comunicación está cifrada! │
└─────────────────────────────────────────────────────────────────────┘
Preguntas frecuentes
¿Qué es un certificado?
Es la identidad digital del servidor. Contiene:
- El nombre del sitio (ej:
google.com) - La clave pública del servidor
- La firma de una autoridad de certificación (ej: Let's Encrypt, DigiCert)
- La fecha de expiración
Su navegador verifica todo esto automáticamente. Si algo no cuadra → 🔴 «Su conexión no es privada».
¿Qué es Diffie-Hellman?
Es un método matemático para que dos personas se pongan de acuerdo sobre un secreto común, incluso si alguien escucha todos sus mensajes.
Analogía de los colores de pintura:
Usted: elige en secreto AZUL 🔵
Banco: elige en secreto ROJO 🔴
Color base público: AMARILLO 🟡
Usted: mezcla AMARILLO + AZUL = VERDE 🟢 → envía el VERDE
Banco: mezcla AMARILLO + ROJO = NARANJA 🟠 → envía el NARANJA
Usted: recibe NARANJA + su AZUL secreto = MARRÓN 🟤
Banco: recibe VERDE + su ROJO secreto = MARRÓN 🟤
✅ ¡Ambos tienen el mismo color final (MARRÓN)!
❌ El espía solo ve VERDE y NARANJA... ¡no puede descubrir el MARRÓN!
En realidad, no son colores sino números grandes matemáticos, pero el principio es idéntico.
Volver a la tabla de contenidos
Ejemplo concreto: Abrir https://google.com
Esto es lo que ocurre realmente cuando usted escribe https://google.com en su navegador:
┌─────────────────────────────────────────────────────────────────────┐
│ SU PC (192.168.1.50) GOOGLE (142.250.80.46) │
│ │
│ ── PASO 1: RESOLUCIÓN DNS ────────────────────────────────── │
│ «¿Cuál es la IP de google.com?» │
│ → Respuesta DNS: 142.250.80.46 │
│ │
│ ── PASO 2: HANDSHAKE TCP ─────────────────────────────────── │
│ Paquete 1: [SYN] 192.168.1.50:54321 → 142.250.80.46:443 │
│ Paquete 2: [SYN,ACK] 142.250.80.46:443 → 192.168.1.50:54321 │
│ Paquete 3: [ACK] 192.168.1.50:54321 → 142.250.80.46:443 │
│ ✅ Conexión TCP establecida en el puerto 443 (HTTPS) │
│ │
│ ── PASO 3: HANDSHAKE TLS ─────────────────────────────────── │
│ Paquete 4: ClientHello → versiones TLS, algoritmos propuestos │
│ Paquete 5: ServerHello ← algoritmo elegido │
│ Paquete 6: Certificate ← certificado de google.com │
│ Paquete 7: Key Exchange ↔ intercambio Diffie-Hellman │
│ Paquete 8: Finished ↔ verificación de ambos lados │
│ 🔒 Túnel TLS establecido — todo está cifrado ahora │
│ │
│ ── PASO 4: DATOS CIFRADOS ────────────────────────────────── │
│ Paquete 9: [PSH,ACK] (cifrado) → GET / HTTP/1.1 │
│ (su solicitud para la página de inicio) │
│ Paquete 10: [ACK] ← acuse de recibo │
│ Paquete 11: [PSH,ACK] (cifrado) ← HTTP/1.1 200 OK + página HTML │
│ (la página de inicio de Google) │
│ Paquete 12: [ACK] → acuse de recibo │
│ 📄 ¡La página de Google se muestra en su navegador! │
│ │
│ ── PASO 5: CIERRE ────────────────────────────────────────── │
│ Paquete 13: [FIN,ACK] → «He terminado» │
│ Paquete 14: [FIN,ACK] ← «Yo también» │
│ Paquete 15: [ACK] → «OK, adiós» │
│ 🔌 Conexión cerrada │
└─────────────────────────────────────────────────────────────────────┘
Puerto 443 vs Puerto 80
- Puerto 80 = HTTP (no cifrado) → sin handshake TLS
- Puerto 443 = HTTPS (cifrado) → handshake TLS obligatorio
Por eso la URL https:// siempre utiliza el puerto 443 por defecto.
Volver a la tabla de contenidos
Lo que ve en Wireshark
Captura HTTP (puerto 80) – NO cifrado
┌──────┬────────────────────┬────────────────────┬──────────┬──────────────────────┐
│ No │ Source │ Destination │ Protocol │ Info │
├──────┼────────────────────┼────────────────────┼──────────┼──────────────────────┤
│ 1 │ 192.168.1.50 │ 93.184.216.34 │ TCP │ SYN │
│ 2 │ 93.184.216.34 │ 192.168.1.50 │ TCP │ SYN, ACK │
│ 3 │ 192.168.1.50 │ 93.184.216.34 │ TCP │ ACK │
│ 4 │ 192.168.1.50 │ 93.184.216.34 │ HTTP │ GET / HTTP/1.1 ⚠️ │
│ 5 │ 93.184.216.34 │ 192.168.1.50 │ TCP │ ACK │
│ 6 │ 93.184.216.34 │ 192.168.1.50 │ HTTP │ 200 OK ⚠️ │
└──────┴────────────────────┴────────────────────┴──────────┴──────────────────────┘
⚠️ ¡Se ve TODO en claro! La solicitud, la respuesta, el contenido de la página...
¡Cualquiera en la red puede leer estos datos!
Captura HTTPS (puerto 443) – Cifrado
┌──────┬────────────────────┬────────────────────┬──────────┬──────────────────────┐
│ No │ Source │ Destination │ Protocol │ Info │
├──────┼────────────────────┼────────────────────┼──────────┼──────────────────────┤
│ 1 │ 192.168.1.50 │ 142.250.80.46 │ TCP │ SYN │
│ 2 │ 142.250.80.46 │ 192.168.1.50 │ TCP │ SYN, ACK │
│ 3 │ 192.168.1.50 │ 142.250.80.46 │ TCP │ ACK │
│ 4 │ 192.168.1.50 │ 142.250.80.46 │ TLSv1.3 │ Client Hello │
│ 5 │ 142.250.80.46 │ 192.168.1.50 │ TLSv1.3 │ Server Hello │
│ 6 │ 142.250.80.46 │ 192.168.1.50 │ TLSv1.3 │ Certificate │
│ 7 │ 192.168.1.50 │ 142.250.80.46 │ TLSv1.3 │ Key Exchange │
│ 8 │ ... │ ... │ TLSv1.3 │ Finished │
│ 9 │ 192.168.1.50 │ 142.250.80.46 │ TLSv1.3 │ Application Data 🔒 │
│ 10 │ 142.250.80.46 │ 192.168.1.50 │ TLSv1.3 │ Application Data 🔒 │
└──────┴────────────────────┴────────────────────┴──────────┴──────────────────────┘
🔒 "Application Data" = datos cifrados. ¡No se puede leer el contenido!
Solo se ve que hay tráfico, pero no QUÉ se intercambia.
Lo que un atacante puede ver en HTTPS
Incluso con HTTPS, un atacante en la red puede ver:
- La dirección IP del servidor (ej: 142.250.80.46)
- El nombre del sitio (a través del campo SNI en ClientHello, ej:
google.com) - La cantidad de datos intercambiados
- El momento de la conexión
Pero NO puede ver:
- ❌ La URL completa (ej:
/search?q=mi+secreto) - ❌ El contenido de la página
- ❌ Las cookies, contraseñas, formularios
- ❌ Los datos enviados en ambos sentidos
Volver a la tabla de contenidos
Resumen final – La analogía completa
HTTP vs HTTPS en una imagen
┌─────────────────────────────────────────────────────────────────────┐
│ │
│ HTTP (puerto 80) HTTPS (puerto 443) │
│ │
│ 📞 Handshake TCP 📞 Handshake TCP │
│ (SYN → SYN,ACK → ACK) (SYN → SYN,ACK → ACK) │
│ │ │ │
│ │ 🔒 Handshake TLS │
│ │ (ClientHello → Certificate → Keys) │
│ │ │ │
│ ▼ ▼ │
│ 📦 Datos EN CLARO 📦 Datos CIFRADOS │
│ (todos pueden leer) (nadie puede leer) │
│ │ │ │
│ 👋 Cierre TCP 👋 Cierre TCP │
│ (FIN → ACK) (FIN → ACK) │
│ │
│ 🔴 ¡Peligroso! 🟢 ¡Seguro! │
└─────────────────────────────────────────────────────────────────────┘
El memo de las banderas TCP
┌──────────────────────────────────────────────────────────────────┐
│ MEMO DE LAS BANDERAS TCP │
│ │
│ SYN = 📞 «Quiero abrir una conexión» │
│ ACK = ✅ «¡Recibido!» │
│ PSH = 📦 «Aquí hay datos, procésalos de inmediato» │
│ FIN = 👋 «He terminado, adiós» │
│ RST = ❌ «¡Colgado a la fuerza!» │
│ │
│ SYN,ACK = 📞✅ «Acepto tu conexión + recibido» │
│ PSH,ACK = 📦✅ «Aquí hay datos + he recibido los tuyos» │
│ FIN,ACK = 👋✅ «Cierro + he recibido tus últimos mensajes» │
└──────────────────────────────────────────────────────────────────┘
El resumen en 5 frases
Resumen
- TCP abre la conexión con SYN / SYN-ACK / ACK (3-way handshake)
- TLS asegura la conexión con certificado + intercambio de claves (handshake TLS)
- PSH,ACK envía los datos reales (solicitudes HTTP, páginas web, etc.)
- FIN,ACK cierra correctamente la conexión
- ACK acompaña casi todo: es solo un «recibido» que permite no perder nada
Volver a la tabla de contenidos
TP Bonus creado el: Febrero 2026