TLS y Canales Seguros

Transport Layer Security (TLS) es el protocolo que asegura la mayoría de las comunicaciones por internet, combinando el intercambio de claves autenticado y el cifrado autenticado para crear un canal confidencial y protegido contra la integridad entre dos puntos finales.

Definition

Un protocolo de canal seguro como TLS establece, entre dos partes, una sesión que garantiza la confidencialidad, integridad y autenticación de todos los datos intercambiados, mediante la realización de un intercambio de claves autenticado seguido de un cifrado autenticado del tráfico.

Scope

Este tema cubre los protocolos de canal seguro, con TLS como ejemplo central: el "handshake" que autentica el servidor (y opcionalmente el cliente) y establece las claves de sesión, la capa de registro que proporciona cifrado autenticado, secreto hacia adelante y protección contra la degradación, y las lecciones de ataques históricos. Aborda cómo los bloques criptográficos se ensamblan en un protocolo implementado. Excluye la infraestructura de certificados (PKI) y las primitivas individuales, que se tratan en temas relacionados.

Core questions

• ¿Cómo autentica el "handshake" de TLS al servidor y acuerda las claves de sesión?
• ¿Cómo protege la capa de registro cada mensaje con cifrado autenticado?
• ¿Cómo se logra el secreto hacia adelante y por qué es importante para el tráfico grabado?
• ¿Cómo se previenen los ataques de degradación y renegociación?
• ¿Qué enseñaron los ataques históricos (BEAST, POODLE, Heartbleed) sobre el diseño de protocolos e implementaciones?

Key concepts

• "handshake" de TLS
• capa de registro
• cifrado autenticado (AEAD)
• intercambio de claves efímero (ECDHE)
• secreto hacia adelante
• autenticación de servidor y cliente
• ataques de degradación y renegociación
• reanudación de sesión
• negociación de suite de cifrado

Key theories

Protocolo de "handshake" más registro

TLS separa un "handshake" de intercambio de claves autenticado —que verifica la identidad mediante certificados y deriva claves de sesión— de una capa de registro que cifra y autentica los datos de la aplicación con esas claves, componiendo limpiamente la autenticación, el acuerdo de claves y la protección masiva.

Secreto hacia adelante y protección contra la degradación

TLS 1.3 exige Diffie-Hellman efímero (de curva elíptica) para el secreto hacia adelante y vincula la transcripción del "handshake" al programa de claves para que un atacante activo no pueda forzar una degradación a parámetros más débiles sin ser detectado.

Mechanisms

En TLS 1.3, el cliente envía sus partes de intercambio de claves y parámetros soportados; el servidor responde con su propia parte efímera de Diffie-Hellman, certificado y una firma sobre la transcripción del "handshake", y ambos derivan claves de sesión a través de una función de derivación de claves (HKDF). La capa de registro protege entonces todos los datos con un cifrado AEAD (como AES-GCM o ChaCha20-Poly1305). La transcripción se autentica para evitar manipulaciones o degradaciones, y el "handshake" se completa en un solo viaje de ida y vuelta, con reanudación opcional de cero viajes de ida y vuelta.

Clinical relevance

TLS asegura la inmensa mayoría del tráfico de internet: HTTPS para la web, transporte seguro de correo electrónico, APIs, VPNs y mensajería, todos funcionan sobre él. Su corrección determina directamente si las contraseñas, los pagos y los datos personales están protegidos de los atacantes de la red. La migración de SSL/TLS temprano defectuoso a TLS 1.3 —y el análisis que la acompañó— es un modelo para la evolución de protocolos bajo presión del mundo real.

Evidence & guidelines

TLS 1.3 está estandarizado en RFC 8446 y se recomienda; SSL 3.0, TLS 1.0 y TLS 1.1 están obsoletos (RFC 8996). NIST SP 800-52 proporciona orientación de configuración. TLS 1.3 se desarrolló con un extenso análisis formal, eliminando debilidades heredadas (intercambio de claves RSA estático, modo CBC, renegociación) que permitieron ataques anteriores como BEAST, POODLE y el fallo de implementación Heartbleed.

History

Netscape creó SSL en 1994-1995; SSL 3.0 fue rediseñado por el IETF como TLS 1.0 (1999) y refinado hasta TLS 1.2 (2008). Una década de ataques —BEAST, CRIME, POODLE, el error de implementación Heartbleed, Logjam y FREAK— expuso debilidades en los modos heredados y el manejo de la degradación. TLS 1.3 (RFC 8446, 2018) fue un rediseño importante con secreto hacia adelante obligatorio, un "handshake" más rápido y análisis de seguridad formal.

Key figures

• Eric Rescorla
• Hugo Krawczyk
• Kenny Paterson
• Taher ElGamal

Seminal works

• rfc8446
• stallings2017
• katz2020

Frequently asked questions

¿Cuál es la diferencia entre SSL y TLS?

TLS es el sucesor de SSL. SSL (versiones 2.0 y 3.0) está obsoleto e es inseguro; 'SSL' persiste como un término coloquial, pero todas las conexiones web seguras actuales utilizan TLS, siendo TLS 1.3 la versión moderna.

¿Me protege TLS de un sitio web malicioso?

TLS solo garantiza que se tiene un canal confidencial y autenticado con el servidor nombrado en el certificado; confirma que se está hablando con ese dominio, no que el dominio sea digno de confianza. Un sitio de "phishing" puede servir un certificado válido para su propio dominio (similar), por lo que TLS no garantiza la honestidad del sitio.