Cómo funcionan realmente HTTPS y TLS: handshake explicado

Escribiste https:// delante de una URL, viste el candado y seguiste adelante. Pero cuando un certificado caduca a las 2 de la mañana, una advertencia de contenido mixto rompe tu página de pago, o un cliente pregunta por qué su llamada a la API falla con un error de TLS, "el candado significa que es seguro" deja de ser una respuesta útil. Este artículo explica qué ocurre realmente en el cable durante una conexión HTTPS y cómo configurarla sin conjeturas.

Qué añade HTTPS a HTTP

HTTPS es HTTP simple transportado dentro de una sesión TLS (Transport Layer Security). TLS proporciona tres garantías concretas:

• Confidencialidad — el tráfico está cifrado, por lo que los intermediarios no pueden leerlo.
• Integridad — se detecta cualquier manipulación en tránsito y la conexión falla.
• Autenticación — el servidor demuestra que controla la clave privada del certificado presentado.

Fíjate en lo que no está en esa lista: HTTPS no dice nada sobre si el servidor es confiable, si la aplicación tiene vulnerabilidades o si los datos están seguros en reposo. Protege el canal, no los extremos.

El handshake TLS, paso a paso

El handshake es la negociación que ocurre antes de que fluya cualquier byte HTTP. En TLS 1.3 requiere un solo viaje de ida y vuelta; TLS 1.2 necesita dos. Este es el flujo de TLS 1.3 en términos sencillos:

1. ClientHello — el cliente envía las versiones de TLS compatibles, una lista de suites de cifrado, un nonce aleatorio y una parte de clave para un intercambio de claves Diffie-Hellman (típicamente X25519).
2. ServerHello — el servidor elige una versión y una suite de cifrado, devuelve su propia parte de clave y envía su cadena de certificados junto con una firma sobre la transcripción del handshake.
3. Derivación de claves — ambos lados calculan el secreto compartido a partir del intercambio Diffie-Hellman. Las claves efímeras hacen que la clave de sesión sea única y se mantenga el secreto perfecto hacia adelante: comprometer la clave a largo plazo del servidor más tarde no descifra el tráfico grabado.
4. Finished — ambos lados envían un MAC sobre la transcripción. Si algo fue alterado, el handshake se aborta.
5. Datos de aplicación — las solicitudes y respuestas HTTP se cifran con claves simétricas derivadas del secreto compartido.

El certificado es donde reside la autenticación. El servidor firma el handshake con su clave privada; el cliente verifica esa firma usando la clave pública del certificado, luego verifica el certificado en sí contra una CA raíz de confianza, comprobando el nombre de host, las fechas de validez y el estado de revocación.

Simétrico vs asimétrico: por qué se usan ambos

La criptografía asimétrica (RSA o ECDSA) es lenta pero resuelve la distribución de claves. Los cifrados simétricos (AES-GCM, ChaCha20-Poly1305) son rápidos pero requieren una clave compartida. TLS usa criptografía asimétrica solo durante el handshake para establecer una clave de sesión simétrica, y luego cifra los datos masivos con esa clave. Por eso una conexión TLS 1.3 moderna es rápida: un viaje de ida y vuelta, y luego AES o ChaCha20 baratos para todo lo demás.

Suites de cifrado y qué importa realmente

Una suite de cifrado es un paquete con nombre de algoritmos. En TLS 1.3 la lista es corta y todas las opciones se consideran seguras; en TLS 1.2 debes elegir con cuidado. Una comparación rápida:

Conclusión práctica: habilita solo TLS 1.2 y 1.3, desactiva TLS 1.0/1.1 y prefiere certificados ECDSA para un menor coste de handshake. Deja que tu servidor o proxy inverso elija el orden de las suites; la mayoría de los valores predeterminados son sensatos en software de la era 2024.

Cómo inspeccionar una conexión real

No necesitas confiar en la documentación: verifica tus propios endpoints. openssl s_client muestra la versión negociada, el cifrado y la cadena de certificados:

openssl s_client -connect example.com:443 -servername example.com -tls1_3 </dev/null

Observa las líneas Protocol y Cipher, luego revisa la salida de la cadena de certificados para ver la caducidad y las entradas SAN. Si la cadena está incompleta, algunos clientes fallarán mientras que los navegadores tendrán éxito, lo cual es una fuente clásica de errores del tipo "funciona en Chrome pero no en curl".

Errores comunes de configuración de HTTPS

• Certificado intermedio faltante — el servidor envía solo su certificado hoja. Los navegadores pueden obtener el intermedio, pero los clientes de API a menudo no lo harán.
• Contenido mixto — una página HTTPS carga un script o una imagen por HTTP; los navegadores lo bloquean o lo degradan. Audítalo con la consola de tu navegador.
• Sin HSTS — sin Strict-Transport-Security, una primera solicitud por HTTP puede ser interceptada antes de que ocurra la redirección.
• Versiones de protocolo débiles u obsoletas — dejar TLS 1.0 habilitado para un cliente heredado debilita silenciosamente cada conexión.
• Caducidad del certificado — automatiza la renovación; un recordatorio manual en el calendario no es una estrategia.

Una configuración de servidor razonable

Para Nginx, un bloque moderno mínimo se ve así:

server {
    listen 443 ssl http2;
    server_name example.com;

    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_prefer_server_ciphers off;
    ssl_session_cache shared:SSL:10m;
    ssl_session_timeout 1d;

    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
}

El archivo fullchain.pem es lo que evita el problema del intermedio faltante. Mantén la redirección desde el puerto 80 en un bloque de servidor separado para que HTTP siga funcionando para los desafíos ACME.

Qué no protege HTTPS

Una vez que la solicitud llega a tu servidor, TLS ha terminado. Las fallas de inyección, el control de acceso roto, los secretos filtrados en los registros y CORS mal configurado viven por encima de la capa de transporte. Trata TLS como la línea base, no como el programa de seguridad. Si estás depurando un incidente, separa temprano los problemas de transporte (fallos de handshake, certificados caducados) de los problemas de aplicación (errores 500, payloads incorrectos) — tienen soluciones completamente diferentes.

Preguntas frecuentes

¿HTTPS cifra la ruta URL y la cadena de consulta?

Sí. En HTTPS, toda la solicitud HTTP, incluida la ruta y la cadena de consulta, está dentro del registro TLS cifrado. Sin embargo, el nombre de host (SNI) y la IP de destino son visibles durante el handshake a menos que se use Encrypted Client Hello.

¿Es TLS 1.3 siempre más rápido que TLS 1.2?

Por lo general, sí, porque ahorra un viaje de ida y vuelta y admite la reanudación 0-RTT. En conexiones de alta latencia la diferencia es notable; en una red local es menor. La mayor ventaja es que TLS 1.3 elimina por completo las opciones de cifrado heredadas.

¿Todavía necesito HSTS si redirijo HTTP a HTTPS?

Sí. Una redirección solo ayuda después de que el navegador ha llegado a tu servidor. HSTS le dice al navegador que omita HTTP por completo para futuras solicitudes, cerrando la ventana en la que una primera solicitud podría ser interceptada.

Cuando estés auditando un despliegue y necesites verificar los detalles del certificado o decodificar un handshake capturado rápidamente, mantén a mano un flujo de trabajo basado en terminal — y si estás documentando los hallazgos para un equipo, el editor de Markdown es una forma rápida de convertir la salida cruda de openssl en un informe legible.