Cómo funcionan realmente HTTPS y TLS: Guía práctica

Escribes una URL, presionas Enter y la página se carga. El ícono del candado te indica que la conexión es segura, pero ¿qué sucede realmente entre tu navegador y el servidor? Si eres desarrollador, entender HTTPS y TLS no es solo algo académico: afecta cómo configuras servidores, depuras errores de conexión y proteges los datos de los usuarios.

Esta guía desglosa el handshake TLS, las capas de cifrado y la validación de certificados en términos sencillos. Verás cómo funciona HTTPS realmente y obtendrás consejos prácticos para tus propios proyectos.

Qué son realmente HTTPS y TLS

HTTPS es HTTP sobre TLS. TLS (Transport Layer Security) es el protocolo criptográfico que cifra los datos en tránsito. Cuando visitas una URL HTTPS, tu navegador y el servidor realizan un handshake TLS para acordar claves de cifrado antes de que se intercambie cualquier dato HTTP.

TLS reemplazó a SSL (Secure Sockets Layer) hace años, pero los términos se usan a menudo indistintamente. Los navegadores modernos admiten TLS 1.2 y TLS 1.3; las versiones anteriores están obsoletas debido a vulnerabilidades conocidas.

El handshake TLS: paso a paso

El handshake establece un canal seguro. Esto es lo que sucede en un handshake TLS 1.2 típico (TLS 1.3 lo simplifica aún más):

1. Client Hello: El navegador envía una lista de suites de cifrado compatibles, versiones de TLS y un valor aleatorio (client random).
2. Server Hello: El servidor elige una suite de cifrado, envía su propio valor aleatorio (server random) y presenta su certificado SSL/TLS.
3. Verificación del certificado: El navegador verifica el certificado contra las CA raíz de confianza, comprueba el nombre de dominio y verifica la expiración.
4. Intercambio de claves: Usando la clave pública del certificado, el cliente cifra un pre-master secret y lo envía al servidor. Ambos lados derivan las mismas claves de sesión.
5. Finished: Ambas partes envían un mensaje Finished cifrado con las nuevas claves de sesión, confirmando que el handshake se realizó con éxito.

En TLS 1.3, el handshake se reduce a un viaje de ida y vuelta (1-RTT) y admite la reanudación 0-RTT para conexiones repetidas, mejorando la latencia.

Cifrado: simétrico y asimétrico

TLS utiliza ambos tipos de cifrado:

• Cifrado asimétrico (por ejemplo, RSA, ECDHE) se utiliza durante el handshake para intercambiar claves de forma segura. Es lento pero resuelve el problema de distribución de claves.
• Cifrado simétrico (por ejemplo, AES-GCM, ChaCha20-Poly1305) se utiliza para la transferencia masiva de datos después del handshake. Es rápido y eficiente.

Las claves de sesión derivadas durante el handshake son claves simétricas. Garantizan que incluso si alguien captura el tráfico cifrado, no pueda descifrarlo sin las claves.

Validación de certificados: confiar pero verificar

Los certificados son emitidos por Autoridades de Certificación (CA). Los navegadores y sistemas operativos incluyen una lista de CA raíz de confianza. Cuando un servidor presenta un certificado, el navegador verifica:

• Que el certificado esté firmado por una CA de confianza (directamente o a través de una CA intermedia).
• Que el nombre de dominio del certificado coincida con el host solicitado.
• Que el certificado esté dentro de su período de validez.
• Que el certificado no haya sido revocado (mediante CRL u OCSP).

Si alguna comprobación falla, el navegador muestra una advertencia. Como desarrollador, puedes usar herramientas como openssl s_client para inspeccionar certificados y depurar problemas de cadena.

Errores comunes de configuración de TLS y cómo solucionarlos

Utiliza verificadores SSL en línea o herramientas de línea de comandos para auditar tu configuración regularmente.

Consejos prácticos para desarrolladores

• Habilitar HSTS: Agrega el encabezado Strict-Transport-Security para forzar a los navegadores a usar HTTPS en visitas futuras.
• Usar TLS 1.3: Es más rápido y seguro. La mayoría de los servidores modernos lo admiten; configura tu servidor para preferirlo.
• Automatizar la gestión de certificados: Herramientas como Certbot pueden obtener y renovar certificados automáticamente.
• Probar con openssl: Ejecuta openssl s_client -connect example.com:443 -servername example.com para inspeccionar el handshake y la cadena de certificados.

Aquí tienes un fragmento de configuración rápida de Nginx para habilitar ajustes TLS modernos:

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_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256';
    ssl_prefer_server_ciphers off;

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

Esta configuración habilita TLS 1.2 y 1.3, utiliza cifrados fuertes y establece HSTS.

Preguntas frecuentes

¿Cuál es la diferencia entre HTTPS y TLS?

HTTPS es HTTP sobre TLS. TLS es el protocolo que proporciona cifrado y autenticación. Por lo tanto, HTTPS es la versión segura de HTTP, impulsada por TLS.

¿Cómo establece el handshake TLS una clave compartida?

El cliente y el servidor utilizan criptografía asimétrica (como ECDHE) para acordar un secreto compartido sin transmitirlo directamente. Luego derivan claves de sesión simétricas a partir de ese secreto para cifrar los datos.

¿Por qué expiran los certificados?

La expiración limita el daño si una clave privada se ve comprometida y fomenta la automatización de la renovación. Los certificados de corta duración son una buena práctica de seguridad.

¿Listo para inspeccionar tu propia configuración TLS? Utiliza el Analizador de registros de Nginx de TryQuickToolBox para detectar errores TLS y fallos de handshake en los registros de tu servidor.