🤝 El handshake TLS, paso a paso
Cada vez que ves el candado del navegador, acaba de ocurrir esto en milisegundos: un handshake que acuerda una clave secreta sin enviarla nunca y comprueba que el servidor es quien dice ser. Recórrelo paso a paso (TLS 1.3).
El intercambio, mensaje a mensaje
-
01 ClientHello
ClientHello — «esto es lo que soporto»
El cliente propone las versiones de TLS y los cifrados que entiende, los grupos de curva y —lo importante— su key share: una clave pública efímera (ECDHE). Incluye el SNI: a qué dominio quiere conectarse.
Va en claro. El SNI revela el dominio de destino (la extensión ECH lo cifra). -
02 ServerHello
ServerHello — elige cifrado y comparte su clave
El servidor elige un cifrado de la lista y envía su propia key share. Con la clave pública del otro, cada lado deriva el mismo secreto compartido (ECDHE) — y ese secreto no viaja nunca por la red.
A partir de aquí todo el handshake va cifrado con claves derivadas de ese secreto. -
03 {EncryptedExtensions} 🔒
EncryptedExtensions
Parámetros de la conexión —por ejemplo el protocolo de aplicación (ALPN: HTTP/2, HTTP/3…)—, ya cifrados.
En TLS 1.2 esto viajaba en claro; en 1.3, no. -
04 {Certificate} 🔒
Certificate — «esta es mi identidad»
El servidor envía su certificado (una cadena X.509) firmado por una Autoridad de Certificación (CA) en la que tu sistema ya confía.
Cifrar sin autenticar no basta: sin esto, un intermediario podría suplantar al servidor. -
05 {CertificateVerify} 🔒
CertificateVerify — la prueba de posesión
El servidor firma todo el diálogo hasta aquí con la clave privada del certificado. Solo quien posee esa clave puede generar esa firma.
Ata el certificado a esta conexión concreta: tener el certificado no basta, hay que poseer su clave privada. -
06 {Finished} 🔒
Finished (servidor) — sello de integridad
Un código de autenticación (MAC) sobre todo el handshake: garantiza que nada se ha manipulado por el camino.
Si un atacante hubiera alterado un mensaje anterior, este sello no cuadra y la conexión se aborta. -
07 {Finished} 🔒
Finished (cliente) — handshake completo
El cliente valida el certificado (la cadena hasta una CA de confianza y la firma) y responde con su propio Finished. Todo en una sola vuelta (1-RTT).
Si el certificado no es de confianza o no corresponde al dominio, aquí es donde el navegador muestra la advertencia. -
08 Application Data 🔒
Canal cifrado establecido 🔒
Cliente y servidor ya intercambian los datos de aplicación (tu HTTP) cifrados con las claves de sesión derivadas.
Forward secrecy: las claves efímeras se descartan. Si mañana roban la clave privada del servidor, el tráfico de hoy sigue sin poder descifrarse.
Sin JavaScript verás el handshake completo como artículo. Con JS, recórrelo paso a paso (también con las flechas ← →).
🔑 La clave que no viaja
En ECDHE, cada lado manda su clave pública y guarda la privada. Combinando la pública del otro con la propia privada, ambos llegan al mismo secreto — que nunca cruza la red. Como son claves efímeras (una por sesión), hay forward secrecy.
🪪 Cifrar no es autenticar
Un canal cifrado con el atacante no sirve de nada. El certificado (firmado por una CA) dice quién es el servidor, y CertificateVerify demuestra que posee la clave privada. Sin ese par, un intermediario podría colarse.
⚡ TLS 1.3 vs 1.2
TLS 1.3 cierra el handshake en una vuelta (1-RTT, antes dos), cifra el certificado y solo admite cifrados con forward secrecy. Menos latencia y menos superficie: adiós a RSA para el intercambio de claves y a cifrados heredados.
Fuente: RFC 8446 (TLS 1.3). ¿Quieres ver el certificado y la postura TLS de un dominio real? Prueba el scorecard de seguridad.