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

Probablemente hayas visto el icono del candado en tu navegador y sepas que HTTPS significa que un sitio web es seguro. Pero, ¿qué sucede realmente cuando visitas un sitio HTTPS? ¿Cómo acuerdan el navegador y el servidor las claves de cifrado? ¿Y por qué son importantes los certificados? Comprender la mecánica de HTTPS y TLS es esencial para desarrolladores, administradores de sistemas y cualquier persona que construya o proteja aplicaciones web.

Esta guía desglosa el handshake TLS, la validación de certificados y el cifrado en términos sencillos. Aprenderás cómo HTTPS protege los datos en tránsito, los errores comunes y los pasos prácticos para asegurar que tus propios sitios estén configurados correctamente.

Qué significa realmente HTTPS

HTTPS es HTTP sobre TLS (Transport Layer Security). Proporciona tres garantías:

• Confidencialidad: Los datos intercambiados entre cliente y servidor están cifrados, por lo que los espías no pueden leerlos.
• Integridad: Los datos no pueden modificarse en tránsito sin ser detectados.
• Autenticación: El cliente puede verificar que está hablando con el servidor legítimo, no con un impostor.

TLS es el sucesor de SSL (Secure Sockets Layer). Aunque todavía se dice "certificado SSL", los sistemas modernos usan TLS. La última versión, TLS 1.3, simplifica el handshake y mejora la seguridad.

El handshake TLS: paso a paso

Antes de que fluyan los datos HTTP cifrados, el cliente y el servidor realizan un handshake para acordar parámetros criptográficos y establecer claves compartidas. Así funciona un handshake típico de TLS 1.3:

1. Client Hello: El cliente envía un mensaje con las versiones de TLS compatibles, los conjuntos de cifrado y un valor aleatorio (client random).
2. Server Hello: El servidor responde con la versión de TLS elegida, el conjunto de cifrado y su propio valor aleatorio (server random). También envía su cadena de certificados.
3. Intercambio de claves: Usando la clave pública del certificado del servidor (o un key share en TLS 1.3), el cliente y el servidor derivan un secreto compartido. En TLS 1.3, esto ocurre en un solo viaje de ida y vuelta.
4. Finished: Ambas partes envían un mensaje Finished cifrado con las claves derivadas para verificar la integridad del handshake.

Después del handshake, los datos de la aplicación (solicitudes y respuestas HTTP) se cifran con claves simétricas derivadas del secreto compartido.

Validación de certificados

El certificado del servidor vincula su clave pública a su identidad (nombre de dominio). El cliente valida el certificado mediante:

• Comprobar que el certificado está firmado por una Autoridad de Certificación (CA) de confianza.
• Verificar que el nombre de dominio coincide con el host solicitado.
• Asegurar que el certificado está dentro de su período de validez y no ha sido revocado.

Si la validación falla, el navegador muestra una advertencia. Nunca omitas estas advertencias en producción; indican un posible ataque de intermediario (man-in-the-middle).

Cifrado en TLS: simétrico y asimétrico

TLS utiliza tanto cifrado asimétrico (clave pública) como simétrico. El cifrado asimétrico se usa durante el handshake para intercambiar claves de forma segura. El cifrado simétrico (como AES o ChaCha20) se usa para datos masivos porque es mucho más rápido.

En TLS 1.3, el intercambio de claves típicamente utiliza Diffie-Hellman efímero (ECDHE), que proporciona secreto hacia adelante (forward secrecy): incluso si la clave privada del servidor se ve comprometida más tarde, las sesiones pasadas permanecen seguras.

Errores comunes en HTTPS y cómo evitarlos

Incluso con HTTPS habilitado, una mala configuración puede debilitar la seguridad. Ten cuidado con:

• Certificados caducados: Configura monitoreo y renovación automática (por ejemplo, Let's Encrypt).
• Contenido mixto: Cargar recursos HTTP en una página HTTPS rompe la seguridad. Usa URLs relativas o HTTPS en todas partes.
• Conjuntos de cifrado débiles: Deshabilita protocolos obsoletos (TLS 1.0/1.1) y cifrados débiles. Usa herramientas como SSL Labs para probar.
• Falta de HSTS: HTTP Strict Transport Security obliga a los navegadores a usar HTTPS. Añade el encabezado Strict-Transport-Security.

Ejemplo práctico: comprobar la configuración de TLS

Puedes inspeccionar la configuración TLS de un servidor usando OpenSSL. Por ejemplo, para ver la cadena de certificados y el protocolo negociado:

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

Busca la versión del protocolo y el cifrado en la salida. Para probar la compatibilidad con TLS 1.3:

openssl s_client -connect example.com:443 -tls1_3

Audita regularmente tu configuración y mantén el software actualizado.

Preguntas frecuentes

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

HTTPS es la versión segura de HTTP, y TLS es el protocolo que proporciona cifrado y autenticación para HTTPS. En otras palabras, HTTPS = HTTP + TLS.

¿Necesito un certificado para servicios internos?

Sí, incluso para servicios internos, usar certificados TLS evita escuchas y ataques de intermediario dentro de tu red. Puedes usar una CA interna o certificados autofirmados, pero asegúrate de que los clientes confíen en ellos.

¿Con qué frecuencia se deben renovar los certificados?

Los certificados tienen un período de validez establecido por la CA. Muchas organizaciones usan certificados de 90 días con renovación automatizada. Monitorea las fechas de vencimiento y automatiza la renovación para evitar interrupciones.

¿Quieres analizar rápidamente tus registros de acceso de Nginx en busca de actividad sospechosa o problemas de rendimiento? Prueba nuestro Analizador de registros de Nginx para procesar y visualizar datos de registros en segundos.