Cómo funcionan realmente HTTPS y TLS: el handshake explicado

Escribes una URL, pulsas Enter y aparece un candado. Pero, ¿qué ocurre realmente entre tu navegador y el servidor para que esa conexión sea segura? Muchos desarrolladores tratan HTTPS como una caja negra, hasta que algo falla, como un error de certificado o un problema de rendimiento. Este artículo corre el telón sobre TLS, el protocolo detrás de HTTPS, y explica el handshake en términos sencillos.

Qué es realmente HTTPS

HTTPS es simplemente HTTP sobre TLS (Transport Layer Security). TLS proporciona tres garantías:

• Confidencialidad: los datos se cifran para que los espías no puedan leerlos.
• Integridad: los datos no pueden modificarse en tránsito sin ser detectados.
• Autenticación: estás hablando con el servidor real, no con un impostor.

Sin TLS, HTTP envía todo en texto plano: contraseñas, cookies y datos de formularios son visibles para cualquiera en la ruta de red.

El handshake de TLS en lenguaje sencillo

El handshake es la negociación que ocurre antes de enviar cualquier dato de aplicación. Su objetivo: acordar algoritmos de cifrado, verificar la identidad del servidor y establecer claves secretas compartidas. Este es el flujo para TLS 1.3, el estándar moderno:

1. Client Hello: el navegador envía una lista de suites de cifrado admitidas, un valor aleatorio y su clave pública (para el intercambio de claves).
2. Server Hello: el servidor elige una suite de cifrado, envía su propio valor aleatorio y clave pública, y proporciona su cadena de certificados.
3. Verificación del certificado: el navegador comprueba el certificado contra las CA raíz de confianza, valida el nombre de dominio y verifica la fecha de caducidad.
4. Derivación de claves: ambas partes calculan el mismo secreto compartido usando el intercambio de claves (típicamente ECDHE). Se derivan las claves de sesión.
5. Finished: ambas partes envían un MAC sobre la transcripción del handshake para confirmar que nada ha sido manipulado.

Después de eso, fluyen los datos de aplicación cifrados. En TLS 1.3, el handshake requiere un viaje de ida y vuelta (1-RTT), y la reanudación puede lograr 0-RTT.

TLS 1.2 vs TLS 1.3

TLS 1.2 requería dos viajes de ida y vuelta y admitía algoritmos más débiles. TLS 1.3 eliminó cifrados obsoletos, simplificó el handshake y cifra más parte del propio handshake. Prefiere siempre TLS 1.3; la mayoría de los servidores y navegadores modernos lo admiten.

Certificados: el ancla de confianza

Un certificado vincula una clave pública a un nombre de dominio y está firmado por una Autoridad de Certificación (CA). Los navegadores incluyen un almacén de CA raíz de confianza. Durante la verificación, el navegador construye una cadena desde el certificado del servidor hasta una raíz de confianza.

Tipos comunes de certificados:

• DV (Validación de Dominio): demuestra el control del dominio; rápido y gratuito (por ejemplo, Let's Encrypt).
• OV (Validación de Organización): incluye detalles verificados de la empresa.
• EV (Validación Extendida): comprobaciones de identidad más estrictas; ya no muestra una barra verde en la mayoría de los navegadores.

Los certificados caducan. Automatiza la renovación con clientes ACME como Certbot para evitar interrupciones.

Intercambio de claves y secreto directo perfecto

TLS moderno utiliza intercambio de claves efímero (ECDHE). Cada sesión genera un nuevo par de claves, de modo que incluso si la clave privada del servidor se ve comprometida posteriormente, las sesiones pasadas no pueden descifrarse. Esta propiedad se llama secreto directo (forward secrecy). Evita el intercambio de claves RSA estático, que carece de esta protección.

Errores comunes de HTTPS y cómo evitarlos

• Contenido mixto: cargar recursos HTTP en una página HTTPS provoca advertencias del navegador. Usa URLs relativas o actualiza a HTTPS.
• Certificados caducados: configura monitorización y renovación automática.
• Suites de cifrado débiles: desactiva TLS 1.0/1.1 y RC4/3DES. Usa una herramienta como SSL Labs para probar.
• Falta de HSTS: añade el encabezado Strict-Transport-Security para forzar HTTPS.

Depurar problemas de TLS

Cuando falla un handshake, usa openssl s_client para inspeccionar la conexión:

openssl s_client -connect example.com:443 -servername example.com

Esto muestra la cadena de certificados, el protocolo negociado y el cifrado. Para errores específicos del navegador, revisa el panel de Seguridad en DevTools.

Preguntas frecuentes

¿Es HTTPS lo mismo que TLS?

HTTPS es HTTP sobre TLS. TLS es el protocolo criptográfico; HTTPS es la versión segura del protocolo de aplicación HTTP.

¿Necesito un certificado separado para cada subdominio?

No necesariamente. Un certificado comodín cubre todos los subdominios de primer nivel, y un certificado multidominio (SAN) puede listar varios nombres.

¿Cómo mejora TLS 1.3 el rendimiento?

TLS 1.3 reduce el handshake a un viaje de ida y vuelta (y cero en la reanudación), y simplifica la negociación de cifrado, reduciendo la latencia.

¿Listo para inspeccionar la seguridad de tu propio sitio? Usa nuestro analizador de logs de Nginx para detectar errores TLS sospechosos y fallos de handshake en tus logs.