¿Qué es TLS 1.3? Todo lo que cambió

TLS 1.3 es la versión actual del protocolo Transport Layer Security, publicada como RFC 8446 en agosto de 2018. Es un rediseño fundamental — no una actualización incremental — que hace HTTPS más rápido, más simple y más seguro que cualquier versión anterior.

A partir de 2026, el 62% de los sitios web soportan TLS 1.3, y todos los navegadores principales lo soportan desde 2018.

Qué cambió respecto a TLS 1.2

La filosofía de diseño: eliminar todo lo que pueda ser mal configurado. TLS 1.2 tiene 37 suites de cifrado — algunas seguras, algunas rotas. TLS 1.3 tiene 5, todas seguras.

Las 5 suites de cifrado de TLS 1.3

TLS_AES_256_GCM_SHA384        ← Strongest, most common
TLS_AES_128_GCM_SHA256        ← Widely used, slightly faster
TLS_CHACHA20_POLY1305_SHA256  ← Best for ARM/mobile (no AES-NI)
TLS_AES_128_CCM_SHA256        ← IoT/embedded
TLS_AES_128_CCM_8_SHA256      ← IoT/embedded (short tag)

No puedes configurarlas mal — son todas cifrados AEAD con claves fuertes. No hay riesgo de «habilitar accidentalmente un cifrado débil» como en TLS 1.2.

Negociación 1-RTT: por qué es más rápida

Negociación TLS 1.2 (2 viajes ida y vuelta):

Client → Server:  ClientHello (supported ciphers)
Server → Client:  ServerHello, Certificate, KeyExchange
Client → Server:  KeyExchange, ChangeCipherSpec, Finished
Server → Client:  ChangeCipherSpec, Finished
                  [4 messages before encrypted data flows]

Negociación TLS 1.3 (1 viaje ida y vuelta):

Client → Server:  ClientHello + KeyShare
Server → Client:  ServerHello + KeyShare + Certificate + Finished
Client → Server:  Finished
                  [encrypted data can flow after 1 round trip]

El cliente envía sus parámetros de key share en el primer mensaje — no necesita esperar a que el servidor especifique los algoritmos primero. Esto reduce la negociación de 2 viajes ida y vuelta a 1.

Reanudación 0-RTT

Para visitantes recurrentes (que se han conectado antes), TLS 1.3 soporta 0-RTT — datos de aplicación cifrados enviados con el primer mensaje:

Client → Server:  ClientHello + KeyShare + EarlyData (encrypted request)
Server → Client:  ServerHello + response

La solicitud se envía antes de que la negociación se complete. Compromiso: los datos 0-RTT son vulnerables a ataques de repetición, por lo que solo deben usarse para solicitudes idempotentes (GET, no POST).

Secreto perfecto hacia adelante obligatorio

En TLS 1.2, podías usar intercambio de claves RSA — la clave RSA de largo plazo del servidor descifra directamente el secreto pre-maestro. Si alguien graba el tráfico y luego roba la clave privada del servidor, puede descifrar todas las conversaciones pasadas.

TLS 1.3 elimina el intercambio de claves RSA por completo. Todo el intercambio de claves usa Diffie-Hellman efímero (ECDHE) — se genera un par de claves único para cada conexión. Robar la clave privada del servidor no ayuda a descifrar sesiones pasadas. Más sobre secreto perfecto hacia adelante →

Certificado cifrado

En TLS 1.2, el certificado del servidor (incluyendo el nombre de dominio) se envía en texto plano durante la negociación. Un observador pasivo puede ver a qué sitio te estás conectando.

En TLS 1.3, el certificado se envía después de que se derivan las claves de la negociación — está cifrado. El SNI (Server Name Indication) todavía es visible en TLS 1.3, pero Encrypted Client Hello (ECH) cifrará eso también en el futuro.

Cómo habilitar TLS 1.3

Verificar si ya está habilitado

echo | openssl s_client -connect yourdomain.com:443 -servername yourdomain.com -tls1_3 2>/dev/null | grep "Protocol"
# Expected: TLSv1.3

Nginx (1.13+ con OpenSSL 1.1.1+)

ssl_protocols TLSv1.2 TLSv1.3;

TLS 1.3 está habilitado por defecto en Nginx moderno — solo necesitas no desactivarlo.

Apache (2.4.37+ con OpenSSL 1.1.1+)

SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1

Esto habilita TLS 1.2 y 1.3.

Verificar tu versión de OpenSSL

openssl version
# Needs: OpenSSL 1.1.1+ for TLS 1.3 support

Si tu OpenSSL es más antiguo, actualízalo o actualiza tu SO.

¿Debo forzar solo TLS 1.3?

Todavía no. Aproximadamente el 38% de los sitios no soportan TLS 1.3, y algunos clientes (proxies corporativos, Java 8, sistemas embebidos antiguos) solo soportan TLS 1.2. Eliminar TLS 1.2 hoy bloquearía a algunos usuarios.

Configuración recomendada: Soportar tanto TLS 1.2 como 1.3. Esto te da la velocidad de TLS 1.3 para clientes modernos mientras mantienes compatibilidad. Esto es lo que hacen Google, Cloudflare y la mayoría de los sitios importantes.

Preguntas frecuentes

¿Necesito un nuevo certificado para TLS 1.3?

No. El mismo certificado funciona con TLS 1.2 y 1.3. Los certificados son agnósticos al protocolo — contienen una clave pública y firma de CA, independientemente de qué versión TLS los use.

¿TLS 1.3 afecta el rendimiento?

Sí, positivamente. La negociación 1-RTT ahorra 50-100ms en la primera conexión. La reanudación 0-RTT elimina la latencia de negociación por completo para visitantes recurrentes. Combinado con HTTP/2 (que requiere HTTPS), los sitios con TLS 1.3 son mediblemente más rápidos.

¿TLS 1.2 sigue siendo seguro?

Sí, con suites de cifrado AEAD (AES-GCM, ChaCha20-Poly1305) e intercambio de claves ECDHE. Evita cifrados CBC en TLS 1.2 — han sido vulnerables a ataques (BEAST, Lucky13). TLS 1.3 es mejor, pero TLS 1.2 con cifrados modernos sigue siendo seguro.

¿Qué hay de TLS 1.4?

No hay TLS 1.4 planeado. El IETF considera TLS 1.3 como el objetivo para el futuro previsible. El próximo cambio importante será incorporar intercambio de claves post-cuántico (ML-KEM) como híbrido con ECDHE existente — esto ocurrirá dentro de TLS 1.3, no como una nueva versión.