En la práctica, ¿es seguro establecer el encabezado Strict-Transport-Security en las solicitudes que no son SSL?

Si el requisito es MUST NOT , entonces, en teoría, algunos navegadores pueden mostrar un error en lugar de una página que tiene este encabezado cuando se obtiene mediante HTTP simple. Sin embargo, es muy poco probable.

(Actualización: este comportamiento improbable está realmente prohibido por el mismo RFC)

Claramente, el punto es que a través de HTTP no se puede confiar en que se origine en el servidor original, por lo que si cualquier navegador lo interpretaría cuando se viera con HTTP, entonces este encabezado podría (ab) usarse para forzar que el servidor aparezca sin conexión para una tiempo adicional sin el consentimiento del operador del servidor, con capacidades suficientes para controlar la ruta de la red.

Los nuevos autores de software de UA / cliente todavía podrían cometer un error al interpretar este encabezado, y puede ser una buena protección contra esto si usted exige que nunca se emita HSTS a través de HTTP, de modo que se pueda marcar e informar. como error por cualquier validador.

Aunque no probé esto, con nginx, no es muy complicado decirlo:

if ($scheme = https) {
    add_header Strict-Transport-Security max-age=18000000;
}

El único problema que puedo prever es cuando tienes un SSL limitado que descarga el proxy frontend y no puedes saber fácilmente si la solicitud es SSL o no. En ese caso, realmente debe emitir HSTS a través de HTTP, asumiendo que su CDN / proxy no tiene una forma de configurar HSTS.

Si bien la directiva if se puede usar para limitar el encabezado HSTS a HTTPS, se vuelve desordenada cuando tiene varios bloques location en su archivo de host virtual. Encontré la siguiente solución en un boleto trac de Nginx.

map $scheme $hsts_header {
    https   max-age=31536000;
}

server {
    listen  80;
    listen  443 ssl;

    add_header Strict-Transport-Security $hsts_header;
}