Cómo funciona SSL/TLS: el handshake TLS explicado

Cada vez que visitas un sitio web HTTPS, tu navegador y el servidor realizan una negociación TLS — un intercambio rápido que autentica al servidor, acuerda los parámetros de cifrado y deriva una clave secreta compartida. Esto ocurre en 1-2 viajes de red (50-200ms) antes de que se cargue cualquier contenido de la página.

La negociación TLS 1.3 (estándar actual)

TLS 1.3 completa la negociación en un solo viaje de ida y vuelta (1-RTT):

Paso 1 — Client Hello Tu navegador envía: versiones TLS soportadas, suites de cifrado soportadas, un número aleatorio y parámetros de key share (para el intercambio de claves Diffie-Hellman).

Paso 2 — Server Hello + Certificate + Finished El servidor responde con: la suite de cifrado elegida, su certificado (probando su identidad), su key share y un mensaje «Finished». En TLS 1.3, el certificado está cifrado — los observadores pasivos no pueden ver a qué sitio te estás conectando.

Paso 3 — Client Finished El navegador verifica el certificado contra su lista de CAs de confianza, calcula la clave de sesión compartida a partir del intercambio Diffie-Hellman y envía su mensaje «Finished». Los datos de la aplicación cifrados pueden fluir ahora.

Total: 1 viaje de ida y vuelta. Las conexiones reanudadas (donde el cliente se ha conectado antes) pueden usar 0-RTT — enviando datos cifrados con el primer mensaje.

Negociación TLS 1.2 (todavía ampliamente utilizada)

TLS 1.2 requiere 2 viajes de ida y vuelta:

1. Client Hello → versiones soportadas, cifrados, número aleatorio
2. Server Hello → cifrado elegido, certificado, intercambio de claves del servidor
3. Client Key Exchange → secreto pre-maestro (cifrado con la clave pública del servidor o vía Diffie-Hellman)
4. Change Cipher Spec + Finished (ambos lados)

TLS 1.2 soporta más suites de cifrado — incluyendo algunas débiles. La configuración adecuada importa más que con TLS 1.3.

Qué ocurre dentro de la conexión cifrada

Después de la negociación, todos los datos se cifran con la clave de sesión negociada usando un cifrado simétrico (típicamente AES-256-GCM o ChaCha20-Poly1305):

• Confidencialidad — los datos están cifrados; solo los dos puntos finales pueden leerlos
• Integridad — cada mensaje incluye un MAC (código de autenticación de mensaje); cualquier manipulación se detecta
• Autenticación — el certificado del servidor prueba su identidad (y opcionalmente, la del cliente)

Cada solicitud y respuesta HTTP — cabeceras, cuerpo, cookies, URLs — viajan a través de este canal cifrado.

Secreto perfecto hacia adelante

El TLS moderno usa intercambio de claves Diffie-Hellman efímero, lo que significa que cada conexión genera una clave de sesión única. Incluso si la clave privada del servidor se ve comprometida después, las conversaciones pasadas no pueden descifrarse.

TLS 1.3 hace obligatorio el secreto perfecto hacia adelante. TLS 1.2 lo soporta pero también permite el intercambio de claves RSA (que no proporciona secreto perfecto hacia adelante). Por esto se prefiere TLS 1.3.

El papel del certificado

La negociación TLS depende de que el servidor tenga un certificado SSL/TLS válido. El certificado proporciona:

1. La clave pública del servidor — usada durante el intercambio de claves
2. Nombre(s) de dominio — el navegador verifica que coincidan con la URL
3. Firma de la CA — prueba que una Autoridad Certificadora de confianza respalda este certificado
4. Fechas de validez — el navegador rechaza certificados expirados

Sin un certificado válido, la negociación falla y el navegador muestra una advertencia de seguridad. Obtén un certificado gratuito →

Rendimiento

En hardware moderno, el costo de CPU del cifrado es insignificante — las instrucciones AES-NI lo manejan en hardware. El costo principal son los viajes de ida y vuelta extra, que TLS 1.3 minimiza.

Qué se puede ver en la red

Sin HTTPS (HTTP)

Un observador en la red ve todo:

GET /login HTTP/1.1
Host: example.com
Cookie: session=abc123

username=admin&password=secret123

Nombres de usuario, contraseñas, cookies, contenido de páginas — todo en texto plano.

Con HTTPS (TLS)

El mismo observador ve:

[TLS handshake — server certificate visible in TLS 1.2, encrypted in TLS 1.3]
[Encrypted application data — indistinguishable from random bytes]
[Encrypted application data]
[Encrypted application data]

Pueden ver la dirección IP de destino y el nombre de host SNI (en TLS 1.2 — cifrado en TLS 1.3 con ECH). No pueden ver la ruta URL, cabeceras, cuerpo ni cookies.

Cómo encaja el certificado

La negociación TLS depende de que el servidor tenga un certificado SSL/TLS válido:

1. La clave pública del servidor — usada durante el intercambio de claves
2. Nombre(s) de dominio — el navegador verifica que coincidan con la URL
3. Firma de la CA — prueba que una Autoridad Certificadora de confianza respalda este certificado
4. Fechas de validez — el navegador rechaza certificados expirados

Sin un certificado válido, la negociación falla y el navegador muestra una advertencia de seguridad. Obtén un certificado gratuito →

Suites de cifrado TLS comunes en 2026

TLS 1.3 (solo 5 suites de cifrado — todas seguras)

TLS_AES_256_GCM_SHA384       ← Most common
TLS_AES_128_GCM_SHA256       ← Widely used
TLS_CHACHA20_POLY1305_SHA256 ← Best for mobile/ARM
TLS_AES_128_CCM_SHA256       ← IoT/embedded
TLS_AES_128_CCM_8_SHA256     ← IoT/embedded (short tag)

TLS 1.2 (usar solo suites AEAD)

ECDHE-ECDSA-AES256-GCM-SHA384  ← Best with ECC cert
ECDHE-RSA-AES256-GCM-SHA384    ← Best with RSA cert
ECDHE-ECDSA-CHACHA20-POLY1305  ← Mobile-optimized

Evita las suites no-AEAD (modo CBC) en TLS 1.2 — han sido vulnerables a ataques como BEAST y Lucky13.

Preguntas frecuentes

¿HTTPS ralentiza mi sitio web?

La negociación TLS añade un viaje de ida y vuelta (TLS 1.3) o dos (TLS 1.2) en la primera conexión. La reanudación de sesión elimina esto para visitantes recurrentes. Como HTTPS habilita HTTP/2 (multiplexación, compresión de cabeceras), los sitios HTTPS son frecuentemente más rápidos en general.

¿Qué es una suite de cifrado?

Una suite de cifrado es una combinación de algoritmos usados para intercambio de claves, cifrado y autenticación de mensajes. Ejemplo: TLS_AES_256_GCM_SHA384 significa TLS con cifrado AES-256-GCM e integridad de mensaje SHA-384. TLS 1.3 tiene solo 5 suites de cifrado — todas seguras. TLS 1.2 tiene 37, algunas de las cuales son débiles.

¿Puede alguien descifrar el tráfico HTTPS después?

No con secreto perfecto hacia adelante (intercambio de claves efímeras). Cada sesión usa una clave única derivada del intercambio Diffie-Hellman. Incluso si la clave privada a largo plazo del servidor se ve comprometida, las claves de sesión pasadas no pueden recuperarse. TLS 1.3 impone esto; TLS 1.2 lo soporta cuando está configurado correctamente.

¿Cómo se relaciona GetHTTPS con esto?

GetHTTPS genera el certificado que hace posible la negociación TLS. El certificado contiene la clave pública que el servidor usa durante el intercambio de claves. GetHTTPS crea este par de claves en tu navegador usando la Web Crypto API y se conecta directamente a la API ACME de Let’s Encrypt para obtener la firma. Cómo funciona GetHTTPS →