Protocolo TLS: funcionamiento, versiones y seguridad

Seguidores Online » Redes Sociales » Protocolo TLS: funcionamiento, versiones y seguridad

Si hoy te conectas a tu banco, subes archivos al trabajo o mandas un simple correo, lo normal es que todo ese tráfico vaya protegido con TLS, el protocolo que blinda la comunicación entre tu dispositivo y el servidor. Sin él, sería como mandar postales abiertas por la calle: cualquiera en el camino podría leerlas o modificarlas sin que te enterases.

En los últimos años TLS ha pasado de ser un añadido opcional a convertirse en una pieza clave de la seguridad en Internet: decide qué algoritmos se usan, cómo se intercambian las claves, qué versiones son seguras, cómo se autentican los sitios web y qué ataques se pueden frenar o no. Entenderlo, al menos a nivel conceptual, es casi obligatorio si administras sistemas, desarrollas aplicaciones o simplemente quieres saber qué hay detrás del candado del navegador.

Qué es TLS y qué problema resuelve

TLS, siglas de Transport Layer Security, es un protocolo criptográfico que se sitúa entre la capa de transporte (normalmente TCP) y los protocolos de aplicación (HTTP, SMTP, IMAP, FTP, SIP, etc.). Su misión es aportar confidencialidad, autenticación e integridad a los datos que viajan por la red entre un cliente y un servidor.

En la práctica, TLS permite que un navegador y un sitio web, un cliente de correo y su servidor o una app de mensajería y su backend se comuniquen a través de un “túnel” cifrado de forma que:

• Solo los extremos legítimos puedan leer el contenido (confidencialidad).
• El cliente pueda verificar que el servidor es quien dice ser (autenticación).
• Se detecten modificaciones o inyecciones en los datos (integridad).

Su antecesor directo fue SSL (Secure Sockets Layer), diseñado originalmente por Netscape. SSL 2.0 y SSL 3.0 estuvieron muy presentes en la primera web comercial, pero con el tiempo se descubrieron vulnerabilidades estructurales y de diseño que llevaron a su sustitución por la familia TLS. A día de hoy, SSL se considera obsoleto e inseguro, y la recomendación es desactivarlo completamente.

Evolución de SSL a TLS: versiones y cambios clave

Para entender por qué hoy se insiste tanto en usar TLS 1.2 o TLS 1.3, conviene repasar brevemente la cronología de SSL/TLS y el estado de seguridad de cada versión.

La secuencia histórica principal es:

• SSL 2.0 – 1995 (no seguro).
• SSL 3.0 – 1996 (no seguro).
• TLS 1.0 – 1999 (obsoleto, vulnerable a varios ataques como BEAST).
• TLS 1.1 – 2006 (obsoleto, mitigaba parte de los problemas de CBC).
• TLS 1.2 – 2008 (aún muy utilizado y considerado seguro con buena configuración).
• TLS 1.3 – 2018 (estado del arte en seguridad y eficiencia).

SSL 2.0 fue publicado con fallos graves: reutilizaba claves para cifrado y autenticación, tenía una construcción MAC débil basada en MD5, carecía de protección adecuada del handshake, era vulnerable a ataques de truncamiento y asumía un único servicio por IP, lo que chocaba con el hosting virtual. Por todo ello, acabó deshabilitado por defecto en navegadores modernos.

SSL 3.0 supuso un rediseño importante, introdujo SHA-1 y soporte más sólido para certificados, pero con el tiempo también se vio comprometido. Su derivación de claves dependía en exceso de MD5 y aparecieron ataques como POODLE, que explotaba el uso de CBC en SSL 3.0 tras forzar degradaciones de versión. Hoy no pasa ningún estándar serio de seguridad y está formalmente prohibido por RFC.

TLS 1.0 tomó como base SSL 3.0, corrigiendo parte del diseño y endureciendo la derivación de claves mezclando MD5 y SHA‑1 en su función pseudoaleatoria. Sin embargo, mantenía cifrado en modo CBC vulnerable a ataques como BEAST y otros problemas de diseño que hacen que ya no se recomiende su uso en entornos modernos.

Con TLS 1.1 se mejoró la protección de CBC introduciendo vectores de inicialización (IV) explícitos y ajustando el manejo de errores de relleno, además de registrar parámetros en IANA. Aun así, TLS 1.0 y 1.1 se consideran hoy versiones obsoletas y los principales navegadores dejaron de soportarlas alrededor de 2020.

TLS 1.2 supuso un salto de calidad: la PRF cambió a SHA‑256, se ampliaron las opciones de algoritmos de hash y firma, se extendió el soporte para modos autenticados (AEAD) como AES‑GCM y AES‑CCM y se definieron extensiones importantes de TLS. En 2011 se publicó además un RFC que prohibe negociar SSL 2.0 en sesiones TLS 1.2.

Por último, TLS 1.3 se diseñó a la luz de más de una década de ataques y malas implementaciones, con un claro objetivo: simplificar, eliminar lo inseguro y reducir la superficie de ataque. Elimina algoritmos considerados débiles, quita compresión, quita intercambio de claves RSA estático y suites no AEAD, introduce 0‑RTT opcional y reduce el handshake a la mínima expresión para mejorar la latencia.

Cómo funciona TLS por dentro: registros y handshake

El protocolo TLS se compone de varias subcapas. La más baja es el protocolo de registro (record layer), que define cómo se empaquetan los datos en registros con un tipo de contenido, una versión y una longitud, y cómo opcionalmente se comprimen, cifran y autentican mediante MAC o AEAD.

Sobre la capa de registro se apoyan varios subprotocolos, identificados por el campo content_type:

• Handshake (22): negociación de parámetros de seguridad.
• ChangeCipherSpec (20): señal de cambio de contexto criptográfico.
• Alert (21): notificación de errores o eventos.
• Application Data (23): datos de aplicación (HTTP, IMAP, etc.).
• Heartbeat (24): mensajes keep-alive en implementaciones que lo soportan.

Un registro TLS incluye, a grandes rasgos: tipo de contenido, versión, longitud, datos de protocolo, MAC y relleno (este último solo en cifrados por bloques antes de AEAD). La longitud máxima típica ronda los 16 KiB de carga útil.

En el arranque de la conexión, el tipo de contenido más relevante es el del protocolo de handshake, que define mensajes como ClientHello, ServerHello, Certificate, ServerKeyExchange, CertificateRequest, ServerHelloDone, ClientKeyExchange, CertificateVerify y Finished. Cada mensaje lleva un tipo y una longitud de datos específicos de handshake.

Handshake TLS típico: establecimiento de la sesión segura

El famoso “apretón de manos” es la fase donde cliente y servidor acuerdan versión, algoritmos, claves y autenticación. Hay varios flujos posibles; el más común es aquel en el que solo el servidor se autentica mediante certificado.

En un handshake completo con autenticación solo del servidor, el flujo simplificado es:

1. ClientHello: el cliente envía la versión máxima de TLS que soporta, un valor aleatorio, la lista de suites de cifrado y métodos de compresión que acepta, y opcionalmente un identificador de sesión si intenta reanudar una sesión anterior.
2. ServerHello: el servidor responde indicando la versión elegida (la más alta común), otro valor aleatorio, la suite de cifrado y compresión seleccionadas y, si procede, un ID de sesión.
3. Certificate: el servidor envía su certificado X.509 (o cadena) para que el cliente pueda verificar su identidad, salvo en algunos conjuntos de cifrado muy específicos donde podría omitirse.
4. ServerKeyExchange (si la suite lo requiere, por ejemplo DHE/ECDHE): el servidor envía parámetros de intercambio de claves firmados con su clave privada.
5. ServerHelloDone: indica que el servidor ha terminado su parte del handshake.
6. ClientKeyExchange: el cliente envía el material necesario para derivar el secreto compartido (por ejemplo, una PreMasterSecret cifrada con la clave pública del servidor o su parte del intercambio Diffie‑Hellman).
7. Derivación de claves: ambas partes usan la PreMasterSecret y los valores aleatorios para generar el master secret, del que se derivan las claves de cifrado, de MAC y los vectores de inicialización mediante una función pseudoaleatoria definida en TLS.
8. ChangeCipherSpec (cliente) y Finished (cliente): el cliente avisa de que a partir de ese punto usará el nuevo contexto criptográfico y envía un mensaje Finished cifrado y autenticado, que contiene un hash de todos los mensajes de handshake vistos.
9. ChangeCipherSpec (servidor) y Finished (servidor): el servidor hace lo mismo en sentido inverso.

Si el servidor también quiere autenticar al cliente, envía un CertificateRequest tras su certificado. El cliente responde con su propio certificado, un ClientKeyExchange y un mensaje CertificateVerify que firma el historial de handshake con su clave privada, demostrando que realmente la controla.

Una vez intercambiados y verificados los mensajes Finished, el handshake se da por completado y los mensajes posteriores de tipo contenido 23 pasan a ser datos de aplicación cifrados y autenticados.

Reanudación de sesiones: rendimiento y tickets TLS

Las operaciones de clave pública (RSA, ECDSA, intercambio de claves DH/ECDH) son caras computacionalmente, sobre todo en servidores con mucho tráfico. Para evitar repetir un handshake completo en cada conexión, TLS ofrece mecanismos de reanudación de sesión.

El más clásico se basa en los IDs de sesión. En un handshake completo, el servidor asigna un identificador y asocia a ese ID el master secret y demás parámetros. Cuando el cliente se conecta de nuevo, incluye ese ID en su ClientHello. Si el servidor aún recuerda esa sesión, responde reutilizando el mismo ID y ambos reanudan la sesión directamente, saltándose parte del intercambio de claves y autenticación.

El RFC 5077 introduce los tickets de sesión: en lugar de almacenar estado en el servidor, éste cifra y autentica el contexto de sesión (incluido el master secret) y se lo entrega al cliente en un ticket. Más tarde, el cliente presenta el ticket y el servidor lo descifra y valida para reanudar. Es muy eficiente, pero hay que gestionar con cuidado las claves que protegen esos tickets, porque afectan al forward secrecy y pueden quedar “más débiles” que la propia sesión TLS si se usan durante demasiado tiempo.

Algoritmos criptográficos en TLS: claves, cifrado e integridad

Una de las grandes fuerzas (y también complejidades) de TLS es su flexibilidad en algoritmos. Durante el handshake se negocia una “cipher suite” que combina:

• Un método de autenticación e intercambio de claves (por ejemplo, RSA, DHE-RSA, ECDHE-ECDSA, PSK…).
• Un algoritmo de cifrado simétrico (AES GCM, AES CBC, ChaCha20‑Poly1305, Camellia, ARIA, etc.).
• Un mecanismo de integridad: HMAC con MD5/SHA‑1/SHA‑256/384 o AEAD integrado (GCM, CCM, Poly1305).

En versiones anteriores a TLS 1.3 existía una larga lista de combinaciones, incluyendo algoritmos hoy desaconsejados o prohibidos como RC4, 3DES, DES, IDEA, RC2 o suites export de baja longitud de clave. También hay soporte para algoritmos regionales como GOST en algunos entornos.

Para integridad, TLS usó tradicionalmente HMAC encima del cifrado (MAC‑then‑Encrypt) con MD5 o SHA‑1. Las suites AEAD modernas integran autenticación y cifrado en un solo paso, evitando problemas de padding oracle y simplificando el diseño. TLS 1.2 añadió soporte oficial para AEAD, y TLS 1.3 directamente solo permite suites AEAD seguras como AES‑GCM o ChaCha20‑Poly1305.

Forward secrecy: por qué importa tanto Diffie‑Hellman efímero

La propiedad de secreto perfecto hacia adelante (forward secrecy) garantiza que, aunque alguien robe la clave privada de un servidor en el futuro, no pueda descifrar sesiones pasadas que haya capturado y almacenado. Sin esta propiedad, basta comprometer la clave del servidor para desbloquear años de tráfico grabado.

En TLS se consigue forward secrecy utilizando intercambios de claves efímeros como DHE o, especialmente, ECDHE. En estas suites, cada sesión genera claves temporales distintas, de modo que incluso con la clave del servidor comprometida, el atacante no puede retro‑calcular las claves de sesión anteriores.

En cambio, suites como TLS_RSA sin Diffie‑Hellman efímero no ofrecen esta garantía: la PreMasterSecret se cifra directamente con la clave pública del servidor, de modo que quien obtenga la privada puede descifrar todas las PreMasterSecret grabadas y, por extensión, todas las sesiones.

Grandes proveedores como Google o Twitter llevan años aplicando forward secrecy por defecto en HTTPS, y cada vez más sitios se suman.

No obstante, la configuración real depende tanto del servidor como del cliente, y características como los tickets de sesión mal gestionados pueden debilitar este modelo si se usan claves de ticket de larga duración.

Usos habituales de TLS: mucho más que HTTPS

La cara visible de TLS para la mayoría de usuarios es el candado del navegador y el prefijo HTTPS en la URL. HTTP sobre TLS evita que contraseñas seguras, datos personales o información de pago viajen en claro y se ha convertido en requisito casi obligatorio para SEO, confianza del usuario y cumplimiento normativo.

Otros muchos protocolos y aplicaciones están protegidos por TLS:

• Correo electrónico: TLS se usa con SMTP, IMAP y POP3, tanto mediante puertos seguros dedicados como a través de extensiones STARTTLS que “elevan” conexiones en claro a seguras.
• VoIP y señalización: protocolos como SIP utilizan TLS para asegurar señalización y, en algunos casos, para soporte de SRTP en medios.
• Mensajería instantánea y apps móviles: gran parte de los chats, notificaciones push y APIs REST usan TLS como capa de seguridad transparente a la aplicación.
• FTP seguro (FTPS): variantes de FTP encapsuladas en TLS para transferencias de archivos sensibles.
• VPN tipo SSL/TLS: soluciones como OpenVPN crean túneles completos cifrados sobre TLS, permitiendo montar VPN sin recurrir a IPsec.
• Autenticación EAP‑TLS: en redes WiFi empresariales, EAP‑TLS se apoya en TLS para autenticación robusta mediante certificados.

Aunque muchos sistemas modernos integran TLS de serie, todavía hay software heredado que no lo soporta nativamente. En esos casos se recurre a wrappers como Stunnel, que actúan como puente TLS para aplicaciones antiguas, si bien IETF lleva años recomendando que los protocolos de aplicación incluyan mecanismos estándar de actualización a TLS para evitar estos parches externos.

Certificados, PKI y fijación: confianza en la identidad

Para que el cliente pueda saber que realmente habla con el servidor correcto, TLS se apoya en una infraestructura de clave pública (PKI) basada en certificados X.509 emitidos por autoridades de certificación (CA).

Un certificado de servidor típico incluye el nombre de dominio (CN/SAN), la clave pública, el emisor, el periodo de validez y el uso permitido. Navegadores y sistemas operativos mantienen un almacén de CAs raíz de confianza; si la cadena que presenta el servidor lleva hasta una de esas raíces y las comprobaciones de validez pasan, el certificado se considera válido.

Existen varias clases de certificados según el nivel de validación:

• DV (Domain Validation): solo se comprueba el control sobre el dominio.
• OV (Organization Validation): se verifica también la existencia de la organización.
• EV (Extended Validation): aplica un proceso de validación más estricto sobre la identidad de la entidad.
• SAN / multidominio y wildcard: permiten cubrir varios dominios o subdominios con un único certificado.

Para cerrar el círculo frente a ataques de hombre en el medio más sofisticados, algunas aplicaciones implementan fijación de certificado o de clave pública (certificate pinning): en lugar de fiarse solo de la PKI general, almacenan un certificado o hash concreto y rechazan cualquier otro, aunque la PKI diga que es válido. También existen proyectos como Perspectivas, que usan “notarios” distribuidos para detectar certificados distintos vistos desde diferentes puntos de la red, una señal potencial de MITM local.

Principales vulnerabilidades y ataques contra SSL/TLS

Aunque TLS está diseñado con múltiples capas de defensa, la historia demuestra que el peligro suele estar en los detalles: versiones antiguas, suites débiles, APIs mal diseñadas o implementaciones inseguras.

Entre los ataques más relevantes que han marcado la evolución del protocolo y las recomendaciones actuales destacan:

• BEAST (2011): explotaba vulnerabilidades en el uso de CBC en TLS 1.0. Se mitiga usando TLS 1.1/1.2, AEAD o cambios en el envío de bloques por parte del cliente.
• CRIME: se aprovechaba de la compresión de datos para inferir contenido secreto como cookies, combinando observación del tamaño comprimido con inyecciones controladas.
• Lucky Thirteen y padding oracles: atacaban detalles del padding en modos CBC. Llevaron a recomendaciones como Encrypt‑then‑MAC (RFC 7366) y a favorecer AEAD.
• POODLE (2014): sacaba partido del modo CBC en SSL 3.0 tras forzar una degradación de protocolo. Motivó la desactivación definitiva de SSL 3.0.
• Ataques contra RC4: durante un tiempo se sugirió RC4 para esquivar BEAST, pero nuevos trabajos demostraron que RC4 en TLS es completamente rompible, y acabó prohibido por RFC.
• Ataques de renegociación insegura: una vulnerabilidad en la forma de renegociar permitía inyectar texto plano al principio de sesiones HTTPS. Se corrigió con la extensión de indicación de renegociación (RFC 5746).
• Ataques de truncamiento TLS: bloquean la petición de logout y fuerzan un cierre de TCP, haciendo creer al usuario que se ha cerrado sesión cuando en realidad el servidor la mantiene abierta.
• Heartbleed: no era un fallo del protocolo, sino de la implementación en OpenSSL (extensión Heartbeat). Permitía leer memoria del servidor, exponiendo claves privadas, datos de sesión y otros secretos.

A esto se suman errores de implementación clásicos: no comprobar campos de certificados (por ejemplo, nombres con byte nulo), aceptar certificados de hoja como CAs, manejar mal códigos de error, permitir degradaciones de versión silenciosas o exponer suites de cifrado export. Muchas bibliotecas históricas de SSL/TLS ofrecían APIs de muy bajo nivel, lo que llevó a miles de aplicaciones a usar TLS “mal” sin que sus desarrolladores fuesen plenamente conscientes.

Buenas prácticas al desplegar TLS hoy en día

Con todo lo anterior, la receta actual para tener una configuración TLS razonablemente sólida en un servidor pasa por seguir unas pautas bastante claras:

En primer lugar, es recomendable habilitar solo TLS 1.2 y TLS 1.3, desactivando SSL 2.0, SSL 3.0, TLS 1.0 y TLS 1.1. Los principales navegadores ya no confían en estas versiones antiguas y mantenerlas abiertas solo sirve para permitir degradaciones y ataques conocidos.

En segundo lugar, conviene limitar las suites de cifrado a algoritmos fuertes: AES‑GCM, AES‑CCM o ChaCha20‑Poly1305, siempre con intercambio de claves efímero (ECDHE/DHE) y sin RC4, 3DES ni cifras export. La mayoría de guías actuales publican listas concretas recomendadas que puedes adaptar a tu servidor web o proxy.

Un tercer punto clave es usar certificados válidos, actualizados y emitidos por CAs de confianza, con claves de tamaño adecuado (2048 bits RSA como mínimo, ECC cuando sea posible) y renovaciones automatizadas. Dejar caducar un certificado provoca alertas de seguridad en los navegadores y mina la confianza de los usuarios.

Además, merece la pena configurar correctamente el servidor HTTP para forzar HTTPS con redirecciones adecuadas, activar HSTS si procede y evitar exponer versiones en claro del sitio que puedan dar lugar a contenido duplicado o a usuarios despistados navegando sin cifrado.

Por último, es vital monitorizar la configuración y revisar periódicamente con herramientas de análisis de TLS: comprueban versiones soportadas, suites activas, soporte de SNI, compatibilidad con forward secrecy, presencia de vulnerabilidades conocidas y más. La seguridad TLS no es algo que configures una sola vez y olvides; el ecosistema evoluciona y conviene ir ajustando la configuración con el tiempo.

Visto todo el recorrido, se entiende por qué el protocolo TLS es hoy uno de los pilares silenciosos de Internet: combina matemáticas avanzadas, estándares abiertos y un largo historial de parches y mejoras para conseguir que la mayoría de nuestras comunicaciones digitales viajen cifradas, autenticadas y con garantías razonables de integridad, siempre que tanto servidores como clientes se mantengan al día y se configuren con cabeza.