In pratica, è sicuro impostare l'intestazione Strict-Transport-Security su richieste non SSL?

Se il requisito è MUST NOT , in teoria alcuni browser possono visualizzare un errore invece di una pagina che ha questa intestazione quando viene recuperata tramite semplice HTTP. È altamente improbabile però.

(Aggiornamento: questo comportamento improbabile è effettivamente vietato dalla stessa RFC.)

Chiaramente il punto è che su HTTP non ci si può fidare di nulla che provenga dal server originale, quindi se un qualsiasi browser lo interpretasse quando viene visto con HTTP, allora questa intestazione potrebbe essere (ab) usata per forzare la visualizzazione offline del server per un tempo prolungato senza il consenso dell'operatore del server, con capacità sufficienti per controllare il percorso di rete.

Nuovi autori di software UA / client potrebbero ancora commettere un errore nell'interpretazione di questa intestazione, e può essere una buona protezione contro questo se si rende necessario non rilasciare mai HSTS via HTTP - in modo che possa essere contrassegnato e segnalato come errore da qualsiasi validatore.

Anche se non l'ho provato, con nginx, non è molto complicato dire:

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

L'unico problema che posso prevedere è quando si dispone di un SSL limitato che scarica il proxy di frontend e non si può facilmente capire se la richiesta è SSL o meno. In questo caso, in realtà devi emettere HSTS tramite HTTP, supponendo che il tuo CDN / proxy non abbia un modo per configurare HSTS.

Sebbene la direttiva if possa essere utilizzata per limitare l'intestazione HSTS a HTTPS, diventa caotica quando si hanno più blocchi location nel file dell'host virtuale. Ho trovato la seguente soluzione in un ticket Trac di Nginx.

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

server {
    listen  80;
    listen  443 ssl;

    add_header Strict-Transport-Security $hsts_header;
}