Cómo funcionan HTTPS y TLS: Guía práctica
Probablemente hayas visto el icono del candado en tu navegador y hayas asumido que significa que un sitio es seguro. Pero, ¿qué ocurre realmente cuando visitas una URL HTTPS? ¿Por qué algunos certificados provocan advertencias? ¿Y cómo puedes saber si una conexión está realmente cifrada de extremo a extremo? Esta guía desglosa HTTPS y TLS en términos prácticos, mostrándote los pasos del handshake, cómo se validan los certificados y cómo inspeccionar conexiones reales usando herramientas de línea de comandos. Al final, entenderás la mecánica lo suficientemente bien como para depurar problemas de TLS y tomar decisiones informadas sobre tu propia seguridad web.
Qué es realmente HTTPS
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 que posee el dominio, no con un impostor.
Sin TLS, HTTP envía todo en texto plano —contraseñas, cookies y contenido— por la red. TLS envuelve ese tráfico en un túnel cifrado. El candado significa que la conexión está cifrada y el certificado es válido, pero no significa que el sitio sea confiable o seguro en otros aspectos (por ejemplo, aún podría tener vulnerabilidades).
El handshake de TLS en lenguaje sencillo
Antes de que se intercambie cualquier dato HTTP, el cliente y el servidor realizan un handshake de TLS. Los pasos exactos varían ligeramente entre TLS 1.2 y 1.3, pero la idea central es la misma: acordar algoritmos, autenticar el servidor y establecer claves compartidas. Aquí tienes un flujo simplificado para TLS 1.3 (el predeterminado moderno):
- Client Hello: El cliente envía una lista de suites de cifrado compatibles, un valor aleatorio y su key share (para el intercambio de claves).
- Server Hello: El servidor elige una suite de cifrado, envía su propio valor aleatorio y key share, y proporciona su cadena de certificados.
- Validación del certificado: El cliente verifica la validez del certificado, el nombre de dominio y la cadena de confianza.
- Derivación de claves: Ambos lados calculan el mismo secreto compartido usando Diffie-Hellman (a menudo X25519). A partir de ahí, derivan claves de sesión simétricas.
- Finished: Ambos lados envían un MAC sobre la transcripción del handshake para confirmar que nada fue manipulado.
Después del handshake, los datos de la aplicación (solicitudes/respuestas HTTP) se cifran con las claves de sesión. TLS 1.3 reduce el handshake a un solo viaje de ida y vuelta (1-RTT) y admite la reanudación 0-RTT, lo que lo hace más rápido que TLS 1.2.
Validación de certificados: cómo decide tu navegador confiar en un sitio
Cuando el servidor envía su certificado, el cliente debe verificarlo. El navegador (o tu cliente HTTP) realiza varias comprobaciones:
- Cadena de confianza: El certificado debe estar firmado por una Autoridad Certificadora (CA) de confianza o por una CA intermedia que enlace con una CA raíz en el almacén de confianza del cliente.
- Nombre de dominio: El Subject Alternative Name (SAN) del certificado debe incluir el nombre de host al que te estás conectando.
- Período de validez: El certificado no debe estar caducado ni ser aún no válido.
- Revocación: El cliente puede consultar OCSP o CRL para ver si el certificado fue revocado (aunque esto suele ser de mejor esfuerzo).
Si alguna comprobación falla, el navegador muestra una advertencia. Por ejemplo, un certificado autofirmado provoca "Tu conexión no es privada" porque no está firmado por una CA de confianza.
Inspeccionar una conexión TLS real
Puedes ver los detalles del handshake tú mismo usando OpenSSL. Ejecuta este comando en tu terminal (reemplaza el nombre de host):
openssl s_client -connect example.com:443 -servername example.com -showcertsLa salida incluye la cadena de certificados, el cifrado negociado y la versión de TLS. Busca líneas como:
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 2048 bitEsto te indica que la conexión usa TLS 1.3 con AES-256-GCM. También puedes usar curl -v https://example.com para ver el resumen del handshake de TLS.
Errores de configuración comunes de TLS y cómo detectarlos
Incluso con HTTPS habilitado, una mala configuración puede debilitar la seguridad. Estos son problemas frecuentes:
| Problema | Riesgo | Cómo comprobarlo |
|---|---|---|
| Protocolos débiles (TLS 1.0/1.1) | Vulnerables a ataques conocidos | openssl s_client -tls1_1 -connect host:443 debería fallar |
| Certificado caducado | Advertencias del navegador, confianza rota | Comprueba la caducidad con openssl s_client | openssl x509 -noout -dates |
| Faltan certificados intermedios | Algunos clientes no pueden validar | Usa -showcerts y verifica que la cadena esté completa |
| Sin cabecera HSTS | Posibles ataques de degradación | Busca la cabecera Strict-Transport-Security |
Solucionar estos problemas suele implicar actualizar la configuración del servidor (por ejemplo, en Nginx: ssl_protocols TLSv1.2 TLSv1.3;) y asegurarte de que tu cadena de certificados esté completa.
HTTPS en la práctica: qué deben hacer los desarrolladores
- Usa solo TLS 1.2 o 1.3; desactiva las versiones anteriores.
- Obtén certificados de una CA de confianza (Let's Encrypt es gratuito y automatizado).
- Habilita HSTS para forzar HTTPS.
- Renueva los certificados con regularidad y supervisa su caducidad.
- Prueba tu configuración con herramientas como SSL Labs (qualys.com/ssllabs) o
testssl.sh.
Si estás depurando registros del servidor, el Analizador de registros de Nginx puede ayudarte a detectar fallos del handshake de TLS y errores de certificados en tus registros de acceso.
Preguntas frecuentes
¿Cuál es la diferencia entre TLS y SSL?
SSL es el predecesor de TLS. SSL 2.0 y 3.0 están obsoletos y son inseguros; los sistemas modernos usan TLS 1.2 o 1.3. A menudo la gente dice "SSL" coloquialmente, pero se refiere a TLS.
¿HTTPS hace que un sitio web sea completamente seguro?
No. HTTPS cifra el tráfico y autentica el servidor, pero no protege contra vulnerabilidades como inyección SQL, XSS o permisos mal configurados. Es una capa de seguridad.
¿Cómo puedo comprobar si un sitio admite TLS 1.3?
Usa openssl s_client -connect host:443 -tls1_3. Si el handshake se completa, TLS 1.3 es compatible. Alternativamente, revisa el protocolo en las herramientas de desarrollo de tu navegador, en la pestaña Seguridad.
Entender el handshake de TLS y la validación de certificados te ayuda a crear y mantener servicios web seguros. Cuando necesites analizar registros del servidor en busca de errores de TLS o problemas de rendimiento, prueba el Analizador de registros de Nginx para analizar y filtrar rápidamente las entradas de los registros.