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

Añadiste un certificado, el navegador muestra un candado y sigues adelante. Luego, un día, un cliente API falla con SSL_ERROR_RX_RECORD_TOO_LONG, una aplicación móvil rechaza tu cadena o aparece un bucle de redirección tras habilitar HSTS. De repente, HTTPS parece una caja negra.

Este artículo abre esa caja. Veremos qué ocurre realmente durante un handshake TLS, por qué existen los certificados, dónde encaja la encriptación simétrica y asimétrica, y cómo depurar los fallos que encontrarás de forma realista en producción.

Qué es realmente HTTPS

HTTPS no es un protocolo separado. Es HTTP simple enviado sobre una conexión cifrada con TLS. El esquema de la URL cambia, el puerto por defecto pasa de 80 a 443, y todo lo demás —métodos, cabeceras, códigos de estado, cookies— se comporta igual.

TLS te proporciona tres garantías sobre TCP:

• Confidencialidad: los intermediarios no pueden leer el tráfico.
• Integridad: se detecta cualquier manipulación en tránsito.
• Autenticación: el cliente puede verificar que habla con el servidor que posee el dominio.

Esa tercera garantía es la que la gente subestima. El cifrado sin autenticación no sirve de nada: un atacante que pueda interceptar el tráfico podría simplemente presentar su propia clave.

El handshake de TLS 1.3, paso a paso

TLS 1.3 simplificó drásticamente el handshake en comparación con TLS 1.2. Este es el flujo entre un navegador y un servidor:

1. ClientHello: el cliente envía las versiones de TLS compatibles, las suites de cifrado, un valor aleatorio y una clave compartida para un grupo Diffie-Hellman (por ejemplo, X25519).
2. ServerHello: el servidor elige una suite de cifrado y envía su propia clave compartida. Ambos lados pueden ahora derivar el mismo secreto compartido.
3. Extensiones cifradas y certificado: el servidor envía su cadena de certificados, ya cifrada con las claves derivadas.
4. Finished: ambos lados envían un MAC sobre la transcripción del handshake para demostrar que nada ha sido manipulado.
5. Datos de aplicación: las peticiones y respuestas HTTP fluyen sobre la sesión establecida.

En TLS 1.3, el handshake completo cuesta un round trip, y la reanudación puede alcanzar cero round trips. TLS 1.2 necesitaba dos round trips antes de que pudieran fluir datos de aplicación.

Por qué el certificado se envía después de derivar las claves

En TLS 1.3 el certificado está cifrado. Eso significa que un observador pasivo no puede ver siquiera qué dominio visita el cliente solo a partir del certificado, lo que reduce la fuga de información. También significa que las herramientas de depuración que esperan un certificado en texto plano en los primeros paquetes se confundirán.

Encriptación simétrica vs asimétrica

Un error común es creer que HTTPS cifra todo con la clave pública del servidor. No es así. La criptografía asimétrica es lenta y limitada en tamaño; solo se usa para establecer un secreto compartido.

El intercambio de claves Diffie-Hellman tiene una propiedad valiosa llamada secreto perfecto hacia adelante (forward secrecy): incluso si la clave privada del servidor se filtra después, las sesiones pasadas grabadas no pueden descifrarse, porque las claves de sesión nunca se derivaron de esa clave a largo plazo.

Qué contiene un certificado

Un certificado X.509 vincula una clave pública a un nombre de dominio. Contiene:

• El sujeto (dominio) y los nombres alternativos del sujeto (SAN), que es lo que los navegadores realmente comprueban.
• La clave pública y su algoritmo.
• El período de validez.
• El emisor y una firma de ese emisor.

Los navegadores confían en un conjunto fijo de autoridades de certificación raíz. Tu servidor envía un certificado intermedio, y el navegador construye una cadena desde tu certificado final hasta una raíz de confianza. Si falta el intermedio, los navegadores de escritorio pueden seguir funcionando porque almacenan en caché los intermedios, mientras que los clientes móviles y las herramientas de línea de comandos fallan. Este es el error de TLS en producción más común.

Pasos prácticos de depuración

Cuando HTTPS falla, trabaja desde fuera hacia dentro.

1. Comprueba la cadena con openssl s_client -connect example.com:443 -servername example.com -showcerts. Confirma que el servidor envía la cadena completa, no solo el certificado final.
2. Comprueba la caducidad: los certificados caducados producen fallos graves sin solución alternativa.
3. Comprueba el nombre de host: la lista de SAN debe contener el nombre de host exacto que solicita el cliente, incluido cualquier prefijo www.
4. Comprueba la versión del protocolo: si un cliente heredado solo admite TLS 1.0 y tu servidor requiere TLS 1.2 o superior, el handshake falla antes de HTTP.
5. Comprueba las redirecciones: una redirección de HTTPS a HTTP y de vuelta crea un bucle; corrígelo en la configuración del servidor, no en el código de la aplicación.

# Inspeccionar la cadena de certificados y el protocolo negociado
openssl s_client -connect example.com:443 \
  -servername example.com -showcerts < /dev/null 2>&1 | \
  openssl x509 -noout -subject -issuer -dates

# Probar una versión específica de TLS
openssl s_client -connect example.com:443 -tls1_2 < /dev/null

En Nginx, la directiva ssl_certificate debe apuntar a un archivo que contenga el certificado final seguido del intermedio, en ese orden. Concatenarlos en el orden incorrecto produce errores de cadena que son fáciles de pasar por alto.

HSTS y el coste de equivocarse

HTTP Strict Transport Security indica a los navegadores que usen HTTPS para un dominio durante un período determinado. Es potente e implacable: una vez que un navegador ha visto un max-age largo, rechazará HTTP simple incluso si más tarde desactivas HTTPS en el servidor.

Empieza con un max-age corto, verifica que todo funciona y luego auméntalo. Añade includeSubDomains solo después de que todos los subdominios sirvan HTTPS válido. La precarga es efectivamente permanente: solo solicítala cuando estés seguro.

Errores de configuración comunes

• Contenido mixto: una página HTTPS que carga scripts o imágenes por HTTP. Los navegadores bloquean el contenido mixto activo y advierten sobre el pasivo.
• Suites de cifrado débiles: dejar habilitados cifrados en modo CBC y versiones antiguas del protocolo por compatibilidad que ya no necesitas.
• Falta de manejo de OCSP o CRL: la comprobación de revocación no es fiable en la práctica; los certificados de corta duración son la respuesta más robusta.
• Brechas en la automatización de certificados: la renovación funciona, pero falta el paso de recarga que hace que el servidor tome el nuevo certificado.

Trata la renovación de certificados como un pipeline de despliegue, no como un recordatorio en el calendario. Si la renovación requiere una persona, eventualmente fallará en el peor momento.

Preguntas frecuentes

¿HTTPS cifra el nombre de dominio que visito?

El dominio aparece en la extensión SNI de TLS y normalmente es visible en la red. La ruta y la cadena de consulta están cifradas, pero un observador de red puede ver típicamente a qué host te conectaste.

¿Por qué mi sitio funciona en un navegador pero falla en curl o en una aplicación móvil?

Casi siempre es un certificado intermedio faltante. Los navegadores a menudo almacenan en caché los intermedios de visitas anteriores, mientras que curl y muchas pilas HTTP móviles requieren que el servidor envíe la cadena completa.

¿TLS 1.3 es siempre mejor que TLS 1.2?

Para clientes modernos, sí: menos round trips, un conjunto de suites de cifrado más pequeño y secreto perfecto hacia adelante por defecto. Mantén TLS 1.2 habilitado solo si aún atiendes a clientes que no pueden negociar 1.3.

Cuando necesites inspeccionar los logs de los servidores que terminan TLS, un rápido repaso con el analizador de logs de Nginx te ayuda a detectar fallos de handshake, bucles de redirección y comportamientos inusuales de clientes antes de que se conviertan en caídas del servicio.