Aprende › Vulnerabilidades web

TLS/SSL: Logjam, FREAK, SWEET32, downgrade attacks y post-quantum

· 8 min de lectura

Aprende las misconfigs de TLS que siguen apareciendo en 2026: protocolos legacy, cipher suites débiles, downgrade attacks, perfect forward secrecy ausente, misconfigs de certificados, mTLS mal implementado y preparación post-quantum.

TLS (Transport Layer Security) protege todo el tráfico HTTPS del planeta. Diseñado con capa criptográfica robusta, su implementación en servidores sigue acumulando misconfigurations incluso en 2026: versiones obsoletas (TLS 1.0, 1.1) aún habilitadas en algunos proveedores, cipher suites débiles mantenidas por compatibilidad, Perfect Forward Secrecy ausente, certificados expirados o emitidos incorrectamente, downgrade attacks factibles. Y en el horizonte, la computación cuántica amenaza con romper RSA y ECC en años a venir, forzando migración a algoritmos post-quantum que ya están disponibles.

Esta lección cubre el handshake TLS 1.2 y 1.3, las vulnerabilidades históricas que siguen apareciendo (Logjam, FREAK, SWEET32, Heartbleed, ROBOT), misconfigs comunes de 2026, mTLS (mutual TLS) para servicios internos, y la transición a post-quantum cryptography que empezó en 2024 con CRYSTALS-Kyber. Es la octava lección de la Tanda 6, abriendo bloque de criptografía aplicada moderna.

La lección cubre defensa y auditoría legítima. Testing TLS de propiedades propias o autorizadas con herramientas como testssl.sh o SSL Labs.

TLS handshake en una imagen#

TLS 1.2 vs 1.3 handshake: RTT, cipher negotiation, certificate verification
TLS 1.2 vs 1.3 handshake: RTT, cipher negotiation, certificate verification

TLS 1.2 (2008, dominante hasta 2018)#

Flujo de 2 RTT:

  1. ClientHello: lista de cipher suites soportadas, random nonce.
  2. ServerHello + Certificate + KeyExchange: servidor elige cipher, envía cert, inicia key exchange (ECDHE para forward secrecy).
  3. ClientKeyExchange + ChangeCipherSpec + Finished: cliente completa handshake.
  4. ChangeCipherSpec + Finished: servidor confirma.

TLS 1.3 (2018, dominante 2024+)#

Simplificado y 1 RTT típico:

  1. ClientHello: incluye key share tentativo.
  2. ServerHello + Certificate + CertificateVerify + Finished: todo encrypted desde el principio.
  3. Finished: client confirma.

Cambios clave 1.3 vs 1.2:

  • Removed: RSA key exchange, AES-CBC, SHA-1, static Diffie-Hellman, compression.
  • Mandatory: PFS via (EC)DHE, authenticated encryption (AEAD).
  • Faster: 1 RTT handshake, 0 RTT con pre-shared keys.

Vulnerabilidades históricas que siguen vigentes#

Heartbleed (CVE-2014-0160)#

OpenSSL bug: TLS heartbeat permitía leer memoria del servidor, incluyendo llaves privadas, passwords. Parcheo rápido pero algunos sistemas legacy siguen vulnerables.

FREAK (CVE-2015-0204)#

Downgrade a export-grade RSA (40-56 bits). Atacante fuerza servidor a usar llave débil, crackea y MITM. Afectaba Apache, OpenSSL, Android, iOS. Parche: disable export ciphers.

Logjam (CVE-2015-4000)#

Downgrade de Diffie-Hellman a 512-bit DH params. Precomputo de group mediano. Mitigation: disable export DH, usar 2048-bit DH mínimo.

SWEET32 (CVE-2016-2183)#

Attack contra block ciphers de 64-bit (3DES, Blowfish). Birthday attack sobre sesiones largas (~32GB). Mitigation: disable 3DES y legacy block ciphers.

ROBOT (2017)#

Return Of Bleichenbacher's Oracle Threat. Padding oracle en RSA PKCS#1 v1.5. Afectaba Facebook, PayPal, Cisco. Mitigation: disable RSA key exchange en TLS 1.2, mandatory en 1.3.

DROWN (CVE-2016-0800)#

Servers con SSLv2 enabled podían ser atacados via cross-protocol attack. Fixed disabling SSLv2 forever.

BEAST, CRIME, BREACH#

Compression-based side-channels en HTTPS. Mitigation: disable TLS compression, segmented responses.

Misconfigs comunes en 2026#

Misconfigs TLS 2026: TLS 1.0/1.1 aún enabled, 3DES, weak DH, no PFS, HSTS missing
Misconfigs TLS 2026: TLS 1.0/1.1 aún enabled, 3DES, weak DH, no PFS, HSTS missing

TLS 1.0/1.1 aún enabled#

Deprecated oficialmente 2020. Muchos servers legacy aún lo soportan por «compatibility». Herramientas como testssl.sh lo detectan en segundos.

Weak cipher suites#

  • RC4: broken, nunca usar.
  • 3DES: 64-bit block, SWEET32.
  • MD5 / SHA-1 signatures: colisiones prácticas.
  • DH < 2048: vulnerable.
  • Export ciphers: históricos, nunca.

No PFS (Perfect Forward Secrecy)#

Sin PFS, compromiso de private key compromete todas sesiones pasadas y futuras. Con PFS (ECDHE), cada sesión tiene key única.

HSTS missing#

HTTP Strict Transport Security forces HTTPS. Sin HSTS, MITM downgrade to HTTP posible.

Certificate issues#

  • Expired certs: lamentablemente común.
  • Wildcard overly broad: *.company.com expone muchos subdomains.
  • Self-signed en producción.
  • Weak key (RSA < 2048, not EC).
  • SHA-1 signature aún en legacy.

OCSP stapling missing#

OCSP Must-Staple cert plus stapling prevents revocation leak + performance.

Mixed content#

HTTPS page carga HTTP resources. Browser warnings + security holes.

Tools para audit#

  • testssl.sh: CLI robusto, standard de facto.
  • SSL Labs Server Test: web service de Qualys, excelente para público-facing.
  • nmap --script ssl-enum-ciphers.
  • sslyze: Python library.
  • sslscan: lightweight.
  • Hardenize: comprehensive web platform scan (TLS + headers + DNS).
  • Mozilla SSL Config Generator: genera configs correctos Nginx/Apache.
# testssl.sh canonical
testssl.sh --full https://example.com

# Lo que reporta:
# - Protocols habilitados
# - Cipher suites + ranking
# - Certificate chain
# - Known vulns (Heartbleed, ROBOT, etc)
# - HSTS, OCSP, etc

Mutual TLS (mTLS)#

Para autenticación bilateral, cliente también presenta cert. Usado en:

  • Service mesh (Istio, Linkerd): mTLS obligatorio entre services.
  • API gateways corporate.
  • IoT con cert deployment.
  • Zero Trust architectures.

Problemas comunes:

  • Client cert validation incomplete: servidor acepta cualquier cert válidamente firmado, no verifica identity.
  • Private key storage: certs en file system sin HSM.
  • Cert rotation manual y riesgoso.

Mitigation: SPIFFE/SPIRE para identity management, HSM/KMS para keys, automatic rotation via cert-manager.

Post-quantum: la transición#

Quantum computers con suficiente scale pueden romper RSA y ECC usando Shor's algorithm. Timeline esperado por consensus: 10-30 años (incertidumbre grande).

NIST estandarizó algoritmos post-quantum en 2024:

  • CRYSTALS-Kyber: key encapsulation (KEM) basado en lattices.
  • CRYSTALS-Dilithium: digital signatures.
  • FALCON: signatures compactos.
  • SPHINCS+: signatures hash-based conservative.

Adoption en 2026:

  • OpenSSL 3.5+: soporte experimental.
  • Google Chrome: X25519Kyber768 hybrid en producción desde 2024.
  • Cloudflare: hybrid post-quantum para sus clientes.
  • Signal protocol: PQXDH para messaging.

Hybrid mode es la transition approach: combinar classical (X25519) con post-quantum (Kyber). Si uno falla, el otro protege. Overhead modesto.

Auditoria defensiva#

Un audit TLS típico incluye:

  • Protocol support: solo TLS 1.2 + 1.3.
  • Cipher suites: strong only, HTTP/2 compatibility.
  • Certificate chain: valid, strong keys, reasonable expiry.
  • HSTS present con reasonable max-age, includeSubDomains.
  • OCSP stapling working.
  • CAA DNS records: controlan qué CAs pueden emitir.
  • Known vulns: testing contra Heartbleed, ROBOT, etc.
  • Perfect Forward Secrecy: ECDHE mandatory.
  • TLS extensions: sensible config (SNI, etc).
  • Post-quantum readiness: planning document existe.

Walkthrough: audit TLS de producción#

Para fijar el patrón contra servidor real (propio o autorizado):

Paso 1 — scan inicial con testssl.sh:

testssl.sh --full --quiet https://objetivo.com | tee tls-audit.txt
# ~30-60 segundos para full test

Paso 2 — review findings:

  • Protocols: ¿solo 1.2+1.3?
  • Cipher strength: ¿alguno marked «weak»?
  • PFS: ¿todos los active ciphers con ECDHE?
  • Server preference: ¿order sensato?
  • Vulnerabilities: ¿Heartbleed, ROBOT, etc.?

Paso 3 — verificar certificate:

openssl s_client -connect objetivo.com:443 -showcerts 2>/dev/null | \
  openssl x509 -text -noout | grep -E "Signature|Public-Key|Not After"

Chequear: key strength 2048+ (RSA) o 256 (EC), SHA-256+, expiry reasonable.

Paso 4 — HSTS y headers:

curl -I -s https://objetivo.com | grep -iE "strict-transport|content-security"

Paso 5 — Qualys SSL Labs para second opinion y grading público.

Paso 6 — reporte: findings prioritizados, fixes concretos (Mozilla config examples), timeline sugerido.

Configuración correcta Nginx#

Ejemplo de config moderna para Nginx 1.25+:

ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384;
ssl_prefer_server_ciphers off;
ssl_session_timeout 1d;
ssl_session_cache shared:SSL:50m;
ssl_session_tickets off;

# OCSP stapling
ssl_stapling on;
ssl_stapling_verify on;
resolver 1.1.1.1 1.0.0.1 valid=300s;

# HSTS
add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;

Generable automáticamente con Mozilla SSL Configuration Generator según nivel (modern/intermediate/old).

Errores comunes#

  • Mantener TLS 1.0/1.1 «por legacy compatibility» sin medir si realmente hay clients.
  • SHA-1 en certs new (debería ser SHA-256 mínimo).
  • Confianza en que «CA confiable» = secure. Hay CAs problemáticas.
  • No monitor cert expiry → outage.
  • mTLS con client cert validation débil.
  • Ignorar post-quantum planning hasta que sea urgente.

Preguntas frecuentes#

¿TLS 1.3 es inmune a todo?#

Mucho más resistente que 1.2. Removió múltiples vulnerable primitives. Pero implementations pueden tener bugs; config matters.

¿Mozilla SSL config generator es confiable?#

Sí, es referencia industria. Genera configs para modern/intermediate/old compatibility levels. Buena base para configurar Nginx/Apache/HAProxy.

¿Cuándo migrar a post-quantum en producción?#

Hybrid mode: ya puedes empezar. Post-quantum only: esperar que ecosystem mature. Secretos con long retention (10+ años) deberían considerar hybrid ahora para protegerse contra «harvest now, decrypt later».

¿mTLS vs OAuth JWT?#

Complementarios. mTLS para transport layer trust (service identity). JWT para user identity y authorization. Usar ambos en architectures Zero Trust.

¿Dónde practico?#

El laboratorio signinbleed de whoami-labs incluye servers TLS con misconfigs plantadas: TLS 1.0 habilitado, cipher suites débiles, certs expired, DH débil. Practicas audit con testssl.sh, identificación, propuesta de config correcta.

¿Let's Encrypt es seguro?#

Sí. CA gratis, trusted por browsers, cert validity 90 días (rotación frecuente es feature, no bug). Mejora adoption de HTTPS globalmente. ACME protocol permite automation con certbot, acme.sh, cert-manager.

¿Qué hacer con legacy clients sin TLS 1.2+?#

Decisión business. Si pocos clients: comunicar y forzar upgrade. Si muchos: mantener legacy intermediate network separada, accept risk documented. En 2026 TLS 1.2+ es realista para 99% de casos.

¿Certificate Transparency ayuda?#

Sí. CT logs permiten detectar certs emitidos para tu dominio por CAs maliciosas o compromised. CAA DNS records restringen qué CAs pueden emitir. Combinación reduce riesgo de rogue cert issuance.

¿mTLS con rotación automática es viable?#

Sí: SPIFFE/SPIRE, cert-manager con Vault PKI, HashiCorp Consul Connect. Infrastructure complex pero resuelve el problema manual rotation. Para mTLS en service mesh es prácticamente standard.

¿Cuánto overhead añade post-quantum hybrid?#

Modest: ~1-2KB adicionales en handshake, menos de 10ms latency típicamente. Cloudflare reporta <5% impact en client experience. Incentive para adoption es bajo costo vs defense future-proof.

Resumen#

  • TLS 1.3 moderno, resistente. TLS 1.0/1.1 deprecated pero aún presentes.
  • Vulnerabilidades históricas: Heartbleed, FREAK, Logjam, SWEET32, ROBOT.
  • Misconfigs 2026: legacy protocols, weak ciphers, no PFS, HSTS missing, expired certs.
  • Tools: testssl.sh, SSL Labs, sslyze, Mozilla SSL config generator.
  • mTLS: bilateral authentication, usado en service mesh y Zero Trust.
  • Post-quantum: NIST standards 2024 (Kyber, Dilithium). Hybrid mode como transition path.
  • Harvest now, decrypt later: amenaza real para secretos long-retention.

Harvest now, decrypt later#

Una preocupación específica de criptoanálisis cuántico futuro es el modelo harvest now, decrypt later: un atacante estatal captura hoy tráfico cifrado con RSA/ECC y lo guarda, confiando en que en 10-20 años tendrá quantum computer para descifrarlo. Para secretos con retention time largo (datos médicos, intelligence, military, propiedad intelectual de research), esto es amenaza real presente aunque la decryption sea futura.

Por eso agencias como NSA han movido su harvesting detection a priority alto, y defensa-oriented organizations están empezando a implementar hybrid post-quantum ya para traffic sensitive. Si tu organización maneja datos que deben permanecer confidential durante décadas, no esperar a que quantum sea mainstream: hybrid es viable hoy y el overhead es modesto.

Monitoring continuo#

TLS no es «set and forget». Config sensible, cert rotation, nuevas vulns, protocol updates. Elementos de monitoring que organizaciones maduras mantienen:

  • Certificate expiry alerting (30/14/7/1 día).
  • SSL Labs grade monitoring semanalmente.
  • CT log monitoring para rogue certs.
  • CAA records en DNS para restrict issuers.
  • Weekly testssl.sh runs against production.
  • Automated remediation donde posible.
  • Incident response playbook para TLS incidents.

Herramientas: Grafana + Prometheus con blackbox exporter, Cert Spotter, CertStream, Checkmk.

La próxima lección entra en Cobalt Strike y OpSec de red team, donde el desafío ya no es solo encontrar vulnerabilidades sino evitar detección durante operaciones largas. Combinar la higiene criptográfica correcta con prácticas de red team maduras es lo que distingue consultoras serias de actores aficionados, y entender ambos lados del juego es lo que hace a un profesional completo capaz de contribuir tanto en ofensa autorizada como en defensa estratégica a largo plazo en cualquier organización moderna actualmente activa.

Fuentes y lecturas recomendadas#

Practícalo en estos laboratorios

Ver todos los laboratorios de esta categoría