🔓 http://qubito.es NO SEGURO
🌐
Paso 0
DNS + TCP — Encontrar al servidor

Escribes qubito.es en el navegador. Antes de hablar de cifrado, hay que encontrar al servidor. Tu navegador pregunta al DNS (la "guía telefónica" de internet) cuál es la dirección IP del servidor. Luego establece una conexión TCP (el famoso "three-way handshake"):

💻 Cliente
🖥️ Servidor
SYN "Hola, quiero conectarme" (seq=0)
SYN-ACK "OK, te escucho" (seq=0, ack=1)
ACK "Perfecto, empecemos" (ack=1)
✓ Conexión TCP establecida — puerto 443 (HTTPS)
🤝
Paso 1 · TLS Handshake
Client Hello — "¿Qué cifrados hablas?"

La conexión TCP está lista, pero es texto plano — cualquiera podría leerla. Ahora empieza el TLS Handshake. Tu navegador envía un "Client Hello" con la lista de algoritmos criptográficos que soporta y un número aleatorio:

💻 Cliente
🖥️ Servidor
CLIENT HELLO
TLS Version: TLS 1.3
Client Random: 7a3f...c8e1 (32 bytes)
Cipher Suites:
  TLS_AES_256_GCM_SHA384 AES-256
  TLS_AES_128_GCM_SHA256 AES-128
  TLS_CHACHA20_POLY1305_SHA256 ChaCha20
Key Exchange:
  x25519 ECDHE
  secp256r1 ECDHE
SNI: qubito.es

El navegador ofrece sus opciones, como en un menú. ECDHE es cifrado asimétrico (clave pública/privada) y AES/ChaCha20 es cifrado simétrico (misma clave en ambos lados). Veremos por qué necesitamos los dos.

📜
Paso 2 · Servidor responde
Server Hello + Certificado

El servidor elige los algoritmos (de la lista del cliente) y envía su certificado digital. Este certificado es la "prueba de identidad" del servidor, firmada por una Autoridad de Certificación (CA) en la que tu navegador confía.

💻 Cliente
🖥️ Servidor
SERVER HELLO
Selected Cipher: TLS_AES_256_GCM_SHA384
Key Exchange: x25519 (ECDHE)
Server Random: b2d4...f7a9 (32 bytes)
🛡️ CERTIFICADO X.509
Subject: CN=qubito.es
Issuer: Let's Encrypt Authority X3
Valid: 2025-12-01 → 2026-02-28
Public Key: EC P-256 (64 bytes)
Signature: ECDSA with SHA-256
Fingerprint: A3:8B:... (SHA-256)

Tu navegador verifica la cadena de confianza: ¿Está firmado por una CA conocida? ¿Ha expirado? ¿El dominio coincide? Si todo es correcto, confía en la clave pública del servidor. Esta verificación usa criptografía asimétrica — firma digital con ECDSA.

🔑
Paso 3 · La magia del cifrado asimétrico
Key Exchange — ECDHE (Diffie-Hellman en Curvas Elípticas)

Aquí está el truco genial: cliente y servidor necesitan una clave secreta compartida, pero no pueden enviarla directamente porque alguien podría interceptarla. Solución: Diffie-Hellman permite que ambos generen la misma clave secreta sin que ninguno la envíe.

🔑
Clave pública Cliente
04:a1:3f:b7:...
🔑
Clave pública Servidor
04:c2:8e:d4:...

Cada lado tiene un par de claves (pública + privada). Se intercambian solo las públicas. Luego cada uno combina su clave privada con la pública del otro y — gracias a las matemáticas de las curvas elípticas — ambos obtienen el mismo resultado: el Pre-Master Secret.

PRIVADA CLIENTE
🔒 a1f3...
+
PÚBLICA SERVIDOR
🔑 c28e...
=
PRE-MASTER SECRET
🤝 d7b2...
¿POR QUÉ ECDHE Y NO RSA?

ECDHE proporciona Forward Secrecy:
→ Se generan claves efímeras (nuevas en cada sesión)
→ Si alguien roba la clave privada del servidor en el futuro,
  NO puede descifrar sesiones pasadas

RSA key exchange (legacy, ya no se usa en TLS 1.3):
→ El cliente cifra el secret con la clave pública del server
→ Si roban la clave privada → TODAS las sesiones pasadas expuestas
→ Sin Forward Secrecy → eliminado de TLS 1.3
Paso 4 · Del asimétrico al simétrico
Derivación de Clave de Sesión (AES-256-GCM)

Ya tenemos el Pre-Master Secret. Pero no lo usamos directamente — se pasa por una función de derivación (HKDF) junto con los valores aleatorios que se intercambiaron, para generar las claves de sesión finales. A partir de aquí, todo el tráfico se cifra con AES-256-GCM — cifrado simétrico.

PRE-MASTER
🤝 d7b2...
+
HKDF-SHA384
⚙️ randoms
SESSION KEY
🔐 AES-256

¿Por qué no usar cifrado asimétrico para todo? Porque es ~1000x más lento que el simétrico. El asimétrico (ECDHE) se usa solo para el intercambio de claves — un momento puntual. El simétrico (AES) se usa para cifrar los datos reales a toda velocidad.

COMPARATIVA DE VELOCIDAD

RSA-2048 cifrado: ~1.000 ops/seg
ECDHE P-256: ~10.000 ops/seg
AES-256-GCM: ~4.000.000.000 bytes/seg (4 GB/s) ← ¡este!

Por eso el handshake (asimétrico) dura ~50ms
y luego el tráfico (simétrico) fluye sin retardo perceptible.
🔐
Clave de sesión
AES-256-GCM
e4:9a:2b:ff:...
(32 bytes = 256 bits)
🔒
Paso 5 · Conexión segura
Tráfico Cifrado — AES-256-GCM en acción

¡Handshake completado! Ahora todo lo que envías y recibes está cifrado con AES-256-GCM. Veamos cómo se ve un mensaje antes y después del cifrado:

TEXTO PLANO
GET /index.html
→ 🔐 →
CIFRADO (AES-256-GCM)
a7:3f:b2:91:e4:...

AES (Advanced Encryption Standard) opera sobre bloques de 128 bits (16 bytes). La clave de 256 bits se expande en 14 "round keys", y cada bloque pasa por 14 rondas de sustitución, permutación y mezcla. Aquí tienes una visualización simplificada de un bloque de 4×4 bytes:

PLAINTEXT
CIPHERTEXT
AES-256-GCM — DETALLE TÉCNICO

Modo: GCM (Galois/Counter Mode)
→ Cifrado autenticado: cifra Y verifica integridad
→ Genera un TAG de autenticación (GMAC) de 128 bits
→ Si alguien modifica un byte, el TAG falla → paquete descartado

Tamaño de bloque: 128 bits
Clave: 256 bits (2²⁵⁶ combinaciones posibles)
Rondas: 14 (SubBytes → ShiftRows → MixColumns → AddRoundKey)
IV/Nonce: 96 bits (único por paquete)
Conexión completa
🔒 qubito.es — Conexión Segura
🔒 HTTPS Activo

Todo este proceso ocurre en ~50-100 milisegundos. Tu navegador acaba de:

1. Resolver DNS y establecer TCP (three-way handshake)
2. Enviar Client Hello con cipher suites soportadas
3. Verificar el certificado X.509 del servidor (cadena de confianza)
4. Intercambiar claves con ECDHE (cifrado asimétrico) → Forward Secrecy
5. Derivar clave de sesión con HKDF
6. Cifrar todo el tráfico con AES-256-GCM (cifrado simétrico)
🔑 ECDHE x25519 — Intercambio de claves + 🔐 AES-256-GCM — Cifrado de datos
⚠️
Amenaza cuántica: El intercambio de claves ECDHE (paso 3) se basa en la dificultad del "problema del logaritmo discreto en curvas elípticas". Un ordenador cuántico con suficientes qubits podría resolverlo con el algoritmo de Shor. Por eso la industria ya está migrando a criptografía post-cuántica (ML-KEM/Kyber). AES-256, en cambio, solo pierde la mitad de su seguridad efectiva (de 256 a 128 bits por Grover) — sigue siendo seguro. → Ver módulo de Shor
← Volver al curso