Cómo funcionan realmente HTTPS y TLS: Guía práctica
Has visto el icono del candado en tu navegador miles de veces, pero ¿sabes qué ocurre realmente entre bastidores cuando visitas un sitio web HTTPS? El protocolo que hace posible la navegación web segura es TLS (Seguridad de la Capa de Transporte), antes conocido como SSL. Comprender cómo funciona realmente TLS no es solo académico: te ayuda a depurar problemas de configuración, tomar decisiones informadas sobre tus propios servidores y apreciar las garantías de seguridad en las que confías a diario.
El problema: HTTP inseguro
Antes de HTTPS, HTTP enviaba todo en texto plano. Cualquiera en la ruta de red (un punto de acceso Wi-Fi, un ISP, un router) podía leer tus contraseñas, cookies y datos personales. Peor aún, un atacante podía modificar el contenido en tránsito, inyectando malware o páginas falsas. La solución es cifrar los datos y verificar la identidad del servidor. Eso es exactamente lo que hace TLS.
Cómo encaja TLS en HTTPS
HTTPS es simplemente HTTP ejecutándose sobre una conexión TLS. El protocolo TLS se sitúa entre la capa de aplicación (HTTP) y la capa de transporte (TCP). Proporciona tres servicios principales:
- Cifrado: los datos se codifican para que los espías no puedan leerlos.
- Autenticación: puedes verificar que el servidor es quien dice ser mediante certificados digitales.
- Integridad: cualquier manipulación de los datos se detecta.
Pero, ¿cómo se ponen de acuerdo un cliente y un servidor sobre las claves de cifrado y demuestran sus identidades? Esa es la función del handshake TLS.
El handshake TLS paso a paso
Cuando visitas un sitio HTTPS, tu navegador y el servidor realizan un handshake: una serie de mensajes que establecen una sesión segura. Aquí tienes una versión simplificada del handshake moderno de TLS 1.3:
- ClientHello: El cliente envía un mensaje con las versiones de TLS compatibles, las suites de cifrado y un número aleatorio.
- ServerHello: El servidor elige una suite de cifrado y envía su propio número aleatorio.
- Certificado del servidor: El servidor envía su certificado digital, que contiene su clave pública e identidad.
- Intercambio de claves: Usando la clave pública del servidor y una técnica como Diffie-Hellman, ambas partes calculan un secreto compartido: la clave de sesión.
- Finalizado: Ambas partes envían un mensaje cifrado confirmando que todo está en orden. A partir de ahora, todos los datos se cifran con la clave de sesión.
En TLS 1.3, esto ocurre en una sola ida y vuelta, haciendo las conexiones más rápidas que en versiones anteriores.
¿Qué pasa con los certificados?
El certificado del servidor es un documento digital emitido por un tercero de confianza llamado Autoridad de Certificación (CA). Vincula una clave pública a un nombre de dominio. Tu navegador verifica la validez del certificado, su expiración y si fue emitido por una CA de confianza. Si el dominio no coincide o el certificado ha expirado, verás una advertencia.
Para obtener un certificado, los propietarios de sitios web utilizan el protocolo ACME (a menudo con herramientas como Let's Encrypt) para demostrar que controlan el dominio. La CA firma el certificado con su propia clave privada. Esto crea una cadena de confianza desde tu navegador hasta la CA y el sitio web.
Cifrado simétrico vs. asimétrico
TLS utiliza dos tipos de cifrado:
- Cifrado asimétrico (clave pública/privada) se usa durante el handshake para intercambiar secretos de forma segura sin compartir previamente una clave.
- Cifrado simétrico (misma clave para cifrar y descifrar) se usa para la transferencia de datos real porque es mucho más rápido.
Por ejemplo, RSA se usa comúnmente para el intercambio inicial de claves (aunque TLS 1.3 prefiere Diffie-Hellman), y AES-GCM es un cifrado simétrico popular para datos masivos.
Suites de cifrado: los componentes básicos
Una suite de cifrado es una combinación de algoritmos que define cómo funcionan el handshake y el cifrado. Por ejemplo, la suite TLS_AES_256_GCM_SHA384 significa:
- Intercambio de claves: (implícito en la suite en TLS 1.3)
- Cifrado de datos: AES en modo GCM con clave de 256 bits
- Hash para integridad: SHA-384
Al configurar un servidor, eliges qué suites de cifrado habilitar. Suites antiguas como ECDHE-RSA-AES128-GCM-SHA256 siguen siendo comunes. El objetivo es preferir suites que ofrezcan secreto perfecto hacia adelante, lo que significa que incluso si la clave privada del servidor se ve comprometida más tarde, las sesiones pasadas permanecen seguras.
Aquí tienes una pequeña comparación de versiones comunes de TLS:
| Versión | Lanzamiento | Características clave | Estado |
|---|---|---|---|
| TLS 1.2 | 2008 | SHA-256, cifrados AEAD | Ampliamente soportado |
| TLS 1.3 | 2018 | Handshake más rápido, solo cifrados con secreto perfecto hacia adelante | Recomendado |
| TLS 1.0/1.1 | 1999/2006 | Legado, débil | Obsoleto |
Errores comunes y cómo evitarlos
Incluso con TLS habilitado, los errores pueden comprometer la seguridad:
- Contenido mixto: Servir algunos recursos a través de HTTP en una página HTTPS. Los navegadores bloquean muchos tipos de contenido mixto. Usa siempre URLs relativas o HTTPS para todos los subrecursos.
- Protocolos obsoletos: Dejar habilitados TLS 1.0 o 1.1 expone a los usuarios a ataques. Deshabilítalos en tu servidor.
- Suites de cifrado débiles: Algunas suites antiguas usan RC4 o DES, que son fáciles de romper. Usa suites modernas con secreto perfecto hacia adelante.
- Expiración de certificados: Un certificado caducado causa errores. Automatiza la renovación con certbot o la renovación automática de tu proveedor.
- Falta de HSTS: HTTP Strict Transport Security indica a los navegadores que usen siempre HTTPS, evitando ataques de degradación. Añade la cabecera
Strict-Transport-Security.
Para probar la configuración TLS de tu servidor, puedes usar escáneres en línea como SSL Labs' SSL Server Test (no afiliado con nosotros). Calificarán tu configuración y señalarán debilidades.
Depurar TLS con OpenSSL
A veces necesitas ver qué ocurre en la red. La herramienta de línea de comandos openssl es tu aliada. Por ejemplo, para ver el certificado de un servidor:
openssl s_client -connect example.com:443 -showcerts
Esto muestra la cadena de certificados y otros detalles. También puedes probar una versión específica de TLS:
openssl s_client -tls1_2 -connect example.com:443
Si estás solucionando problemas con un cliente que no puede conectarse, esto te muestra exactamente qué protocolos y cifrados soporta el servidor.
Por qué TLS importa para tu sitio web
Más allá de la seguridad, HTTPS es una señal de clasificación para los motores de búsqueda y un requisito para muchas características modernas del navegador como la geolocalización y los service workers. Si aún no has migrado, hazlo ahora. Herramientas como Let's Encrypt lo hacen gratuito y fácil.
Una vez que estés en HTTPS, también deberías considerar usar una herramienta para inspeccionar los registros de tu servidor web en busca de anomalías. Por ejemplo, si ejecutas un servidor Nginx, analizar tus registros de acceso puede ayudarte a detectar handshakes fallidos repetidos o solicitudes sospechosas. Nuestro Analizador de registros Nginx puede ayudarte a analizar y comprender esos registros rápidamente.
Preguntas frecuentes
¿Cuál es la diferencia entre SSL y TLS?
SSL (Capa de sockets seguros) es el predecesor de TLS. Todas las versiones de SSL están obsoletas e inseguras. TLS es el protocolo moderno, siendo TLS 1.2 y 1.3 los estándares actuales. La gente suele decir "SSL" cuando se refiere a "TLS", pero técnicamente son diferentes.
¿Cómo verifica el navegador un certificado?
El navegador comprueba la firma digital del certificado usando la clave pública de la CA que lo emitió. También verifica que el certificado no haya caducado, que el dominio coincida y que la CA esté en su almacén de raíces de confianza. Si alguna comprobación falla, el navegador muestra una advertencia.
¿Qué es el secreto perfecto hacia adelante?
El secreto perfecto hacia adelante es una propiedad de métodos de intercambio de claves como ECDHE. Asegura que incluso si la clave privada a largo plazo del servidor se ve comprometida, las claves de sesión pasadas no se pueden derivar, por lo que el tráfico grabado permanece confidencial. TLS 1.3 exige suites de cifrado con secreto perfecto hacia adelante.
Conclusión
HTTPS y TLS no son magia: son una combinación bien diseñada de criptografía y confianza. Al comprender el handshake, los certificados y las suites de cifrado, puedes tomar mejores decisiones para tus propios proyectos y solucionar problemas con confianza. Mantén tus protocolos actualizados, usa suites de cifrado fuertes y prueba siempre tu configuración.
¿Listo para poner en práctica tus conocimientos? Si gestionas un servidor Nginx, prueba nuestro Analizador de registros Nginx para ver quién se conecta a tu sitio y detectar posibles problemas de seguridad en tus registros.