TLS 1.3: la revolución 0-RTT y la eliminación de cifras obsoletas

TLS 1.2 permitía negociar combinaciones peligrosas: cifrado sin autenticación, modos CBC vulnerables a padding oracle, hashes débiles como SHA-1 y compresión TLS (causa directa de ataques como CRIME). TLS 1.3 eliminó todo eso: prohibió el intercambio de claves con RSA estático (obligando a Perfect Forward Secrecy mediante ECDHE), eliminó los modos CBC dejando únicamente esquemas AEAD (AES-GCM, AES-CCM, ChaCha20-Poly1305) y redujo la lista de suites de cifrado permitidas de cientos a solo cinco opciones ultraseguras.

En TLS 1.2, establecer una sesión cifrada requería dos intercambios completos de ida y vuelta (2-RTT) entre cliente y servidor antes de poder enviar el primer byte de datos HTTP. En TLS 1.3, el cliente asume una curva elíptica común (como X25519) y envía su oferta de clave pública directamente dentro del mensaje inicial ClientHello. El servidor responde con su ServerHello y su propia clave pública, completando el apretón de manos en un solo viaje (1-RTT) y comenzando a transmitir datos cifrados inmediatamente.

Si un usuario ya visitó un sitio web recientemente y tiene un ticket de sesión previo (Session Ticket / PSK), TLS 1.3 permite activar el modo 0-RTT (Early Data). En este modo, el cliente envía la primera petición HTTP cifrada (por ejemplo, GET /index.html) en el mismísimo primer paquete de red que sale de su tarjeta, antes incluso de que el servidor responda con su saludo. La latencia percibida por el usuario para reconectarse a un servidor web es exactamente cero.

El modo 0-RTT tiene un precio en seguridad: carece de secreto hacia adelante para esos primeros bytes y, lo más grave, es vulnerable a ataques de repetición (Replay). Un atacante situado en la red (como el administrador de un Wi-Fi público) puede capturar el paquete 0-RTT y reenviarlo 100 veces al servidor. Si ese paquete contiene una orden como POST /api/transferir?cantidad=500, el servidor podría procesar 100 transferencias duplicadas. Por esta razón, las especificaciones de seguridad exigen que 0-RTT solo se habilite para peticiones estrictamente idempotentes (como GET).