HSTS su siti disponibili su HTTP e HTTPS

Le intestazioni HSTS inviate su HTTP vengono ignorate dai browser conformi alle specifiche - questo per evitare che un man-in-the-middle impedisca ai visitatori di accedere a un sito Web non HTTPS impostando una regola HSTS nel browser. (vedi RFC 6797 )

Pertanto, puoi tranquillamente, anche se tecnicamente non correttamente, fornire intestazioni HSTS a tutti i tuoi utenti e fornire le stesse pagine su HTTP e HTTPS e deliberatamente non reindirizzare da pagine non sicure a quelle protette.

Ciò avrà come effetto il fatto che i visitatori che visitano la tua versione HTTPS saranno costretti a tornare ad esso nelle visite future (per la durata dell'intestazione, almeno), e i visitatori che visiteranno deliberatamente la tua versione HTTP rimarranno su questo. Se seguono un collegamento alla versione HTTPS in qualsiasi momento, saranno costretti a HTTPS in futuro.

A seconda che abbia senso, dipende dai tuoi obiettivi e dai tuoi visitatori: hai molti visitatori da proxy danneggiati? Fornisci informazioni che potrebbero essere incriminanti in alcune pagine?

Personalmente, servirò solo la versione sicura e ho un reindirizzamento forzato da quello non sicuro, soprattutto dal momento che i motori di ricerca sembrano orientarsi preferendo siti sicuri.

L'intestazione HSTS non ha effetto mentre si accede al sito tramite HTTP.

L'obiettivo di HSTS è di forzare il browser a caricare il sito su HTTPS, avendo la possibilità di visualizzarlo su HTTP è contro-intuitivo.

I'm wondering if it makes sense to enable HSTS on a site that is served over HTTPS as well as over HTTP.

Non sono del tutto certo per l'HSTS, ma penso di sì.

(L'idea in sé è sana ed è simile a ciò che " Crittografia opportunistica " ha in mente: fai l'attaccante lavorare di più usando almeno una parte della crittografia per almeno alcune connessioni.)

L'abstract della RFC dice questo:

This specification defines a mechanism enabling web sites to declare themselves accessible only via secure connections and/or for users to be able to direct their user agent(s) to interact with given sites only over secure connections.

E il "e / o" bit della frase sembra importante qui.

Quindi ciò che puoi fare tramite HSTS è qualcosa di simile a: Questo sito è completamente HTTPS. Questo sito funzionerà per te anche se il tuo firewall blocca tutte le connessioni alla porta 80. E come ripensamento: Se ci fosse un semplice collegamento HTTP lasciato da qualche parte qui intorno, allora è un errore, ti preghiamo di aggiornarlo tranquillamente in HTTPS.

E questo bit di silent-upgrade-xor-failure ti salverebbe da uno scenario che danno qui: (sezione 2.3.1.3)

Even if the site's developers carefully scrutinize their login page for "mixed content", a single insecure embedding anywhere on the overall site compromises the security of their login page because an attacker can script (i.e., control) the login page by injecting code (e.g., a script) into another, insecurely loaded, site page.

E mentre ci si aspetta che il server reindirizzi il client a HTTPS ( sezione 7.2 ):

If an HSTS Host receives an HTTP request message over a non-secure transport, it SHOULD send an HTTP response message containing a status code indicating a permanent redirect,

... questo è un DOVREBBE e non un MUST.

Quindi, in sintesi: sì, quello che chiedi dovrebbe essere sia un possibile e legittimo uso di HSTS.

Un'altra cosa: se desideri supportare gli utenti di laptop che possono utilizzare sia la versione HTTPS del tuo sito (ad es. da casa) che la versione HTTP del tuo sito (ad esempio dal WIFI dell'ufficio), dovrai impostare il timeout dell'HSTS è sufficientemente basso. (A pochi minuti forse.)