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

Probablemente hayas visto el icono del candado en tu navegador y sepas que significa "seguro". Pero, ¿qué ocurre realmente cuando visitas un sitio web HTTPS? ¿Cómo sabe tu navegador que está hablando con el servidor real y no con un impostor? ¿Y por qué TLS a veces ralentiza las cosas? Esta guía desglosa HTTPS y TLS en términos prácticos, para que puedas configurar, depurar y proteger tus aplicaciones web con confianza.

Qué es realmente HTTPS

HTTPS es simplemente 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: El servidor demuestra su identidad mediante un certificado.

Sin TLS, HTTP envía todo en texto plano: contraseñas, cookies y datos personales son visibles para cualquiera en la ruta de red. HTTPS soluciona eso.

El handshake TLS en lenguaje sencillo

Antes de que fluyan datos cifrados, el cliente y el servidor realizan un handshake para acordar las claves de cifrado y verificar la identidad. Esto es lo que sucede en un handshake TLS 1.3 típico (el estándar moderno):

1. Client Hello: El navegador envía una lista de suites de cifrado compatibles, versiones de TLS y un valor aleatorio.
2. Server Hello: El servidor elige una suite de cifrado, envía su propio valor aleatorio y proporciona su cadena de certificados.
3. Intercambio de claves: Ambas partes utilizan un algoritmo de intercambio de claves (como ECDHE) para derivar un secreto compartido sin transmitirlo directamente.
4. Verificación del certificado: El cliente comprueba el certificado del servidor contra las CA raíz de confianza, valida el nombre de dominio y verifica la expiración.
5. Finished: Ambas partes envían un MAC para confirmar la integridad del handshake, y comienza la transmisión de datos de aplicación cifrados.

TLS 1.3 reduce esto a un solo viaje de ida y vuelta (1-RTT) e incluso admite la reanudación 0-RTT para visitantes recurrentes, reduciendo significativamente la latencia en comparación con TLS 1.2.

Certificados: el ancla de confianza

Un certificado vincula una clave pública a un nombre de dominio y está firmado por una Autoridad de Certificación (CA). Los navegadores y sistemas operativos incluyen un almacén de CA raíz de confianza. Cuando un servidor presenta su certificado, el cliente verifica la cadena hasta una raíz de confianza.

Tipos comunes de certificados:

• DV (Validación de Dominio): Demuestra el control del dominio; se emite rápidamente y a menudo es gratuito (por ejemplo, Let's Encrypt).
• OV (Validación de Organización): Incluye detalles verificados de la organización; tarda más en emitirse.
• EV (Validación Extendida): Nivel de validación más alto; históricamente mostraba una barra verde, pero los navegadores modernos ya no lo enfatizan.

Los certificados caducan, por lo que la automatización es esencial. Herramientas como Certbot o clientes ACME integrados en tu proxy inverso gestionan la renovación automáticamente.

Configurar HTTPS en tu servidor

Aquí tienes una configuración mínima de Nginx que habilita HTTPS con ajustes TLS modernos:

server {
    listen 443 ssl http2;
    server_name example.com;

    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256';
    ssl_prefer_server_ciphers off;

    # HSTS (habilitar después de probar)
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

    location / {
        proxy_pass http://localhost:3000;
    }
}

server {
    listen 80;
    server_name example.com;
    return 301 https://$host$request_uri;
}

Puntos clave: usa solo TLS 1.2 y 1.3, prefiere suites de cifrado ECDHE para secreto perfecto hacia adelante y redirige HTTP a HTTPS. HSTS indica a los navegadores que siempre usen HTTPS para tu dominio, pero prueba cuidadosamente antes de habilitarlo con un max-age largo.

Errores comunes y cómo evitarlos

• Contenido mixto: Cargar recursos HTTP en una página HTTPS rompe el candado. Usa URLs relativas o asegúrate de que todos los recursos sean HTTPS.
• Certificados caducados: Automatiza la renovación y monitorea la expiración. Un certificado caducado provoca advertencias inmediatas en el navegador.
• Protocolos débiles: Deshabilita TLS 1.0 y 1.1; están obsoletos y son vulnerables.
• Cadenas de certificados incompletas: Los servidores deben enviar certificados intermedios; de lo contrario, algunos clientes fallan. Usa herramientas como SSL Labs para probar.
• Sin precarga HSTS: Para máxima protección, envía tu dominio a la lista de precarga HSTS después de asegurarte de que todos los subdominios admiten HTTPS.

TLS 1.2 vs TLS 1.3: Qué cambió

TLS 1.3 es más rápido y sencillo, eliminando algoritmos heredados. La mayoría de los clientes modernos lo admiten, pero mantén TLS 1.2 para dispositivos más antiguos.

Depurar problemas de TLS

Cuando HTTPS falla, revisa lo siguiente:

• Usa openssl s_client -connect example.com:443 -servername example.com para inspeccionar la cadena de certificados y el handshake.
• Ejecuta curl -vI https://example.com para ver la versión de TLS y el cifrado negociado.
• Revisa los registros del servidor en busca de errores de handshake; Nginx registra errores SSL en el registro de errores.
• Usa testers SSL en línea para obtener una calificación completa y recomendaciones.

Si trabajas con registros de Nginx con regularidad, el Analizador de registros de Nginx puede ayudarte a detectar fallos de handshake TLS y otros problemas rápidamente.

Preguntas frecuentes

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

HTTPS es HTTP sobre TLS. TLS es el protocolo criptográfico que proporciona cifrado, integridad y autenticación. HTTPS es la versión segura de HTTP que utiliza TLS.

¿Necesito un certificado para servicios internos?

Sí, para servicios internos en producción, usa certificados de tu propia CA o de una CA pública. Los certificados autofirmados causan problemas de confianza; considera usar una PKI privada o herramientas como mkcert para desarrollo.

¿Con qué frecuencia deben renovarse los certificados?

La mejor práctica moderna son certificados de 90 días con renovación automatizada, como ofrece Let's Encrypt. Vidas más cortas reducen el riesgo si una clave se ve comprometida.

¿Listo para asegurar tu sitio? Comienza probando tu configuración TLS actual con un verificador SSL, luego aplica la configuración de Nginx anterior. Para profundizar en seguridad web, explora nuestras otras guías sobre OWASP Top 10 y prevención de XSS.