TLS

TLS es el protocolo que da confidencialidad, integridad y autenticidad al tráfico (HTTPS y mucho más). Esta ficha cubre cómo funciona el handshake, cómo auditar una configuración TLS y los ataques históricos que explican por qué hoy se recomienda TLS 1.3.

sequenceDiagram
    participant C as Cliente
    participant S as Servidor
    C->>S: ClientHello (suites, random)
    S-->>C: ServerHello (suite elegida, random)
    S-->>C: Certificate (cadena X.509)
    S-->>C: ServerHelloDone
    C->>S: ClientKeyExchange (premaster cifrado con la pública)
    C->>S: ChangeCipherSpec + Finished
    S-->>C: ChangeCipherSpec + Finished
    Note over C,S: Canal cifrado establecido

Handshake (versión resumida)

TLS 1.2
  ClientHello (cipher suites, extensiones) -> ServerHello (suite elegida) + certificado
  intercambio de clave (ECDHE) -> ambos derivan la clave de sesión -> Finished
TLS 1.3 (RFC 8446)
  handshake de 1-RTT (0-RTT opcional); SOLO suites AEAD con PFS (ECDHE)
  elimina RSA key exchange, CBC, RC4, compresión, renegociación -> mucho más simple y seguro

PFS (Perfect Forward Secrecy): con ECDHE, comprometer la clave privada del servidor no descifra el tráfico pasado capturado. Clave y razón para exigir ECDHE.

Qué auditar (enumeración)

testssl.sh https://host            # versión, suites, PFS, vulns conocidas, cert
sslscan host:443                   # suites soportadas rápido
nmap --script ssl-enum-ciphers -p443 host
openssl s_client -connect host:443 -tls1_2   # inspección manual del handshake/cert
# Qualys SSL Labs para una nota externa (sitios públicos)

Banderas rojas: SSLv3/TLS1.0/1.1 activos, RC4/3DES/CBC débiles, sin PFS, cert caducado o cadena incompleta, clave RSA < 2048.

Ataques históricos (por qué TLS evolucionó)

BEAST (2011)     CBC + IV predecible en TLS1.0
CRIME/BREACH     compresión + inyección -> recuperar cookies/tokens por tamaño
POODLE (2014)    downgrade a SSLv3 + padding oracle CBC
Heartbleed (2014) CVE-2014-0160: fuga de memoria de OpenSSL (claves, datos) por un bug
                  de heartbeat, NO un fallo del protocolo -> leer memoria del servidor
FREAK/Logjam     downgrade a claves "export" débiles (RSA/DH de 512 bits)
DROWN (2016)     reutilizar clave con SSLv2 vulnerable rompe TLS
Sweet32          colisión de bloque en 3DES (bloque de 64 bits) con muchas peticiones

Casi todos se mitigan: deshabilitar versiones/suites viejas, sin compresión TLS, y preferir TLS 1.3.

MITM en TLS (laboratorio / pentest de clientes)

# si el CLIENTE no valida bien el certificado (ver crypto-pki):
mitmproxy / burp como proxy -> presenta su propio cert -> si el cliente lo acepta, MITM total
# útil para analizar apps móviles/IoT; con pinning hay que hacer bypass (Frida) en entorno autorizado

Herramientas

testssl.sh, sslscan, nmap ssl-enum-ciphers, openssl s_client (auditoría).
mitmproxy / Burp (interceptar), Wireshark (analizar handshake, con claves de sesión para descifrar).

Defensa

TLS 1.3 (y 1.2 solo con suites AEAD + ECDHE); desactivar SSLv2/3, TLS 1.0/1.1, RC4, 3DES, CBC.
HSTS (fuerza HTTPS), OCSP stapling, certificados de CA válida con cadena completa, claves ≥ 2048/ECC.
Sin compresión TLS; renovación/rotación automatizada (ACME/Let’s Encrypt); monitorizar con CT.
En clientes propios: validación estricta y, si aplica, pinning.

CVEs y casos reales

Heartbleed (CVE-2014-0160): robo masivo de claves y datos de servidores OpenSSL en 2014.
POODLE (CVE-2014-3566), DROWN (CVE-2016-0800), Logjam, FREAK: downgrade/legacy.
ROBOT (2017): Bleichenbacher sobre RSA key exchange aún presente en equipos reales.

Checklist de prueba

Escanear con testssl.sh/sslscan: versiones y suites
¿SSLv3/TLS1.0-1.1, RC4, 3DES, CBC o sin PFS?
Verificar certificado: vigencia, cadena, SAN, tamaño de clave
¿Vulnerable a Heartbleed/POODLE/DROWN/ROBOT? (testssl marca)
¿HSTS presente? ¿redirección HTTP→HTTPS?
Clientes propios: MITM para comprobar validación/pinning
Preferir y verificar soporte de TLS 1.3

TLS