HTTP, HTTPS y TLS: Parte 7 — Transición a HTTPS: redirecciones, HSTS, HTTPS-First y el encabezado Upgrade

El usuario escribe en la barra de direcciones example.ru sin esquema, sigue un enlace antiguo http://… o abre un marcador de hace una década. En todos estos casos la primera petición puede ir por HTTP sin cifrar, y la tarea del propietario del sitio es que luego todo vaya por HTTPS, y en lo ideal — que no haya petición abierta en absoluto. Para ello existen varios mecanismos que actúan en diferentes etapas: redirección en el servidor, HSTS, la lista integrada preload, el modo HTTPS-First en el navegador, registro DNS de tipo HTTPS. Separadamente se analiza el encabezado Upgrade, con el que a menudo se confunde la «actualización a HTTPS»: él cambia el protocolo por otro, por ejemplo WebSocket.

Redirección de HTTP a HTTPS

Nivel básico — el servidor en el puerto 80 responde con una redirección a la misma dirección por HTTPS:

server {
    listen 80;
    listen [::]:80;
    server_name example.ru www.example.ru;

    location /.well-known/acme-challenge/ {
        root /var/www/letsencrypt;   # comprobación Let's Encrypt HTTP-01
    }

    location / {
        return 301 https://$host$request_uri;
    }
}

Lo que importa:

• 301 o 308. Ambos son redirecciones permanentes; los motores de búsqueda transfieren el peso de la página a la nueva dirección. 308 preserva el método y el cuerpo de la petición; con 301 el navegador convierte POST en GET. Para un sitio la diferencia suele ser inapreciable, para una API donde los clientes envían por error POST a http:// es mejor 308.
• Conservar la ruta. $request_uri contiene la ruta y los parámetros. Redirigir todas las páginas a la página principal rompe enlaces y los resultados de búsqueda.
• Un solo paso. La cadena http://example.ru → https://example.ru → https://www.example.ru son dos vueltas innecesarias. Dirija directamente a la dirección final.
• Let’s Encrypt HTTP-01 sigue las redirecciones, por lo que un location separado para acme-challenge no es obligatorio, pero evita sorpresas con configuraciones no estándar.

El punto débil de la redirección: la primera petición sigue siendo abierta. Un atacante en la misma red (por ejemplo, en Wi-Fi público) puede interceptarla y no dejar que el usuario llegue a HTTPS, sirviéndole el sitio por HTTP a través de sí mismo. Esta técnica se llama SSL stripping, y HSTS protege contra ella.

HSTS

HSTS (HTTP Strict Transport Security, RFC 6797) es un encabezado de respuesta con el que el sitio le dice al navegador: «durante el tiempo indicado, comunícate conmigo solo por HTTPS».

Strict-Transport-Security: max-age=31536000; includeSubDomains

• max-age — tiempo en segundos (31536000 = un año). Cada respuesta con el encabezado renueva el periodo;
• includeSubDomains — la regla se aplica a todos los subdominios;
• preload — consentimiento para la inclusión en la lista preload (más abajo).

Al recibir el encabezado, el navegador:

1. reescribe por sí mismo cualquier enlace http:// a ese sitio en https:// antes de enviar la petición — la redirección del servidor deja de ser necesaria (en las herramientas de desarrollador se ve como 307 Internal Redirect);
2. no permite al usuario omitir un error de certificado: no hay botón «Continuar de todos modos».

Reglas:

• el navegador acepta el encabezado solo por HTTPS; en la respuesta por HTTP lo ignora;
• empiece con un max-age pequeño (300, luego 86400, luego una semana) e increméntelo cuando esté seguro de que todo funciona por HTTPS. No se puede cancelar HSTS rápidamente: los navegadores que hayan memorizado el encabezado exigirán HTTPS hasta el fin del periodo;
• verifique includeSubDomains con especial cuidado: si tiene intranet.example.ru o printer.example.ru sin HTTPS, después de activarlo dejarán de abrirse para todos los que visitaron el dominio principal.

En Nginx:

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

Lista HSTS preload

HSTS empieza a actuar después de la primera visita por HTTPS. La primera visita queda sin protección. Para cubrir también esa primera visita existe la lista preload — un listado de dominios incorporado en Chrome, Firefox, Safari y Edge. Para los dominios de la lista el navegador usa solo HTTPS desde la primera petición.

Requisitos para la inclusión (hstspreload.org):

1. certificado válido;
2. redirección de HTTP a HTTPS en el mismo nombre de host;
3. todos los subdominios accesibles por HTTPS;
4. encabezado en el dominio principal: max-age no menor de 31536000, includeSubDomains y preload.

Se puede solicitar en hstspreload.org; entrar en las versiones estables de los navegadores lleva semanas. El borrado de la lista lleva meses y no afecta a versiones antiguas de navegadores, por lo que preload es en la práctica irreversible. Algunas zonas de dominio están incluidas por completo: todos los sitios en .dev, .app, .page funcionan solo por HTTPS.

HTTPS-First en los navegadores

Los navegadores no esperan a que el sitio configure HSTS, y por sí mismos prueban HTTPS.

• Chrome desde la versión 115 (2023) al acceder a http:// primero intenta HTTPS y, si falla, vuelve a HTTP (HTTPS-Upgrades). La opción «Siempre usar conexiones seguras» (Always Use Secure Connections) además advierte antes de abrir el sitio por HTTP. Google anunció que en Chrome 154 (octubre de 2026) esta opción estará activada por defecto: el navegador preguntará al usuario antes de la primera visita a un sitio público sin HTTPS y no repetirá la advertencia para sitios que el usuario visite con regularidad. Para usuarios con el modo reforzado Safe Browsing está activada desde abril de 2026.
• Firefox desde la versión 136 (marzo de 2025) funciona en modo HTTPS-First por defecto: intenta HTTPS y retrocede a HTTP si el sitio no responde. Hay además un modo más estricto HTTPS-Only.
• Safari también intenta HTTPS para direcciones sin esquema.

Qué significa esto para el propietario del sitio: si por HTTPS en su dominio se abre algo distinto que por HTTP (plantilla del hosting, sitio ajeno en la misma IP, error de certificado), los usuarios cada vez más verán precisamente eso. HTTPS debe funcionar en todos los nombres que usted publique, y los sitios sin HTTPS irán acompañados de una advertencia.

Upgrade-Insecure-Requests y contenido mixto

Contenido mixto — una página por HTTPS que carga scripts, estilos o imágenes por HTTP. Los navegadores bloquean esos scripts, estilos y frames; las imágenes, vídeos y audios intentan cargarse por HTTPS y si no es posible no se muestran.

Dos cosas con nombres parecidos:

• Encabezado de petición Upgrade-Insecure-Requests: 1. El navegador lo envía al acceder a una página, indicando: «prefiero HTTPS». El servidor puede responder a él con una redirección a HTTPS. En la práctica con una redirección normal suele ser suficiente; este encabezado se usa raramente.

• Directiva CSP upgrade-insecure-requests. Encabezado de respuesta que ordena al navegador reescribir todos los recursos http:// en la página a https:// antes de cargarlos:

  Copy

  Content-Security-Policy: upgrade-insecure-requests

  Útil al migrar un sitio antiguo con miles de enlaces a imágenes http://: mientras no se corrijan los enlaces, la directiva elimina las advertencias. Los recursos deben estar disponibles por HTTPS — la directiva no crea HTTPS donde no existe.

Registro DNS HTTPS

Un registro tipo HTTPS (RFC 9460) informa al cliente de parámetros de conexión antes de la primera petición:

example.ru.  3600  IN  HTTPS  1 . alpn="h3,h2" ipv4hint=192.0.2.10

• la mera presencia del registro le indica al navegador que el sitio está disponible por HTTPS: Chrome y Firefox en ese caso van directamente a https://, evitando el HTTP abierto, igual que con HSTS;
• alpn — qué protocolos se soportan; con h3 el navegador puede conectar directamente por HTTP/3;
• ech — clave para Encrypted Client Hello;
• ipv4hint, ipv6hint — direcciones para no esperar la respuesta a A/AAAA.

Cloudflare soporta el registro (lo crea automáticamente) y algunos hostings DNS también. Comprobarlo: dig HTTPS example.ru.

Encabezado Upgrade: cambio de protocolo

Upgrade es un mecanismo de HTTP/1.1 para pasar de HTTP a otro protocolo dentro de la misma conexión TCP. El cliente propone, el servidor acepta con 101 Switching Protocols, y a partir de ahí por la conexión va el nuevo protocolo.

WebSocket (RFC 6455) es el ejemplo principal. En qué se diferencia WebSocket de SSE y long polling y cuándo elegir cada uno está en el artículo «WebSockets, Long Polling y SSE». Aquí — cómo se ve la propia transición:

GET /ws HTTP/1.1
Host: example.ru
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Sec-WebSocket-Version: 13

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=

La dirección wss:// es WebSocket sobre TLS, es decir, primero se establece HTTPS y dentro de él se hace el Upgrade.

Upgrade y Connection son encabezados de una misma etapa, y los proxies no los reenvían más allá. Por eso para WebSocket detrás de Nginx se necesita una configuración explícita:

map $http_upgrade $connection_upgrade {
    default upgrade;
    ''      close;
}

server {
    location /ws/ {
        proxy_pass http://127.0.0.1:8080;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection $connection_upgrade;
        proxy_read_timeout 3600s;   # por defecto 60 s — la conexión inactiva se cerrará
    }
}

Sin estas líneas el cliente recibirá 400 o 426, y en el registro de la aplicación habrá un GET normal sin Upgrade.

En HTTP/2 y HTTP/3 no existe el encabezado Upgrade. WebSocket en ellos se abre mediante el método extendido CONNECT (RFC 8441 para HTTP/2, RFC 9220 para HTTP/3) con el pseudocabecero :protocol: websocket. Navegadores y servidores lo negocian entre sí; Nginx sigue comunicándose con la aplicación por HTTP/1.1.

Otras aplicaciones de Upgrade:

• Upgrade: h2c — pasar a HTTP/2 sin cifrar. Los navegadores nunca lo soportaron, y el RFC 9113 (2022) lo declaró obsoleto. Los proxies que permiten pasar Upgrade: h2c a la aplicación a veces permiten eludir sus reglas de acceso (h2c smuggling) — es mejor descartar esos encabezados en la entrada;
• Upgrade: TLS/1.0 — pasar a TLS dentro de la conexión HTTP (RFC 2817). No se adoptó en la web; en su lugar se usa el puerto separado 443.

Si el servidor requiere cambiar a otro protocolo responde con el código 426 Upgrade Required y el encabezado Upgrade indicando el protocolo necesario.

Orden para migrar el sitio a HTTPS

1. Emitir certificado para todos los nombres usados, incluyendo www, y configurar renovación automática.
2. Verificar que el sitio funciona completamente por HTTPS: enlaces internos, imágenes, formularios, widgets de terceros. Para enlaces antiguos en el contenido — CSP upgrade-insecure-requests.
3. Habilitar redirección 301 de HTTP a HTTPS, conservando la ruta.
4. Indicar https:// en las direcciones canónicas, el mapa del sitio, en Yandex Webmaster y Google Search Console.
5. Activar HSTS con max-age corto; tras unas semanas — un año y includeSubDomains.
6. Si está seguro de todos los subdominios — enviar el dominio a la lista preload.

Errores típicos

• Redirección infinita: la aplicación detrás del proxy no ve X-Forwarded-Proto: https y vuelve a redirigir a HTTPS; lo mismo ocurre con Cloudflare en modo Flexible.
• HSTS con includeSubDomains en el dominio principal cuando hay subdominios sin HTTPS — los servicios internos dejan de abrirse.
• El encabezado HSTS se entrega por HTTP — el navegador lo ignora, no hay protección.
• Redirigir a la página principal en vez de a la misma página.
• WebSocket detrás de Nginx sin proxy_http_version 1.1 y sin los encabezados Upgrade/Connection, o con proxy_read_timeout por defecto — las conexiones se cortan cada minuto.