Cómo funcionan realmente HTTPS y TLS: bajo el capó

Escribes una URL, pulsas Enter y ves el 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 descorre el telón sobre HTTPS y TLS, explicando el handshake, el cifrado y la validación de certificados en términos prácticos.

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.

TLS evolucionó de SSL (Secure Sockets Layer). Las versiones modernas (TLS 1.2 y 1.3) son las que deberías usar; SSL está obsoleto.

El handshake TLS: paso a paso

Antes de que fluya cualquier dato HTTP, el cliente y el servidor realizan un handshake para acordar las claves de cifrado. Esto es lo que sucede en un handshake TLS 1.3 típico (simplificado):

1. Client Hello: El navegador envía una lista de suites de cifrado soportadas, 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 su clave pública, y presenta su certificado.
3. Derivación de claves: Ambas partes calculan el mismo secreto compartido usando el intercambio de claves Diffie-Hellman. A partir de esto, derivan claves de sesión para el cifrado simétrico.
4. Finished: Ambas partes envían un MAC (Message Authentication Code) para verificar la integridad del handshake. Ahora pueden fluir los datos de aplicación cifrados.

TLS 1.3 redujo el handshake a un solo viaje de ida y vuelta (1-RTT) e incluso admite 0-RTT para sesiones reanudadas, mejorando la latencia.

Intercambio de claves: Diffie-Hellman

La magia del TLS moderno es que el cliente y el servidor pueden acordar un secreto compartido sin transmitirlo nunca. Diffie-Hellman (específicamente ECDHE para curva elíptica) lo permite. Incluso si un atacante registra todo el handshake, no puede derivar la clave de sesión; esta propiedad se llama forward secrecy (secreto hacia adelante).

Cifrado simétrico: AES o ChaCha20

Una vez establecido el secreto compartido, TLS cambia a cifrado simétrico (como AES-GCM o ChaCha20-Poly1305) porque es mucho más rápido que la criptografía asimétrica. Las claves de sesión se utilizan para cifrar todos los datos de aplicación.

Validación de certificados: confía pero verifica

El certificado del servidor es fundamental para la autenticación. Contiene la clave pública del servidor y está firmado por una Autoridad de Certificación (CA). Así lo valida el navegador:

• Cadena de confianza: El certificado debe encadenar hasta una CA raíz de confianza preinstalada en el navegador o sistema operativo.
• Coincidencia de nombre de host: El certificado debe ser válido para el dominio que visitas (mediante Subject Alternative Names).
• Periodo de validez: El certificado no debe estar caducado ni aún no válido.
• Revocación: El navegador puede consultar OCSP o CRL para asegurarse de que el certificado no ha sido revocado.

Si alguna comprobación falla, recibes una advertencia, como "Tu conexión no es privada".

Errores comunes de configuración de TLS

Incluso con HTTPS habilitado, los errores pueden debilitar la seguridad:

• Protocolos obsoletos: Soportar TLS 1.0/1.1 o SSLv3 te expone a ataques conocidos.
• Suites de cifrado débiles: Permitir cifrados RC4 o en modo CBC sin mitigaciones.
• Falta de HSTS: Sin HTTP Strict Transport Security, los usuarios pueden ser degradados a HTTP.
• Mala gestión de certificados: Certificados caducados o configuración incorrecta de la cadena.

Utiliza herramientas como SSL Test de SSL Labs para comprobar tu configuración.

Ejemplo práctico: habilitar HTTPS con Nginx

Aquí tienes una configuración mínima de Nginx para un servidor HTTPS seguro:

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;

    location / {
        root /var/www/html;
        index index.html;
    }
}

Esta configuración utiliza certificados de Let's Encrypt, habilita solo TLS 1.2 y 1.3, y establece HSTS.

Preguntas frecuentes

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

TLS es el sucesor de SSL. Las versiones de SSL (2.0, 3.0) están obsoletas debido a fallos de seguridad. Cuando la gente dice "certificado SSL", normalmente se refiere a un certificado TLS.

¿HTTPS hace que mi sitio web sea lento?

El TLS moderno (1.3) añade una latencia mínima, a menudo solo unos pocos milisegundos. Con la reanudación de sesión y HTTP/2, HTTPS puede ser igual de rápido o más que HTTP.

¿Cómo obtengo un certificado TLS gratuito?

Let's Encrypt proporciona certificados gratuitos y automatizados. Herramientas como Certbot pueden obtenerlos y renovarlos por ti.

Conclusión

HTTPS y TLS no son magia: son protocolos bien diseñados que combinan criptografía de clave pública para la autenticación con cifrado simétrico para la velocidad. Comprender el handshake y la validación de certificados te ayuda a depurar problemas y configurar tus servidores de forma segura. Utiliza siempre TLS 1.2 o 1.3, mantén los certificados actualizados y habilita HSTS.

Para analizar los registros del servidor y detectar errores TLS o problemas de rendimiento, prueba nuestro Analizador de registros de Nginx.