AldeaCode Logo
Security Cabecera HSTS: Cómo Evitar el SSL Stripping
Security AldeaCode Architecture

Cabecera HSTS: Cómo Evitar el SSL Stripping

Cómo funciona la cabecera HSTS, cómo configurarla en Nginx, Apache o Cloudflare, y cómo entrar en la lista de preload del navegador.

Qué resuelve HSTS realmente

Cuando un usuario escribe ejemplo.com, el navegador no sabe si tu web habla HTTPS o HTTP. Por defecto prueba el puerto 80 (HTTP). Tu servidor responde con un 301 hacia HTTPS. Esa primera petición en plano es el problema.

En los milisegundos antes de que llegue el redirect, cualquiera en la misma red (un Wi-Fi de cafetería, el router de un hotel, un nodo ISP comprometido) puede interceptarla y servir una página falsa por HTTP. El usuario ve la web, en la barra pone http://, y el atacante hace de proxy con el tráfico real. Esto es SSL stripping. El candado nunca aparece, pero casi nadie lo mira.

HSTS es una sola cabecera HTTP que le dice al navegador: “a partir de ahora, nunca hables HTTP con este dominio”. El navegador guarda esa regla en local. La próxima vez que el usuario escriba ejemplo.com, el navegador reescribe la URL a https://ejemplo.com antes de que la petición salga del equipo. Ya no hay petición HTTP que interceptar.

Puedes inspeccionar las reglas guardadas en Chrome desde chrome://net-internals/#hsts.

La pega de la primera visita

HSTS solo funciona después de que el navegador haya visto la cabecera al menos una vez. La primerísima visita, en un dispositivo nuevo, todavía pasa por HTTP y el redirect. Esa ventana es pequeña, pero existe.

La solución para esa ventana es la lista de Preload (más abajo).

La cabecera, parte por parte

Strict-Transport-Security: max-age=63072000; includeSubDomains; preload
  • max-age es el tiempo en segundos que el navegador mantiene la regla. 63072000 son dos años.
  • includeSubDomains extiende la regla a todos los subdominios. Potente y fácil de usar mal.
  • preload es tu declaración de intención para entrar en la lista de preload del navegador. No te incluye automáticamente.

Despliégalo sin dejarte fuera

El error más típico con HSTS es lanzar max-age=63072000; includeSubDomains el primer día y descubrir tres horas después que el panel interno en facturacion.ejemplo.com no tiene certificado. Los navegadores que ya cachearon la regla se negarán a abrirlo. No puedes arreglarlo desde el servidor. El navegador mantendrá la regla hasta que expire.

Hazlo por fases:

  1. Empieza con max-age=300 (cinco minutos). Sin includeSubDomains todavía.
  2. Audita todos los subdominios. Herramientas internas, servidores de logs, staging, esa impresora. Asegúrate de que HTTPS funciona en todos.
  3. Tras una semana sin incidencias, sube max-age a una semana, luego un mes, luego un año.
  4. Cuando estés seguro de que todos los subdominios sirven HTTPS limpio, añade includeSubDomains.
  5. Solo entonces añade preload y envía a la lista.

Si algo se rompe en el paso 1 o 2, lo arreglas antes de que ningún usuario haya cacheado una regla larga.

Configuración por servidor

Nginx

add_header Strict-Transport-Security "max-age=300" always;

El flag always importa. Sin él, Nginx no envía la cabecera en respuestas de error (500, 502, 504). Si un usuario topa con un error en una red hostil y su regla HSTS ha expirado, queda sin protección en el peor momento.

Cuando estés listo para subir:

add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;

Apache

En tu virtual host o .htaccess:

Header always set Strict-Transport-Security "max-age=300"

Necesitas que el módulo mod_headers esté activo. En hostings compartidos suele estarlo. Si no lo está, esta línea provocará un 500 en cada petición, así que prueba en staging primero.

Cloudflare

En el panel: SSL/TLS, Edge Certificates, HSTS. Lo activas, eliges max-age, eliges si incluyes subdominios.

El truco: activar includeSubDomains aquí es irreversible desde el punto de vista del usuario. Si un subdominio se salta el proxy (nube naranja apagada) y no tiene certificado válido, ese subdominio queda inalcanzable para todo usuario cuyo navegador haya cacheado la regla. Cloudflare te da un botón y las consecuencias son tuyas.

Cómo verificar

Fíate de lo que recibe el navegador, no de lo que dice el archivo de configuración.

curl -I https://ejemplo.com | grep -i strict

Deberías ver Strict-Transport-Security: max-age=....

En el navegador, abre DevTools, pestaña Network, clic en el documento HTML, y busca en Response Headers. La cabecera tiene que estar.

Para mirar más a fondo, chrome://net-internals/#hsts te deja consultar un dominio concreto y ver la regla cacheada, su caducidad y si tiene includeSubDomains.

La lista de Preload

La lista de preload es una lista cableada dentro de Chrome, Firefox, Safari y Edge. Los dominios incluidos reciben la regla HTTPS desde la primerísima visita, antes de recibir ninguna cabecera. Cierra la ventana de la primera visita.

Requisitos:

  • Certificado SSL válido en el ápex y en www.
  • El puerto 80 redirige a HTTPS en el mismo host.
  • Todos los subdominios servidos sobre HTTPS.
  • La cabecera sirve max-age de al menos un año, más includeSubDomains y preload.

Envía tu dominio en hstspreload.org. Salir de la lista es lento (meses, a veces más), así que solo envía cuando estés seguro.

Sobre los reguladores

Las autoridades europeas de protección de datos consideran HSTS parte de las “medidas técnicas apropiadas” del artículo 32 del RGPD para sitios que tratan datos personales. Resoluciones recientes citan la falta de seguridad en el transporte como un factor agravante (Carrefour fue multada con tres millones de euros por la CNIL en 2020 por un conjunto de fallos que incluía protecciones de transporte insuficientes). No es la única razón para configurar HSTS, pero ante una auditoría tenerlo bien puesto es una respuesta limpia.

Efecto colateral en rendimiento

Con HSTS cacheado, el navegador se salta el redirect HTTP a HTTPS. En redes móviles eso ahorra entre 200 y 500 ms en la primera petición a tu dominio. Además impide que Google indexe la versión HTTP de tus URLs, lo que evita casos raros de contenido duplicado.

Para una configuración de cabeceras más completa, mira nuestra guía de Content Security Policy y el artículo de seguridad técnica y cumplimiento LOPD. La SEO Expert App detecta cabeceras de seguridad ausentes de forma automática.

FAQ

Lo que hacemos

Webs honestas, sin atajos.

Ingeniería real y diseño cuidado. Si te ha gustado el post, hablemos del tuyo.

Hablemos →

Te puede interesar

Ver todos los artículos →