SSL funciona en dos fases: primero un "handshake" (apretón de manos) donde cliente y servidor se autentican y acuerdan una clave de cifrado compartida; luego, el intercambio de datos cifrado con esa clave. Todo ocurre en milisegundos, antes de que se cargue cualquier byte de la página.
Entender cómo funciona SSL no solo satisface la curiosidad técnica; te ayuda a tomar mejores decisiones sobre configuración de servidores, selección de algoritmos y diagnóstico de errores de conexión.
Los dos ingredientes básicos: cifrado simétrico y asimétrico
Antes de ver el handshake, conviene entender los dos tipos de cifrado que SSL combina:
Cifrado asimétrico (clave pública/privada)
Usa un par de claves matemáticamente relacionadas: la clave pública (que cualquiera puede conocer) y la clave privada (que solo el servidor guarda en secreto). Lo que se cifra con una, solo se puede descifrar con la otra. Es muy seguro, pero lento computacionalmente.
Cifrado simétrico (clave de sesión)
Usa la misma clave para cifrar y descifrar. Es mucho más rápido que el asimétrico, pero requiere que ambas partes compartan la clave de forma segura antes de usarla.
SSL combina ambos: usa el cifrado asimétrico (lento pero seguro) para intercambiar la clave simétrica (rápida), y luego usa esa clave simétrica para cifrar todos los datos de la sesión.
El TLS handshake paso a paso
Cuando tu navegador se conecta a https:// de cualquier sitio, ocurre lo siguiente en décimas de segundo:
Paso 1: ClientHello
El navegador envía un mensaje ClientHello con:
- La versión de TLS más alta que soporta (ej. TLS 1.3).
- Una lista de cipher suites (combinaciones de algoritmos) que acepta.
- Un número aleatorio llamado client random.
Paso 2: ServerHello + Certificado
El servidor responde con:
- La versión de TLS y la cipher suite elegida.
- Un número aleatorio llamado server random.
- Su certificado SSL, que contiene su clave pública y está firmado por una Autoridad Certificadora (CA) de confianza.
Paso 3: Verificación del certificado
El navegador verifica que el certificado:
- Fue emitido por una CA de confianza (incluida en su lista de raíces).
- No ha expirado ni fue revocado.
- Corresponde exactamente al dominio al que nos estamos conectando.
Si alguna verificación falla, el navegador muestra una advertencia de seguridad y detiene la conexión.
Paso 4: Intercambio de clave (Key Exchange)
Aquí es donde la magia ocurre. Dependiendo de la cipher suite acordada:
- En TLS 1.2: el navegador genera un pre-master secret, lo cifra con la clave pública del servidor y lo envía. Solo el servidor puede descifrarlo con su clave privada.
- En TLS 1.3: se usa el algoritmo Diffie-Hellman efímero (ECDHE), que permite generar la clave compartida sin enviarla directamente. Esto añade forward secrecy: aunque alguien capture la clave privada del servidor en el futuro, no podrá descifrar sesiones pasadas.
Paso 5: Generación de claves de sesión
Usando el client random, el server random y el secreto compartido del paso anterior, ambas partes generan de forma independiente las mismas claves de sesión simétricas. El proceso es determinístico: si tienen los mismos insumos, obtienen el mismo resultado, sin necesidad de enviarse las claves.
Paso 6: Finished — canal seguro establecido
Ambas partes envían un mensaje Finished cifrado con las nuevas claves de sesión, verificando que todo salió bien. A partir de aquí, toda la comunicación usa cifrado simétrico (AES-GCM en configuraciones modernas).
Si quieres profundizar en configuración de certificados o necesitas ayuda para habilitar TLS 1.3 en tu servidor, los especialistas de elenlace.com pueden hacerlo por ti.
Algoritmos modernos: qué buscar en tu configuración
No todos los algoritmos son igual de seguros. Esta tabla resume las opciones actuales:
| Función | Recomendado | Evitar |
|---|---|---|
| Protocolo | TLS 1.3, TLS 1.2 | SSL 3.0, TLS 1.0, TLS 1.1 |
| Intercambio de clave | ECDHE (X25519, P-256) | RSA estático (sin forward secrecy) |
| Cifrado simétrico | AES-256-GCM, ChaCha20-Poly1305 | RC4, DES, 3DES |
| Hash / firma | SHA-256, SHA-384 | MD5, SHA-1 |
TLS 1.0 y 1.1 están oficialmente deprecados por el IETF desde 2021 y bloqueados en los navegadores modernos. Si tu servidor aún los soporta, es hora de actualizarlo.
¿Qué es el forward secrecy y por qué importa?
El forward secrecy (secreto hacia adelante) garantiza que, aunque alguien robe la clave privada del servidor mañana, no podrá descifrar las sesiones de hoy. Lo logra generando claves de sesión efímeras (que se descartan al terminar la conexión) mediante algoritmos como ECDHE.
Sin forward secrecy, un atacante que grabe tráfico cifrado hoy podría descifrarlo más tarde si obtiene la clave privada. Con forward secrecy, cada sesión es independiente y su compromiso no afecta a las demás.
TLS 1.3 obliga al uso de cipher suites con forward secrecy, eliminando los métodos que no lo garantizan. Es otra razón importante para desactivar TLS 1.2 o al menos configurarlo solo con cipher suites ECDHE.
Consulta más recursos sobre protocolos y cifrado en nuestra sección de seguridad SSL.
Conclusiones clave
- SSL/TLS usa cifrado asimétrico para el handshake y cifrado simétrico para los datos de sesión, combinando seguridad y velocidad.
- El handshake TLS consta de seis pasos: ClientHello, ServerHello + certificado, verificación, intercambio de clave, generación de claves de sesión y Finished.
- TLS 1.3 es el estándar actual: más rápido (un viaje de ida y vuelta en lugar de dos) y más seguro (forward secrecy obligatorio).
- Los algoritmos que debes buscar son ECDHE para el intercambio de clave, AES-GCM o ChaCha20 para el cifrado y SHA-256+ para los hashes.
- El forward secrecy garantiza que el compromiso futuro de una clave no expone sesiones pasadas.
¿Quieres asegurarte de que tu servidor está configurado con los algoritmos modernos correctos? Contáctanos en elenlace.com y auditamos tu configuración TLS sin costo inicial.
Preguntas frecuentes
¿El handshake TLS ralentiza mi sitio web?
En TLS 1.3, el handshake completo requiere solo un viaje de ida y vuelta (1-RTT) y puede incluso completarse en cero viajes si el navegador reconoce el servidor (0-RTT). El impacto en la latencia es de decenas de milisegundos, imperceptible para el usuario. HTTP/2 y HTTP/3 sobre TLS en realidad aceleran la carga total gracias a la multiplexación.
¿Dónde se guarda la clave privada del servidor?
En el servidor web, generalmente en un directorio protegido que solo el usuario del proceso web puede leer (por ejemplo /etc/ssl/private/ en Linux). La clave privada nunca debe transmitirse ni exponerse. Si se ve comprometida, hay que revocar el certificado y generar uno nuevo.
¿Qué es una Autoridad Certificadora (CA)?
Es una entidad de confianza que verifica la identidad del dueño de un dominio (o de una empresa) y emite el certificado SSL firmado digitalmente. Los navegadores incluyen una lista de CAs raíz de confianza; si el certificado de un sitio fue firmado por una de ellas, el navegador lo acepta automáticamente. Ejemplos: Let's Encrypt, DigiCert, Sectigo.
¿Puedo ver el handshake TLS en acción?
Sí. En las DevTools de Chrome o Firefox, ve a la pestaña Security para ver detalles del certificado y la cipher suite usada. Para un análisis completo, usa el comando openssl s_client -connect tudominio.com:443 -tls1_3 desde la terminal, que imprime cada fase del handshake en texto plano.
Para saber más
Otros proveedores y guías que vale la pena comparar:
