Versiones de TLS, conjuntos de cifrado y secreto perfecto hacia adelante

TLS (Transport Layer Security) es el protocolo criptográfico que protege la mayoría de las comunicaciones de internet: HTTPS, SMTPS, IMAPS, LDAPS y las VPN dependen de TLS. TLS proporciona tres propiedades de seguridad: confidencialidad (el cifrado impide la interceptación), integridad (el MAC impide la manipulación) y autenticación (los certificados verifican la identidad del servidor). TLS evolucionó a partir de SSL (Secure Sockets Layer), que ahora está obsoleto. Las versiones actuales son TLS 1.2 (ampliamente implementada) y TLS 1.3 (más rápida y segura, recomendada para todas las implementaciones nuevas).

TLS ha pasado por varias versiones, algunas de las cuales contenían vulnerabilidades críticas. SSL 2.0/3.0: obsoletas y vulnerables a los ataques POODLE y DROWN. TLS 1.0: declarada obsoleta por NIST y PCI-DSS en 2020 (vulnerable a BEAST y POODLE en cifrados de bloque). TLS 1.1: declarada obsoleta junto con TLS 1.0. TLS 1.2: estándar mínimo actual; es segura cuando se configura correctamente con suites de cifrado robustas. TLS 1.3: publicada en 2018; elimina todos los algoritmos débiles, exige secreto hacia adelante, ofrece un handshake significativamente más rápido (1-RTT en lugar de 2-RTT) y evita los ataques de degradación. PCI-DSS 4.0 exige como mínimo TLS 1.2 y recomienda TLS 1.3.

Una suite de cifrado es un conjunto de algoritmos criptográficos que se utilizan conjuntamente en una sesión TLS. Cada suite de cifrado especifica: un algoritmo de intercambio de claves (cómo se establecen las claves de sesión), un algoritmo de autenticación (cómo se verifica el servidor), un algoritmo de cifrado masivo (qué cifra los datos) y un algoritmo de código de autenticación de mensajes (MAC) (cómo se verifica la integridad). El cliente y el servidor negocian qué suite de cifrado utilizar durante el handshake de TLS; el servidor selecciona la suite más robusta que ambos admiten.

La fase de intercambio de claves establece la clave de sesión sin transmitirla. Intercambio de claves RSA (TLS 1.2): el cliente cifra un secreto premaster con la clave pública del servidor; si posteriormente se compromete la clave privada, se pueden descifrar todas las sesiones anteriores. DHE (Diffie-Hellman Ephemeral): genera un nuevo par de claves para cada sesión; proporciona secreto hacia adelante, pero es lento. ECDHE (Elliptic Curve DHE): ofrece el mismo secreto hacia adelante que DHE, pero con tamaños de clave menores y mejor rendimiento; es el intercambio de claves preferido tanto en TLS 1.2 como en TLS 1.3. TLS 1.3 exige ECDHE o DHE y elimina por completo el intercambio de claves RSA.

El secreto perfecto hacia adelante (PFS) garantiza que, incluso si posteriormente se compromete la clave privada de larga duración del servidor, no se puedan descifrar las sesiones grabadas anteriormente. El PFS se consigue mediante un intercambio de claves efímeras (ECDHE o DHE), en el que se genera un par de claves temporal nuevo para cada sesión y se descarta después de utilizarlo. Sin PFS (con el intercambio de claves RSA), un atacante puede grabar hoy todas las sesiones TLS cifradas y descifrarlas retroactivamente cuando finalmente obtenga la clave privada. La estrategia de vigilancia de la NSA de «recopilar ahora y descifrar después» supone que los objetivos acabarán actualizándose a claves más robustas o que los ordenadores cuánticos romperán las actuales.

Varios componentes de cifrado heredados están criptográficamente comprometidos y deben deshabilitarse. Cifrados NULL: no aplican ningún cifrado. Cifrados de grado de exportación (ataque FREAK): se debilitaron deliberadamente para cumplir las normativas estadounidenses de exportación de la década de 1990. RC4: cifrado de flujo con sesgos estadísticos aprovechados en ataques. DES y 3DES: cifrados de bloque con tamaños de bloque demasiado pequeños (ataque SWEET32) o longitudes de clave insuficientes. MD5 y SHA-1 para MAC: vulnerabilidades de colisión. Cifrados anónimos (aNULL): no autentican el servidor. Las configuraciones modernas de TLS solo deberían permitir AES-GCM, ChaCha20-Poly1305, AES-CCM como cifrados masivos.

TLS 1.3 incorpora varias mejoras de seguridad importantes con respecto a 1.2. PFS obligatorio: se elimina el intercambio de claves RSA; todas las sesiones utilizan ECDHE o DHE. Menos suites de cifrado: solo se permiten 5 suites de cifrado AEAD; no es posible negociar cifrados débiles. Handshake más rápido: un viaje de ida y vuelta (1-RTT) frente a los 2-RTT de TLS 1.2, y 0-RTT para reanudar sesiones (aunque 0-RTT implica consideraciones relacionadas con ataques de repetición). Handshake cifrado: el certificado del servidor se cifra durante el handshake, lo que impide que los observadores pasivos identifiquen a qué certificado y, por tanto, a qué sitio web se conecta el cliente.

Los ataques de degradación engañan a un servidor y a un cliente TLS para que utilicen una versión de TLS o una suite de cifrado más antigua y débil de la que ambos admiten. POODLE (Padding Oracle On Downgraded Legacy Encryption) aprovechó el hecho de que las implementaciones de TLS volvían a SSL 3.0 cuando se producían errores de conexión. La medida de mitigación consistió en deshabilitar SSL 3.0. FREAK y Logjam explotaron cifrados de grado de exportación. TLS_FALLBACK_SCSV es una pseud suite de cifrado que los clientes incluyen para indicar «esta no es mi versión preferida»; si un servidor la detecta y admite una versión superior, cancela el intento de degradación.

La autenticación del servidor TLS depende de que el cliente verifique la cadena de certificados del servidor hasta una CA raíz de confianza. Comprobaciones esenciales: caducidad (el certificado debe estar dentro de su periodo de validez), revocación (la comprobación mediante CRL u OCSP confirma que el certificado no se ha revocado), nombre de host (SAN o CN debe coincidir con el dominio al que se conecta) y cadena de firmas (las firmas de la CA intermedia y de la CA raíz son válidas). Certificate Transparency (CT) exige que todos los certificados de confianza pública se registren en registros CT de solo adición, lo que permite detectar certificados emitidos incorrectamente pocos minutos después de su emisión.

Qualys SSL Labs (ssllabs.com/ssltest) es la herramienta de referencia para evaluar la configuración TLS de un servidor web. Asigna a los servidores una calificación de A+ (excelente) a F (problemas críticos) según las versiones de TLS admitidas, la robustez de las suites de cifrado, la validez del certificado, la configuración de HSTS, la compatibilidad con el secreto hacia adelante y la resistencia frente a ataques conocidos. Una calificación A+ exige: únicamente TLS 1.2 o superior, todos los cifrados ECDHE, un certificado válido y HSTS con precarga. Las organizaciones deberían ejecutar pruebas de SSL Labs después de la configuración inicial y nuevamente después de cualquier cambio en la pila TLS. Muchos marcos de cumplimiento (PCI-DSS) exigen evaluaciones periódicas de la configuración TLS.

Los certificados TLS caducados provocan interrupciones y advertencias de confianza para los usuarios que los atacantes pueden aprovechar. La gestión del ciclo de vida de los certificados incluye: registrar todos los certificados en un inventario de certificados, configurar alertas de caducidad al menos 30 días antes del vencimiento, automatizar la renovación con el protocolo ACME (Let's Encrypt, Certbot), utilizar periodos de validez cortos (90 días para certificados públicos) para reducir la ventana de riesgo en caso de compromiso y utilizar certificados comodín (*.example.com) con cuidado, ya que un certificado comodín comprometido afecta a todos los subdominios. Las plataformas de gestión de certificados (Venafi, DigiCert CertCentral) automatizan el descubrimiento y el ciclo de vida en inventarios de certificados grandes.

Compruebe su comprensión de los conceptos de CompTIA Security+ (SY0-701) de esta lección.

En esta lección ha aprendido que TLS 1.0/1.1 están obsoletas y TLS 1.2 es el estándar mínimo, mientras que TLS 1.3 es la opción preferida, con PFS obligatorio y handshakes cifrados; las suites de cifrado especifican el intercambio de claves (se prefiere ECDHE), el cifrado masivo (AES-GCM, ChaCha20) y los algoritmos MAC; y el secreto perfecto hacia adelante requiere un intercambio de claves efímeras (DHE/ECDHE) para que las sesiones anteriores no puedan descifrarse ni siquiera después de que se comprometa la clave. A continuación, exploraremos el DNS seguro: DNSSEC y DNS over HTTPS.