Cómo funcionan HTTPS y TLS: Guía práctica
Escribes https:// y ves un candado, pero ¿qué ocurre realmente entre tu navegador y el servidor? Muchos desarrolladores tratan HTTPS como una caja negra, hasta que algo falla en producción. Esta guía recorre el handshake TLS, la validación de certificados y el cifrado que protege tus datos, con pasos prácticos para depurar problemas comunes.
Por qué existe HTTPS: las tres garantías
HTTPS es HTTP sobre TLS (Transport Layer Security). Proporciona tres propiedades fundamentales:
- Confidencialidad – Los espías no pueden leer los datos.
- 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.
Sin TLS, cualquiera en la ruta de red (operador de Wi‑Fi, ISP, router malicioso) puede leer o alterar el tráfico. TLS lo resuelve combinando criptografía asimétrica y simétrica.
El handshake TLS explicado de forma sencilla
Antes de enviar cualquier solicitud HTTP, el cliente y el servidor realizan un handshake para acordar claves y verificar identidades. TLS 1.3 moderno lo simplifica a un solo viaje de ida y vuelta, pero los conceptos son los mismos.
- Client Hello – El navegador envía las versiones de TLS y suites de cifrado compatibles, y un valor aleatorio.
- Server Hello – El servidor elige una suite de cifrado, envía su propio valor aleatorio y presenta su cadena de certificados.
- Validación del certificado – El navegador comprueba la firma, la caducidad y el nombre de dominio del certificado contra las CA raíz de confianza.
- Intercambio de claves – Mediante Diffie‑Hellman efímero (o similar), ambas partes derivan un secreto compartido sin transmitirlo.
- Finished – Ambas partes envían un MAC sobre la transcripción del handshake para confirmar la integridad.
Tras el handshake, todos los datos HTTP se cifran con claves simétricas (p. ej., AES‑GCM o ChaCha20‑Poly1305), mucho más rápidas que las operaciones asimétricas.
Simétrico vs asimétrico: ¿por qué ambos?
La criptografía asimétrica (RSA, ECDSA) se usa solo durante el handshake para autenticación e intercambio de claves. Es computacionalmente costosa. El cifrado simétrico maneja los datos masivos porque es eficiente. TLS los combina: asimétrico para establecer confianza, simétrico para proteger la sesión.
| Operación | Tipo | Propósito |
|---|---|---|
| Firma de certificados | Asimétrico | Demostrar la identidad del servidor |
| Intercambio de claves | Asimétrico / ECDHE | Derivar un secreto compartido |
| Cifrado de datos masivos | Simétrico | Confidencialidad e integridad rápidas |
Validación de certificados: la cadena de confianza
Los navegadores confían en un conjunto de CA raíz preinstaladas en el sistema operativo o el navegador. Un certificado de servidor está firmado por una CA intermedia, que a su vez está firmada por una CA raíz. El navegador construye una cadena y verifica cada firma. Si falta algún eslabón o no es válido, aparece una advertencia.
Fallos de validación comunes:
- Certificado caducado – Revisa la fecha
Not After. - Discrepancia de nombre de host – El Subject Alternative Name (SAN) del certificado debe incluir el dominio.
- Cadena incompleta – El servidor debe enviar los certificados intermedios; los navegadores a menudo no los obtienen automáticamente.
- Raíz no confiable – Los certificados autofirmados generan advertencias a menos que se confíe explícitamente en ellos.
Usa openssl s_client -connect example.com:443 -showcerts para inspeccionar la cadena que presenta un servidor.
Depuración práctica: inspeccionar una conexión TLS
Cuando HTTPS falla, estos comandos ayudan:
# Check certificate details and chain
openssl s_client -connect example.com:443 -servername example.com -showcerts
# Test TLS versions and ciphers
nmap --script ssl-enum-ciphers -p 443 example.com
# From the browser: open DevTools → Security tabBusca errores como UNABLE_TO_VERIFY_LEAF_SIGNATURE (intermedio faltante) o ERR_CERT_COMMON_NAME_INVALID (discrepancia de nombre de host).
Errores comunes y buenas prácticas
- Contenido mixto – Cargar recursos HTTP en una página HTTPS rompe el candado. Usa URLs relativas o HTTPS en todas partes.
- HSTS – Envía
Strict-Transport-Securitypara forzar HTTPS y evitar ataques de downgrade. - OCSP Stapling – Permite que el servidor incluya la prueba de revocación, reduciendo la latencia del handshake.
- TLS 1.3 – Prefiérelo por velocidad y seguridad; desactiva TLS 1.0/1.1.
- Renovación de certificados – Automatiza con Let's Encrypt y configura recordatorios.
HTTPS no es opcional. Los motores de búsqueda posicionan mejor los sitios seguros, y los navegadores marcan HTTP como «No seguro».
FAQ
¿Cuál es la diferencia entre TLS y SSL?
SSL es el predecesor de TLS. Los certificados «SSL» modernos en realidad usan protocolos TLS. TLS 1.2 y 1.3 son las versiones seguras; las versiones SSL están obsoletas y no deben usarse.
¿HTTPS ralentiza mi sitio?
Con TLS 1.3 y la reanudación de sesión, la sobrecarga es mínima, a menudo unos pocos milisegundos. Los beneficios de seguridad superan con creces el coste. Usa HTTP/2 o HTTP/3 para reducir aún más la latencia.
¿Cómo soluciono los errores de «cadena de certificados incompleta»?
Configura tu servidor para enviar la cadena completa, incluidos los certificados intermedios. La mayoría de los proveedores de CA suministran un archivo bundle; apunta tu servidor web (p. ej., Nginx ssl_certificate) al archivo concatenado con el certificado y los intermedios.
¿Necesitas analizar los registros del servidor en busca de errores TLS o problemas de rendimiento? Prueba nuestro Analizador de registros de Nginx para analizar y visualizar rápidamente los registros de acceso.