Cómo funcionan realmente HTTPS y TLS: Guía paso a paso

Probablemente hayas visto el ícono del candado en tu navegador y asumido que tu conexión es segura. Pero, ¿qué sucede realmente cuando visitas un sitio HTTPS? ¿Cómo sabe tu navegador que está hablando con el servidor real y no con un impostor? ¿Y por qué TLS a veces ralentiza tu sitio?

En esta guía, desmitificaremos HTTPS y TLS recorriendo el handshake paso a paso. Aprenderás los roles de los certificados, el cifrado simétrico y asimétrico, y cómo verificar y optimizar TLS en tus propios proyectos.

Qué hacen realmente HTTPS y TLS

HTTPS es 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 legítimo, no con un atacante.

Sin TLS, el tráfico HTTP se envía en texto plano. Cualquiera en la ruta de la red (puntos de acceso Wi-Fi, ISP, routers comprometidos) puede leerlo o alterarlo. TLS resuelve esto estableciendo un canal seguro antes de que se intercambien datos HTTP.

El handshake TLS: paso a paso

El handshake es donde ocurre la magia. Es una negociación que establece claves compartidas y verifica identidades. Aquí está el flujo simplificado para TLS 1.2 y 1.3 (las dos versiones que encontrarás hoy).

Paso 1: Client Hello

El cliente (navegador) envía un mensaje ClientHello que contiene:

• Versiones de TLS soportadas (por ejemplo, TLS 1.3, TLS 1.2)
• Suites de cifrado soportadas (combinaciones de algoritmos)
• Una cadena de bytes aleatoria (client random)
• Para TLS 1.3, una clave compartida para el intercambio Diffie-Hellman

Paso 2: Server Hello y certificado

El servidor responde con un ServerHello (versión elegida, suite de cifrado, server random) y su certificado. El certificado contiene la clave pública del servidor y está firmado por una Autoridad de Certificación (CA).

El cliente verifica el certificado: ¿Está expirado? ¿Está emitido por una CA de confianza? ¿Coincide el dominio? Si no, el navegador muestra una advertencia.

Paso 3: Intercambio de claves

Usando la clave pública del servidor (o parámetros Diffie-Hellman), el cliente y el servidor derivan un secreto pre-maestro compartido. En TLS 1.3, esto se hace con Diffie-Hellman efímero (ECDHE), proporcionando secreto hacia adelante: incluso si la clave privada del servidor se ve comprometida más tarde, las sesiones pasadas permanecen seguras.

Paso 4: Finished

Ambos lados envían un mensaje Finished cifrado con las claves recién derivadas. Si el descifrado tiene éxito, el handshake está completo. A partir de entonces, todos los datos de la aplicación (HTTP) se cifran con cifrado simétrico (por ejemplo, AES-GCM o ChaCha20-Poly1305).

Mejoras de TLS 1.3

TLS 1.3 reduce el handshake a un viaje de ida y vuelta (1-RTT) y admite reanudación 0-RTT para visitantes recurrentes. También elimina algoritmos obsoletos, haciéndolo más rápido y seguro. La mayoría de los navegadores y servidores modernos admiten TLS 1.3.

Cifrado simétrico vs asimétrico en TLS

TLS utiliza ambos tipos de cifrado por una buena razón:

• Cifrado asimétrico (clave pública): Se utiliza durante el handshake para autenticar el servidor e intercambiar claves de forma segura. Es computacionalmente costoso pero resuelve el problema de distribución de claves.
• Cifrado simétrico: Se utiliza para la transferencia masiva de datos después del handshake. Es rápido y eficiente.

Este enfoque híbrido te brinda la seguridad de la criptografía de clave pública con el rendimiento de los cifrados simétricos.

Certificados: anclas de confianza

Un certificado vincula una clave pública a un nombre de dominio y está firmado por una CA. Los navegadores y sistemas operativos incluyen un almacén de CA raíz de confianza. Cuando un servidor presenta su certificado, el cliente construye una cadena de confianza hasta una raíz de confianza.

Los certificados tienen una vida útil limitada (ahora a menudo 90 días con Let's Encrypt). Los certificados expirados causan errores en el navegador, así que automatiza la renovación.

Práctico: Inspeccionar TLS con OpenSSL

Puedes inspeccionar la configuración TLS de un servidor usando la herramienta de línea de comandos openssl. Esto ayuda a depurar fallos de handshake o verificar suites de cifrado.

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

Esto se conecta al servidor e imprime la cadena de certificados, el cifrado negociado y los detalles de la sesión. Busca Verify return code: 0 (ok) para confirmar que el certificado es válido.

Para verificar la expiración del certificado:

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -dates

Errores comunes de TLS y cómo evitarlos

• Certificados expirados: Configura la renovación automatizada y la monitorización. Usa herramientas como Certbot para Let's Encrypt.
• Contenido mixto: Cargar recursos HTTP en una página HTTPS rompe la seguridad. Usa URLs relativas o asegúrate de que todos los recursos sean HTTPS.
• Suites de cifrado débiles: Deshabilita protocolos obsoletos (TLS 1.0, 1.1) y cifrados débiles (RC4, 3DES). Habilita TLS 1.3.
• Falta de HSTS: Agrega el encabezado Strict-Transport-Security para forzar HTTPS en futuras visitas.
• Cadenas de certificados incompletas: Algunos servidores olvidan incluir certificados intermedios, causando errores en algunos clientes. Usa SSL Labs para probar.

Optimizar el rendimiento de TLS

TLS agrega latencia debido al handshake. Aquí te mostramos cómo minimizarla:

• Habilita TLS 1.3, que tiene un handshake más rápido.
• Usa la reanudación de sesión (tickets de sesión o claves precompartidas) para evitar handshakes completos en visitantes recurrentes.
• Habilita el stapling OCSP para reducir la latencia de validación de certificados.
• Usa una CDN con terminación TLS en el edge para reducir los tiempos de ida y vuelta.
• Mantén los certificados pequeños (usa ECDSA en lugar de RSA cuando sea posible).

Preguntas frecuentes

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

HTTPS es la versión segura de HTTP, y TLS es el protocolo criptográfico que proporciona la seguridad. HTTPS usa TLS para cifrar y autenticar la conexión.

¿Cómo proporciona TLS secreto hacia adelante?

El secreto hacia adelante asegura que incluso si la clave privada del servidor se ve comprometida, las claves de sesión pasadas no puedan derivarse. Se logra utilizando el intercambio de claves Diffie-Hellman efímero (ECDHE) en TLS 1.3 y en configuraciones modernas de TLS 1.2.

¿Por qué veo errores de certificado en algunos sitios?

Los errores de certificado generalmente significan que el certificado está expirado, es autofirmado, fue emitido para un dominio diferente o la cadena de certificados está incompleta. Los navegadores rechazan dichos certificados para protegerte de ataques de intermediario.

Cuando necesites inspeccionar o depurar conexiones TLS, herramientas como Timestamp Converter pueden ayudarte a decodificar los períodos de validez de los certificados y depurar problemas relacionados con el tiempo.