El SSL/TLS handshake es un proceso de negociación donde cliente y servidor establecen una conexión segura y encriptada antes de intercambiar datos de aplicación. El handshake verifica la identidad del servidor mediante validación de certificado, negocia algoritmos de encriptación (cipher suites), realiza intercambio criptográfico de llaves, y deriva llaves de sesión para encriptación simétrica. Este proceso ocurre después del handshake TCP para cada conexión HTTPS.
TLS (Transport Layer Security), el sucesor de SSL (Secure Sockets Layer), protege HTTP, SMTP, FTP y otros protocolos. TLS 1.2 (RFC 5246, 2008) y TLS 1.3 (RFC 8446, 2018) son las versiones actuales. TLS 1.3 reduce la latencia del handshake de 2 RTT a 1 RTT, mejora la seguridad eliminando features obsoletos, y encripta más metadatos del handshake.
El handshake debe completarse antes de que fluyan los datos de aplicación. Para HTTPS, esto significa TCP handshake (1.5 RTT) + TLS handshake (1-2 RTT) = 2.5-3.5 RTT antes de enviar el HTTP request. El handshake 1-RTT de TLS 1.3 reduce esto a 2.5 RTT total. Session resumption y TLS False Start reducen aún más la latencia para clientes recurrentes.
Last updated: 2026-04-22
Cómo Funciona el TLS Handshake
El handshake establece secretos compartidos para encriptación sin transmitir esos secretos por la red. La criptografía de llave pública permite intercambio seguro de llaves; la criptografía simétrica proporciona encriptación eficiente de datos después del handshake.
TLS 1.2 Handshake (2 RTT)
Paso 1: ClientHello
El cliente envía:
- Versión TLS soportada (ej., TLS 1.2)
- Client random (32 bytes: timestamp + datos random)
- Cipher suites soportadas (lista de combinaciones de algoritmos)
- Métodos de compresión (típicamente null)
- Extensiones TLS: Server Name Indication (SNI), supported groups (curvas ECDHE), signature algorithms, session ID para resumption
Paso 2: ServerHello
El servidor responde con:
- Versión TLS seleccionada
- Server random (32 bytes)
- Cipher suite seleccionada de la lista del cliente
- Método de compresión seleccionado (usualmente null)
- Certificado del servidor (cadena de certificados X.509)
- ServerKeyExchange (para cipher suites DHE/ECDHE; contiene parámetros Diffie-Hellman)
- CertificateRequest (opcional, si el servidor requiere certificado de cliente)
- ServerHelloDone
Paso 3: Client Key Exchange y Verificación
El cliente:
- Valida el certificado del servidor (firma, expiración, cadena de confianza CA, coincidencia de hostname)
- Verifica firma del ServerKeyExchange (si está presente)
- Genera pre-master secret (para intercambio de llaves RSA) o realiza cálculo Diffie-Hellman (para DHE/ECDHE)
- Envía mensaje ClientKeyExchange conteniendo pre-master secret encriptado (RSA) o valor público DH (DHE/ECDHE)
- Opcional: Envía Certificate y CertificateVerify si el servidor solicitó certificado de cliente
- Envía ChangeCipherSpec para señalar que siguen registros encriptados
- Envía mensaje Finished (encriptado con nuevas llaves, verifica integridad del handshake)
Paso 4: Server Finish
El servidor:
- Desencripta pre-master secret (RSA) o realiza cálculo Diffie-Hellman (DHE/ECDHE)
- Deriva master secret del pre-master secret, client random, server random
- Deriva llaves de sesión del master secret: client/server MAC keys, client/server encryption keys, client/server IVs
- Envía ChangeCipherSpec
- Envía mensaje Finished (encriptado, verificado por cliente)
Handshake completado. Datos de aplicación encriptados con llaves de sesión derivadas.
TLS 1.3 Handshake (1 RTT)
TLS 1.3 simplifica y asegura el handshake:
Paso 1: ClientHello
El cliente envía:
- Versión TLS 1.3
- Client random
- Cipher suites (solo AEAD: AES-GCM, ChaCha20-Poly1305)
- Extensión key share: valor público ECDHE (adivinando la curva preferida del servidor)
- Algoritmos de firma soportados
- SNI, extensión supported versions
Paso 2: ServerHello, EncryptedExtensions, Certificate, Finished
El servidor responde en un solo flight:
- ServerHello: cipher suite seleccionada, server random
- Extensión key share: valor público ECDHE del servidor
- EncryptedExtensions: respuesta SNI, otras extensiones no criptográficas
- Certificate: cadena de certificados del servidor (encriptado)
- CertificateVerify: firma sobre transcripción del handshake (encriptado)
- Finished: MAC sobre transcripción del handshake (encriptado)
Todos los mensajes después de ServerHello encriptados con llaves derivadas del secreto compartido ECDHE. Detalles del certificado ocultos de observadores pasivos.
Paso 3: Client Finished
El cliente:
- Valida certificado del servidor
- Verifica firma CertificateVerify
- Envía mensaje Finished (encriptado)
Handshake completado en 1 RTT. Forward secrecy establecido (ECDHE obligatorio). Algoritmos legacy removidos (intercambio de llaves RSA, modo CBC, MD5, SHA-1, compresión).
Métodos de Intercambio de Llaves
Intercambio de Llaves RSA (TLS 1.2, Removido en TLS 1.3)
El cliente genera pre-master secret, lo encripta con la llave pública RSA del servidor desde el certificado. El servidor desencripta con llave privada. Sin forward secrecy: si la llave privada del servidor se compromete, todas las sesiones pasadas son desencriptables. Removido de TLS 1.3 debido a falta de forward secrecy.
Intercambio Diffie-Hellman (DHE)
Ambos lados generan pares de llaves DH, intercambian valores públicos. El secreto compartido se computa sin transmitirlo. Forward secrecy: la llave RSA del servidor solo firma parámetros DH, no encripta pre-master secret. Compromiso de llave privada no revela llaves de sesión pasadas. Lento (aritmética de primos grandes).
Elliptic Curve Diffie-Hellman (ECDHE)
Igual que DHE pero usando criptografía de curva elíptica. Llaves más pequeñas, computación más rápida. Intercambio de llaves más común en TLS 1.2 y TLS 1.3. Curvas: X25519 (preferida), secp256r1 (P-256), secp384r1 (P-384). Forward secrecy. Requerido en TLS 1.3.
Cipher Suites
Una cipher suite especifica algoritmos para intercambio de llaves, autenticación, encriptación y MAC. Nombrada como: TLS_KEYEXCHANGE_AUTHENTICATION_WITH_CIPHER_MODE_MAC.
Ejemplos de cipher suites:
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256(TLS 1.2)- Intercambio de llaves: ECDHE
- Autenticación: RSA (firma del certificado)
- Encriptación: AES-128 en modo GCM (encriptación autenticada)
- MAC: SHA256 (usado en la autenticación de GCM)
TLS_AES_256_GCM_SHA384(TLS 1.3)- Encriptación: AES-256-GCM
- Hash: SHA384
- Intercambio de llaves: ECDHE (implícito, única opción en TLS 1.3)
Las cipher suites de TLS 1.3 solo especifican algoritmos simétricos; el intercambio de llaves siempre es ECDHE. Las cipher suites de TLS 1.2 especifican todos los componentes.
Validación de Certificados
El cliente valida el certificado del servidor durante el handshake:
Validación de Cadena
- Certificado firmado por Certificate Authority (CA) confiable
- Certificado de CA firmado por root CA (integrado en el trust store del OS/navegador)
- Toda la cadena verificada desde cert del servidor hasta root CA
- Ningún certificado revocado (verificado vía CRL u OCSP)
Propiedades del Certificado
- Hora actual dentro del período de validez del certificado (fechas not before/not after)
- Certificado no revocado (verificación CRL u OCSP)
- Hostname coincide con Subject Alternative Name (SAN) o Common Name (CN) del certificado
- Certificado tiene key usage apropiado: digitalSignature para ECDHE, keyEncipherment para intercambio de llaves RSA
- Extended Key Usage incluye TLS Web Server Authentication
Detección de Debilidades
- Tamaño mínimo de llave: RSA ≥2048 bits, ECDSA ≥256 bits
- Algoritmo de firma: SHA-256 o más fuerte (rechazar SHA-1, MD5)
- Certificado no débil (ej., vulnerabilidad Debian weak key)
Si alguna verificación falla, el cliente aborta el handshake con error de certificado.
Session Resumption
Evitar handshake completo para clientes recurrentes:
Session IDs (TLS 1.2)
El servidor proporciona session ID en ServerHello. El cliente reconecta con session ID en ClientHello. El servidor busca la sesión, reanuda con handshake abreviado (1 RTT). Estado de sesión almacenado en servidor (memoria o cache distribuido). Escalabilidad limitada.
Session Tickets (TLS 1.2)
El servidor encripta estado de sesión en un ticket, lo envía al cliente después del handshake. El cliente presenta el ticket en la siguiente conexión. El servidor desencripta el ticket, reanuda la sesión. Sin estado en servidor, escalable. Rotación de llaves de ticket requerida para forward secrecy.
Pre-Shared Key (PSK) (TLS 1.3)
TLS 1.3 unifica resumption bajo PSK. El cliente envía PSK identity en ClientHello. El servidor acepta PSK, deriva llaves más rápido. Puede combinarse con ECDHE para forward secrecy (PSK + ECDHE fresco). Soporta provisioning externo de PSK.
0-RTT Data (TLS 1.3)
El cliente envía datos de aplicación en el primer flight con PSK. Elimina latencia de handshake completamente para clientes conocidos. Datos rejugables (sin estado de servidor cuando se envían). Usar solo para requests idempotentes (GET requests, no POST). El servidor puede rechazar 0-RTT, requiriendo fallback a handshake 1-RTT.
Comparación TLS 1.2 vs TLS 1.3 Handshake
| Característica | TLS 1.2 | TLS 1.3 |
|---|---|---|
| RTT del handshake | 2 RTT | 1 RTT |
| Intercambio de llaves | RSA, DHE, ECDHE | Solo ECDHE |
| Forward secrecy | Opcional (RSA carece) | Obligatorio |
| Modos cipher | CBC, GCM, CCM | Solo AEAD (GCM, CCM, ChaCha20-Poly1305) |
| Encriptación de certificado | No (enviado en claro) | Sí (encriptado después de ServerHello) |
| Tiempo de negociación | 2 round trips | 1 round trip |
| Algoritmos legacy | Soportados | Removidos (intercambio RSA, CBC, compresión, renegotiation) |
| Resumption 0-RTT | No | Sí |
| Algoritmos de firma | RSA, ECDSA, DSA | RSA-PSS, ECDSA, EdDSA |
TLS 1.3 mejora seguridad eliminando algoritmos vulnerables, reduce latencia mediante handshake 1-RTT, y mejora privacidad encriptando certificados.
Cuándo Ocurre el TLS Handshake
El handshake TLS ocurre cuando:
- Un navegador conecta a un sitio web HTTPS
- Un cliente API llama a un endpoint HTTPS
- Un cliente de email envía vía SMTPS o recibe vía IMAPS/POP3S
- Un cliente SSH usa autenticación basada en certificado (no el mismo protocolo, pero conceptos similares)
- Cualquier conexión TCP se actualiza a TLS (STARTTLS para SMTP, IMAP)
El handshake TLS NO ocurre cuando:
- Conexión HTTP (sin encriptar, sin TLS)
- La conexión ya está establecida (conexiones HTTPS persistentes reutilizan sesión TLS)
- Session resuction tiene éxito (handshake abreviado)
- La aplicación usa protocolo en texto plano
Señales de Problemas de Handshake
- Errores de certificado: Expirado, hostname incorrecto, CA no confiable
- Desactualización de cipher suite: Cliente y servidor no comparten algoritmos comunes
- Desactualización de versión de protocolo: Cliente solo soporta TLS 1.3, servidor solo TLS 1.0
- Timeout de handshake: La red descarta ClientHello o ServerHello
- Advertencias de criptografía débil: Certificados SHA-1, llaves RSA pequeñas, ciphers desactualizados
- Degradación de rendimiento: Handshake completo en cada request (sin session resumption)
Métricas y Medición
Métricas de Rendimiento del Handshake:
- Tiempo de TLS handshake: Tiempo desde ClientHello hasta Finished (objetivo: <100ms local, <200ms regional)
- Tiempo de validación de certificado: Tiempo para verificar cadena de certificado (objetivo: <50ms)
- Tiempo de intercambio de llaves: Tiempo para computación ECDHE (objetivo: <10ms)
- Tiempo total de establecimiento de conexión: TCP + TLS handshake (objetivo: <300ms global)
Métricas de Seguridad:
- Distribución de versión TLS: Porcentaje de conexiones TLS 1.3 vs TLS 1.2 (objetivo: maximizar TLS 1.3)
- Fortaleza de cipher suite: Porcentaje de conexiones con forward secrecy (objetivo: 100%)
- Validez de certificado: Días hasta expiración, coincidencia apropiada de hostname
- Latencia de verificación OCSP/CRL: Tiempo para verificar revocación de certificado (objetivo: <50ms)
Según SSL Labs (2024), 78% de los sitios web soportan TLS 1.3. Tiempo promedio de TLS handshake para servidores bien configurados: 20-80ms. Servidores pobremente configurados (grupos DH pequeños, profundidad excesiva de cadena de certificado) ven tiempos de handshake de 200-500ms.
Casos de Uso Reales
Sitios de E-Commerce
- HTTPS para todas las páginas (protege login, datos de pago)
- Certificados EV muestran nombre de la empresa en el navegador
- Session resumption para conexiones repetidas rápidas
- Header HSTS fuerza HTTPS, previene ataques de downgrade
- Certificate pinning para apps móviles
APIs y Microservicios
- Mutual TLS (mTLS): Cliente y servidor autentican con certificados
- Certificados de corta duración vía automatización de certificados
- Service mesh emite y renueva certificados automáticamente
- API gateway termina TLS, reenvía a servicios backend
- Rotación de certificados sin reinicio de servicio
Content Delivery Networks
- TLS termination en ubicaciones edge (más cerca de usuarios, reduce RTT)
- Infraestructura TLS compartida entre clientes
- Session tickets para resumption sin estado a través de servidores edge
- OCSP stapling reduce latencia de validación de certificado
- Provisioning automático de certificados (integración Let’s Encrypt)
Aplicaciones Móviles
- TLS 1.3 para handshakes más rápidos en redes móviles de alta latencia
- Certificate pinning previene MITM con CA comprometida
- Session resumption crítico para duración de batería
- 0-RTT para obtención instantánea de datos (con garantías de idempotencia)
Aplicaciones Empresariales
- CA interna emite certificados para servicios internos
- Autenticación basada en certificado para arquitecturas zero-trust
- Inspección TLS por appliances de seguridad (break-and-inspect)
- mTLS para comunicación servicio-a-servicio
Errores Comunes y Soluciones
Error: Usar intercambio de llaves RSA (sin forward secrecy) en TLS 1.2 Solución: Configura el servidor para priorizar cipher suites ECDHE sobre RSA. Forward secrecy protege sesiones pasadas si la llave privada se compromete. Clientes modernos soportan ECDHE; prioriza cipher suites TLS_ECDHE_*. Transiciona a TLS 1.3 donde forward secrecy es obligatorio.
Error: No habilitar session resumption Solución: Habilita session tickets para resumption sin estado (escala mejor que session IDs). Configura rotación de llaves de ticket (cada 6-24 horas) para forward secrecy de sesiones reanudadas. TLS 1.3 usa resumption basado en PSK; asegúrate de que el servidor soporte. Monitorea tasa de éxito de resumption.
Error: Enviar profundidad excesiva de cadena de certificado Solución: Envía solo certificados intermedios necesarios (típicamente 1-2 intermedios). Root CA ya es confiable por el cliente; no la envíes. Cadenas grandes incrementan tamaño del handshake, latencia y tiempo de validación. Prueba con SSL Labs para verificar completitud de cadena sin redundancia.
Error: Usar cipher suites débiles o desactualizadas Solución: Deshabilita cipher suites con vulnerabilidades conocidas: RC4, 3DES, modo CBC con encriptación no autenticada, SHA-1. Prefiere ciphers AEAD (AES-GCM, ChaCha20-Poly1305). Configura el servidor para aplicar ordenamiento fuerte de cipher suites. Actualiza librerías TLS a últimas versiones.
Error: No implementar OCSP stapling Solución: Habilita OCSP stapling para reducir latencia de validación de certificado. El servidor “staples” respuesta OCSP al certificado, eliminando lookup OCSP del cliente. Reduce tiempo de handshake en 50-200ms. Previene fuga de privacidad del cliente consultando OCSP responder. La mayoría de servidores modernos soportan stapling.
Error: Ignorar adopción de TLS 1.3 Solución: Habilita TLS 1.3 para handshake 1-RTT, seguridad mejorada y configuración simplificada. Todos los navegadores modernos soportan TLS 1.3 (Chrome, Firefox, Safari, Edge). Monitorea estadísticas de versión TLS. El diseño de TLS 1.3 elimina clases enteras de vulnerabilidades.
Preguntas Frecuentes
¿Cuál es la diferencia entre SSL y TLS? SSL (Secure Sockets Layer) fue el protocolo original desarrollado por Netscape (SSL 1.0, 2.0, 3.0). TLS (Transport Layer Security) es el estándar sucesor IETF (TLS 1.0, 1.1, 1.2, 1.3). SSL tiene vulnerabilidades conocidas; todas las versiones están deprecadas. TLS es el estándar actual. Coloquialmente, “certificado SSL” se refiere a certificados X.509 usados en TLS.
¿Por qué el handshake TLS ocurre después del handshake TCP? TLS opera sobre TCP, requiriendo un transporte confiable. TCP establece conexión primero (SYN, SYN-ACK, ACK), luego el handshake TLS corre sobre esa conexión. Los registros TLS se transmiten en segmentos TCP. TCP proporciona confiabilidad; TLS proporciona seguridad. QUIC (HTTP/3) combina transporte y TLS en un solo handshake, reduciendo tiempo total de establecimiento.
¿Cómo sabe el cliente la llave pública del servidor? El servidor envía su certificado X.509 en el mensaje ServerHello. El certificado contiene la llave pública del servidor. El cliente valida la cadena de certificado hasta una root CA confiable. Si es válido, el cliente confía en la llave pública del certificado. Para ECDHE, el servidor firma ServerKeyExchange con llave privada; el cliente verifica la firma con llave pública del certificado.
¿Qué sucede si la validación del certificado falla? El cliente aborta el handshake, muestra error al usuario. Errores comunes: certificado expirado, desactualización de hostname, CA no confiable, certificado auto-firmado (no en trust store), certificado revocado. El usuario puede anular la advertencia (no recomendado para producción). Las aplicaciones deben fallar cerrado, no permitir continuar con certificado inválido.
¿Cómo logra TLS 1.3 handshake 1-RTT? El cliente TLS 1.3 envía key share en ClientHello (adivinando curva preferida del servidor). El servidor inmediatamente computa secreto compartido y envía respuesta encriptada. Elimina round trip de TLS 1.2 donde cliente esperaba ServerHello antes de enviar key share. TLS 1.3 también encripta certificado, reduciendo metadatos en texto plano.
¿Qué es forward secrecy y por qué importa? Forward secrecy significa que las llaves de sesión no pueden derivarse de la llave privada del servidor. ECDHE genera pares de llaves efímeros por sesión. Incluso si la llave privada del servidor se compromete después, las sesiones pasadas permanecen seguras. Sin forward secrecy (intercambio de llaves RSA), compromiso de llave privada desencripta todas las sesiones pasadas. Obligatorio en TLS 1.3.
¿Puede interceptarse el handshake TLS? Un atacante activo con certificado CA comprometido puede interceptar (man-in-the-middle). Certificate pinning previene esto validando certificado específico o llave pública. Atacantes pasivos no pueden desencriptar handshake debido a criptografía de intercambio de llaves. TLS 1.3 encripta más del handshake, reduciendo exposición de metadatos a observadores pasivos.
Cómo Aplica en la Práctica
Entender el TLS handshake es esencial para debuggear problemas HTTPS, optimizar rendimiento e implementar comunicaciones seguras.
Optimización de Rendimiento:
- Habilitar TLS 1.3 para handshake 1-RTT
- Configurar session tickets para resumption
- Usar OCSP stapling para reducir latencia de validación de certificado
- Optimizar cadena de certificado (remover intermediarios redundantes)
- Habilitar TLS False Start para TLS 1.2 (enviar datos antes de Finished)
- Terminar TLS en CDN edge para menor RTT
Hardening de Seguridad:
- Usar cipher suites fuertes (AEAD, ECDHE, SHA-256+)
- Habilitar TLS 1.3, deshabilitar TLS 1.0 y 1.1
- Usar certificados con RSA 2048+ bits o ECDSA 256+ bits
- Habilitar HSTS para forzar HTTPS
- Implementar certificate pinning para apps móviles
- Monitorear expiración de certificados proactivamente
Resolución de Problemas de Handshake:
- Usar openssl s_client para probar handshake:
openssl s_client -connect example.com:443 - Verificar configuración de cipher suite con prueba SSL Labs
- Verificar completitud de cadena de certificado
- Monitorear latencia de handshake y tasas de falla
- Verificar mixed content (recursos HTTP en página HTTPS)
- Probar con diferentes clientes (navegadores, curl, openssl)
TLS Handshake en Azion
Azion proporciona terminación TLS optimizada y gestión:
- Soporte TLS 1.3 para rendimiento de handshake más rápido
- Edge termination reduce RTT (usuarios conectan a ubicaciones edge cercanas)
- Certificados SSL gestionados con renovación automática
- OCSP stapling para latencia reducida de validación de certificado
- Encriptación de session ticket a través de red edge para resumption
- Configuración HSTS para enforcement de HTTPS
- Soporte mTLS para autenticación de API
- Gestión de Digital Certificates mediante Azion Console y API
La red global de Azion termina conexiones TLS en ubicaciones edge worldwide, minimizando latencia de handshake para usuarios finales mientras mantiene postura de seguridad fuerte.
Aprende más sobre Digital Certificates y mTLS vs TLS.
Sources
- Dierks, T., Rescorla, E. “RFC 5246: TLS 1.2.” IETF, 2008. https://tools.ietf.org/html/rfc5246
- Rescorla, E. “RFC 8446: TLS 1.3.” IETF, 2018. https://tools.ietf.org/html/rfc8446
- SSL Labs. “SSL Server Test.” https://www.ssllabs.com/ssltest/
- Rescorla, E. “The Transport Layer Security (TLS) Protocol Version 1.3.” IETF, 2018. https://www.rfc-editor.org/rfc/rfc8446