Saltar al contenido
ecdsa.com

TLS 1.2 frente a TLS 1.3: qué cambia y qué configurar

TLS 1.3 eliminó todas las construcciones que estaban detrás de una década de ataques a TLS y ahorra un viaje de ida y vuelta. TLS 1.2 sigue siendo aceptable con una configuración restrictiva, pero las nuevas capacidades solo existen en 1.3.
Qué se comparaTLS 1.2TLS 1.3

TLS 1.2 frente a TLS 1.3 ya no es una elección entre iguales. TLS 1.2 (RFC 5246, 2008) es seguro si se limita al intercambio de claves ECDHE y a conjuntos de cifrado AEAD; TLS 1.3 (RFC 8446 en 2018, revisado como RFC 9846 en julio de 2026) hace que esa sea la única opción, cifra una parte mayor del handshake y es la única versión que ofrece intercambio de claves híbrido poscuántico y Encrypted Client Hello.

De un vistazo

TLS 1.2TLS 1.3
EspecificaciónRFC 5246 (2008), hoy declarado obsoleto por el RFC 9846RFC 8446 (2018), revisado como RFC 9846 (2026)
Handshake completo2 viajes de ida y vuelta1 viaje de ida y vuelta (2 con HelloRetryRequest)
ReanudaciónID de sesión o tickets, 1 viaje de ida y vueltaPSK, 1 viaje de ida y vuelta, datos 0-RTT opcionales
Intercambio de clavesTransporte de claves RSA, DHE, ECDHEECDHE, DHE, KEM híbridos; PSK con o sin DHE
Forward secrecySolo con conjuntos (EC)DHESiempre (salvo en la reanudación solo con PSK)
Conjuntos de cifradoNombran el intercambio de claves, la autenticación, el algoritmo de cifrado y el MAC; admiten CBC, RC4 y 3DESCinco conjuntos, todos AEAD, que nombran el algoritmo de cifrado y el hash
Cifrado del handshakeCertificados en claroTodo lo que sigue a ServerHello va cifrado
FirmasPKCS#1 v1.5 o PSS, ECDSA; SHA-1 posiblePSS obligatorio para las firmas RSA del handshake; SHA-1 eliminado
Renegociación, compresiónPresentes (peligrosas si no se restringen)Eliminadas
Protección contra la degradaciónSolo el hash de Finished; FALLBACK_SCSVCentinela en ServerHello.random más la transcripción
Intercambio de claves poscuánticoNo disponibleX25519MLKEM768 e híbridos con curvas NIST
Encrypted Client HelloNo disponibleRFC 9849

El handshake

TLS 1.2 negocia primero e intercambia las claves después: el cliente enumera conjuntos de cifrado, el servidor elige uno y envía su certificado y los parámetros del intercambio de claves, el cliente envía su key share y ambos terminan. Pasan dos viajes de ida y vuelta antes de que fluyan los datos de aplicación, y el certificado viaja en claro. Con los conjuntos de RSA estático, el cliente cifra el secreto premaestro (premaster secret) con la clave del certificado del servidor, así que cualquiera que obtenga esa clave más adelante puede descifrar todas las sesiones grabadas.

TLS 1.3 apuesta por adelantado: el cliente envía key shares para sus grupos preferidos en el primer mensaje, el servidor responde con su key share y, acto seguido, con las extensiones cifradas, el certificado, CertificateVerify y Finished, y el cliente puede enviar datos tras un solo viaje de ida y vuelta. Las sesiones reanudadas pueden llevar incluso datos anticipados 0-RTT (early data), a costa de perder la protección contra repetición para esos datos.

El script siguiente, ejecutado con OpenSSL 3.6.5 contra un servidor público el 20 de octubre de 2026, muestra el resultado práctico cuando el mismo cliente fuerza cada versión.

Un servidor, dos versiones del protocolo
#!/bin/sh
host=${1:-cloudflare.com}
for version in -tls1_2 -tls1_3; do
  echo "== $version"
  echo | openssl s_client -connect "$host:443" -servername "$host" "$version" -brief 2>&1 \
    | grep -E "Protocol version|Ciphersuite|Peer Temp Key|Negotiated TLS1.3 group"
done
Salida
== -tls1_2
Protocol version: TLSv1.2
Ciphersuite: ECDHE-ECDSA-CHACHA20-POLY1305
Peer Temp Key: X25519, 253 bits
== -tls1_3
Protocol version: TLSv1.3
Ciphersuite: TLS_AES_256_GCM_SHA384
Negotiated TLS1.3 group: X25519MLKEM768

La conexión TLS 1.2 es segura aquí porque el servidor solo permite ECDHE con AEAD, pero se queda en el X25519 clásico; la conexión TLS 1.3 negocia el híbrido poscuántico.

Qué eliminó TLS 1.3 y por qué

Casi todos los ataques famosos contra TLS de la década de 2010 explotaban una funcionalidad de la época de TLS 1.2 que TLS 1.3 eliminó:

  • Modo CBC con MAC-then-encrypt (BEAST, Lucky Thirteen, POODLE): solo quedan los algoritmos de cifrado AEAD.
  • RC4 (sesgos estadísticos) y 3DES (SWEET32): eliminados.
  • Transporte de claves RSA (oráculos de relleno de Bleichenbacher, ROBOT; sin forward secrecy): eliminado.
  • Criptografía de grado de exportación y grupos arbitrarios de campo finito (FREAK, Logjam): solo quedan los grupos con nombre.
  • Renegociación y compresión (triple handshake, CRIME): eliminadas.
  • Firmas sobre transcripciones parciales (en TLS 1.2, ServerKeyExchange solo firma los parámetros): CertificateVerify firma toda la transcripción.
  • SHA-1 y MD5 en las firmas: eliminados.

El RFC 9846 también endurece los requisitos para las implementaciones de TLS 1.2, y el RFC 9325 enumera el subconjunto seguro de TLS 1.2: ECDHE o DHE con AEAD, extended master secret (RFC 7627) y renegociación segura.

Funciones que solo ofrece TLS 1.3

  • Intercambio de claves híbrido poscuántico (X25519MLKEM768, RFC 10024), que los principales navegadores negocian por defecto desde finales de 2024 y OpenSSL desde la 3.5.
  • Encrypted Client Hello (RFC 9849), que oculta el nombre del servidor a la red cuando se usa con registros DNS HTTPS.
  • Compresión de certificados (RFC 8879) y credenciales delegadas (RFC 9345).
  • QUIC, que integra el handshake de TLS 1.3 y es el transporte de HTTP/3.

Cumplimiento normativo y políticas

  • Sistemas federales de EE. UU.: NIST SP 800-52 Rev. 2 exige que los servidores TLS gubernamentales admitan TLS 1.3 a más tardar el 1 de enero de 2024 y permite TLS 1.2 con conjuntos aprobados.
  • Entornos de tarjetas de pago: PCI DSS prohíbe SSL y las primeras versiones de TLS (1.0) desde el 30 de junio de 2018; TLS 1.2 y 1.3 son aceptables.
  • IETF: el RFC 8996 declaró obsoletos TLS 1.0 y 1.1 en 2021; los navegadores los retiraron en 2020.
  • Planes poscuánticos: NIST IR 8547 (borrador) y CNSA 2.0 dan por hecho un establecimiento de claves híbrido o poscuántico, que solo está disponible en TLS 1.3.

Cuándo elegir cada una

  • Sitios web y API públicos: TLS 1.3 como opción preferida y, como alternativa, TLS 1.2 limitado al subconjunto seguro.
  • Servicios internos, mallas de servicios, mTLS: solo TLS 1.3.
  • Clientes heredados (Android antiguo, dispositivos embebidos, versiones antiguas de Java y Windows): TLS 1.2 con ECDHE y AEAD; planifica su retirada.
  • Dispositivos intermedios (middleboxes) que inspeccionan el tráfico: cuenta con que tendrán que actualizarse para TLS 1.3, ECH y los ClientHello poscuánticos de gran tamaño, en lugar de frenar los servidores por ellos.
  • Todo lo que necesite confidencialidad poscuántica: TLS 1.3 con un grupo híbrido.

Notas de migración

  1. Actualiza la biblioteca TLS: OpenSSL 1.1.1 o posterior para TLS 1.3, 3.5 o posterior para los grupos poscuánticos predeterminados; versiones actuales de BoringSSL y Go, Java 11 o posterior, Windows Server 2022 o posterior.
  2. Activa TLS 1.3 junto a 1.2 y después limita 1.2 a conjuntos ECDHE con AEAD; en nginx, ssl_protocols TLSv1.2 TLSv1.3; con una lista ssl_ciphers corta, ya que los conjuntos de TLS 1.3 se configuran por separado.
  3. Revisa los certificados y las claves: los certificados RSA funcionan con TLS 1.3 porque las firmas del handshake usan PSS con las mismas claves; los certificados ECDSA funcionan sin cambios.
  4. Decide qué hacer con 0-RTT: déjalo desactivado salvo que la aplicación pueda gestionar con seguridad la repetición de solicitudes anticipadas.
  5. Mide el tráfico TLS 1.2 que queda y fija una fecha para desactivarlo allí donde llegue a cero. El generador de configuración TLS produce la configuración para los servidores habituales, y el comprobador masivo de dominios indica qué versiones aceptan tus hosts.

Referencias

Todas las comparaciones