Cómo funcionan HTTPS y TLS: Guía práctica
El problema: HTTPS está en todas partes, pero ¿cómo funciona realmente?
Ves el icono del candado en tu navegador y asumes que tu conexión es segura. Pero cuando algo sale mal—un error de certificado, una advertencia de contenido mixto o un handshake TLS lento—necesitas entender qué está pasando bajo el capó. Esta guía desglosa HTTPS y TLS en piezas prácticas y digeribles para que puedas depurar y optimizar conexiones seguras.
HTTPS es simplemente HTTP sobre TLS (Transport Layer Security). TLS proporciona cifrado, autenticación e integridad. Veamos cómo funciona, paso a paso.
Qué hace realmente TLS
TLS resuelve tres problemas fundamentales:
- Cifrado: Evita que los espías lean los datos intercambiados entre cliente y servidor.
- Autenticación: Demuestra la identidad del servidor (y opcionalmente la del cliente) mediante certificados.
- Integridad: Asegura que los datos no han sido manipulados durante el tránsito.
Sin TLS, el tráfico HTTP es texto plano—cualquiera en la ruta de red puede leerlo o modificarlo. TLS envuelve HTTP en un túnel cifrado.
El handshake TLS: paso a paso
Antes de que fluya cualquier dato HTTP, el cliente y el servidor realizan un handshake para acordar los parámetros de cifrado. Este es el flujo típico para TLS 1.2 (TLS 1.3 es más rápido pero similar en concepto):
- Client Hello: El cliente envía las versiones de TLS compatibles, los conjuntos de cifrado y un valor aleatorio.
- Server Hello: El servidor elige una versión de TLS y un conjunto de cifrado, y envía su propio valor aleatorio.
- Certificado: El servidor envía su cadena de certificados, incluida su clave pública y prueba de identidad.
- Intercambio de claves: Usando el certificado, el cliente y el servidor acuerdan de forma segura un secreto compartido (pre-master secret) utilizando algoritmos como ECDHE.
- Finished: Ambas partes verifican el handshake y cambian a comunicación cifrada usando claves simétricas derivadas del secreto compartido.
TLS 1.3 reduce esto a un solo viaje de ida y vuelta (1-RTT) e incluso admite 0-RTT para sesiones reanudadas, haciendo las conexiones más rápidas.
Certificados: el ancla de confianza
Un certificado vincula una clave pública a una identidad (como un nombre de dominio). Está firmado por una Autoridad de Certificación (CA) en la que el cliente confía. Cuando tu navegador se conecta a https://example.com, verifica:
- El certificado es válido para el dominio.
- Está firmado por una CA de confianza.
- No ha expirado.
- No ha sido revocado (mediante OCSP o CRL).
Si alguna verificación falla, recibes una advertencia. Para desarrollo, puedes usar certificados autofirmados, pero los navegadores los marcarán a menos que los confíes explícitamente.
Errores comunes de certificados y soluciones
| Error | Causa probable | Solución |
|---|---|---|
| NET::ERR_CERT_COMMON_NAME_INVALID | El certificado no coincide con el dominio | Reemitir el certificado con los Subject Alternative Names (SANs) correctos |
| NET::ERR_CERT_AUTHORITY_INVALID | Autofirmado o CA no confiable | Usar una CA de confianza o instalar la CA en el almacén de confianza |
| NET::ERR_CERT_DATE_INVALID | Expirado o aún no válido | Renovar el certificado y verificar el reloj del sistema |
Cifrado en la práctica: simétrico vs asimétrico
TLS utiliza ambos tipos de cifrado:
- Cifrado asimétrico (clave pública): Se usa durante el handshake para intercambiar de forma segura un secreto compartido. Lento pero resuelve la distribución de claves.
- Cifrado simétrico: Se usa para datos masivos después del handshake. Algoritmos rápidos como AES-GCM o ChaCha20-Poly1305 cifran el tráfico HTTP real.
El secreto compartido del handshake se usa para derivar claves de sesión simétricas. Este enfoque híbrido te da seguridad y rendimiento.
Depuración de conexiones TLS
Cuando HTTPS falla, necesitas inspeccionar el handshake. Aquí tienes comandos y técnicas prácticas:
1. Inspeccionar detalles del certificado con OpenSSL
openssl s_client -connect example.com:443 -servername example.com </dev/null
Esto imprime la cadena de certificados, el conjunto de cifrado y los detalles del handshake. Busca Verify return code: 0 (ok) para confirmar la confianza.
2. Probar versiones de TLS y cifrados
nmap --script ssl-enum-ciphers -p 443 example.com
Esto lista las versiones de TLS y conjuntos de cifrado compatibles, ayudándote a identificar configuraciones débiles.
3. Verificar encabezados de seguridad HTTP
Usa las DevTools del navegador (pestaña Seguridad) para ver si la página es completamente segura. El contenido mixto (recursos HTTP en una página HTTPS) genera advertencias y puede romper funcionalidades.
4. Analizar registros del servidor en busca de errores TLS
Si ejecutas Nginx, los fallos de handshake TLS aparecen en los registros de errores. Por ejemplo:
2025/01/01 12:00:00 [error] 1234#0: *5 SSL_do_handshake() failed (SSL: error:14094416:SSL routines:ssl3_read_bytes:sslv3 alert certificate unknown) while SSL handshaking, client: 203.0.113.1, server: 0.0.0.0:443
Esto indica que el cliente rechazó el certificado. Verifica tu cadena de certificados y configuración.
Optimización del rendimiento de TLS
TLS añade latencia, pero puedes minimizarla:
- Habilitar TLS 1.3: Handshake más rápido y seguridad mejorada.
- Usar reanudación de sesión: Los IDs de sesión o tickets reducen la sobrecarga del handshake para clientes recurrentes.
- Habilitar OCSP stapling: El servidor incluye el estado de revocación en el handshake, evitando una solicitud separada del cliente.
- Elegir conjuntos de cifrado eficientes: Prefiere AES-GCM con aceleración por hardware o ChaCha20-Poly1305 en móviles.
- Mantener certificados pequeños: Minimiza la longitud de la cadena y usa certificados ECDSA para claves más pequeñas.
Errores comunes y cómo evitarlos
- Certificados expirados: Automatiza la renovación con Let's Encrypt y configura monitoreo.
- Cadenas de certificados incompletas: Incluye siempre los certificados intermedios; la falta de intermedios causa errores de confianza en algunos clientes.
- Protocolos débiles: Deshabilita TLS 1.0 y 1.1; usa TLS 1.2+ con cifrados fuertes.
- Contenido mixto: Asegúrate de que todos los subrecursos (imágenes, scripts, estilos) usen HTTPS.
- Mala configuración de HSTS: Usa el encabezado
Strict-Transport-Securitycon cuidado; comienza con un max-age corto.
Preguntas frecuentes
¿Cuál es la diferencia entre HTTPS y TLS?
HTTPS es HTTP sobre TLS. TLS es el protocolo que proporciona cifrado y autenticación. Por lo tanto, HTTPS es la versión segura de HTTP, impulsada por TLS.
¿Cómo mejora TLS 1.3 a TLS 1.2?
TLS 1.3 reduce el handshake a un viaje de ida y vuelta (1-RTT) y admite 0-RTT para sesiones reanudadas. También elimina algoritmos criptográficos obsoletos y débiles, simplificando la configuración y mejorando la seguridad.
¿Por qué recibo errores de certificado en desarrollo?
Los servidores de desarrollo a menudo usan certificados autofirmados, que los navegadores no confían por defecto. Puedes agregar el certificado a tu almacén de confianza o usar una herramienta como mkcert para generar certificados de confianza local.
¿Necesitas inspeccionar o depurar rápidamente registros del servidor en busca de errores TLS? Prueba nuestro Analizador de registros de Nginx para analizar y filtrar entradas de registro en tu navegador.