TLS — la web cifrada

¿Quién protege tu candado?

Cuando abres https://banco.com, tres cosas tienen que pasar antes de que tu navegador y el servidor se intercambien un solo byte de datos.

Autenticación: ¿el servidor es realmente quien dice ser, o es un atacante en medio haciéndose pasar por el banco? Acuerdo de clave: ¿cómo establecen una clave secreta compartida sin que nadie escuchando pueda obtenerla, sabiendo que todo el tráfico es público? Cifrado del tráfico: una vez tienen la clave, ¿cómo cifran lo que se envían sin comprometerse?

TLS (Transport Layer Security) es el protocolo que resuelve los tres problemas a la vez. Es la capa invisible debajo de HTTPS, IMAPS, SMTPS y prácticamente cualquier "S" que veas en un protocolo de Internet. El atacante a derrotar es el MitM — Man-in-the-Middle — alguien con capacidad de interceptar el tráfico: desde otro usuario en la misma Wi-Fi del aeropuerto hasta un ISP malicioso o un Estado. TLS tiene que funcionar incluso asumiendo que el atacante ve absolutamente todo lo que pasa por la red.

De SSL 2.0 a TLS 1.3 + PQC

30 años de iteraciones, vulnerabilidades con nombre propio y mejoras incrementales hasta llegar al handshake actual. La línea es roja al principio (todo lo que ya está roto) y se va volviendo cuántica al final.

• 1995
  SSL 2.0 · Netscape
  Roto desde el día 1, con vulnerabilidades graves de diseño. Deprecado oficialmente en 2011.
• 1996
  SSL 3.0
  Mejor diseño, pero también caería con el ataque POODLE en 2014. Deprecado.
• 1999
  TLS 1.0 · RFC 2246
  Primera versión bajo el paraguas IETF. Vulnerable a BEAST (2011). Deprecado oficialmente en 2021.
• 2006
  TLS 1.1
  Mitiga BEAST. Deprecado en 2021 junto con 1.0.
• 2008
  TLS 1.2 · RFC 5246
  El caballo de batalla durante una década. Aún se considera aceptable si está bien configurado (sin RC4, sin CBC, sin SHA-1).
• 2018
  TLS 1.3 · RFC 8446
  Reescritura profunda: handshake en 1-RTT (o 0-RTT), elimina algoritmos rotos (RC4, MD5, SHA-1, RSA key exchange, CBC), perfect forward secrecy obligatorio.
• 2024
  NIST FIPS 203/204/205
  Se publican los primeros estándares post-cuánticos: ML-KEM, ML-DSA y SLH-DSA. Empieza la migración real.
• 2024 →
  TLS 1.3 + ML-KEM en producción
  Chrome y Cloudflare habilitan X25519MLKEM768 por defecto. Es probablemente lo único PQC que ya estás usando hoy sin saberlo.

Lo que hoy se considera "bien hecho"

Sin meternos todavía en post-cuántica, esto es lo que en 2026 se considera una configuración TLS sólida. Es la línea base contra la que vamos a comparar cuando llegue el momento de hablar de Shor.

Esto es lo que hoy se considera seguro. Y aquí viene el problema.

Qué rompe Shor, qué debilita Grover

TLS clásico se apoya en dos problemas matemáticos difíciles: el logaritmo discreto en curvas elípticas (ECDHE para acuerdo de clave, ECDSA para firmas) y la factorización de enteros grandes (RSA, tanto en key exchange — donde aún se use — como en firmas). Ambos son fáciles para un ordenador cuántico suficientemente grande ejecutando el algoritmo de Shor.

Esto es lo que sobrevive y lo que no:

El cifrado simétrico aguanta razonablemente bien con tamaños de clave de 256 bits. El problema serio está en el key exchange y en las firmas, que son asimétricos y se apoyan precisamente en los problemas que Shor sabe resolver.

Harvest Now, Decrypt Later. Atacantes con capacidad estatal están capturando tráfico TLS cifrado ahora mismo y guardándolo. Cuando llegue Q-Day, descifrarán retroactivamente todo lo que tenga interés.

Cualquier dato con valor más allá de ~10 años está ya en riesgo hoy si viaja sobre TLS clásico — historias clínicas, secretos industriales, comunicaciones diplomáticas, propiedad intelectual. Por eso la migración no es algo de 2030, es algo de ahora.

ML-KEM, ML-DSA y los híbridos

En agosto de 2024, NIST publicó los primeros estándares post-cuánticos. Tres familias, tres usos:

Estado real en TLS 1.3

¿Por qué híbrido y no PQC puro?

Porque ML-KEM es nuevo. Lleva relativamente poco tiempo siendo escrutado por la comunidad criptográfica. Si apareciese un ataque clásico contra ML-KEM (improbable pero posible), el componente X25519 del híbrido seguiría protegiendo la sesión.

Híbrido = seguro contra el atacante cuántico y contra fallos en el propio PQC.

Es la postura sensata para los próximos 5-10 años: ganamos resistencia cuántica sin apostar todo a un algoritmo todavía joven. Cuando la comunidad lleve más años martilleando ML-KEM sin encontrar grietas, se podrá pasar a PQC puro.

Los 6 criterios de la auditoría

Estos son los criterios que aparecerán en el examen final para esta estación. Cada uno se mapea a un nivel de madurez. Spoiler: ya sabes lo que se va a preguntar.

Mapeo a badge de la estación: 0–30 Classical · 31–55 Hybrid-Ready · 56–75 Quantum-Safe · 76–90 Q-Day Proof. Cada respuesta "no lo sé" resta del máximo posible y aparece en el reporte como un área a investigar — no penaliza, pero tampoco te da puntos por no saber.