Per integrare la risposta di voretaq7 , puoi anche farlo usando il file Web.config (NB: da usare solo per siti SSL, poiché aggiungerà l'intestazione per le risposte HTTP e HTTPS, che è contro la specifica RFC 6797, si prega di consultare la spiegazione di seguito) - aggiungere un blocco come segue:
<system.webServer>
<httpProtocol>
<customHeaders>
<add name="Strict-Transport-Security" value="max-age=31536000"/>
</customHeaders>
</httpProtocol>
</system.webServer>
Ovviamente, potresti già avere un system.webServerblocco nel tuo Web.config, quindi aggiungi questo, se è così. Preferiamo gestire le cose nel Web.config piuttosto che nella GUI, perché significa che le modifiche alla configurazione possono essere impegnate nel nostro repository Git.
Se si desidera gestire il reindirizzamento da HTTP a SSL, come menzionato da Greg Askew , potrebbe essere più semplice farlo con un sito Web separato in IIS. Ecco come gestiamo la richiesta di SSL per alcuni siti client. Quel sito contiene solo un reindirizzamento HTTP e alcune correzioni per la divulgazione di informazioni , tutto in Web.config:
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<system.web>
<httpRuntime requestValidationMode="2.0" enableVersionHeader="false" />
</system.web>
<system.webServer>
<httpRedirect enabled="true" destination="https://www.domain.co.uk/"
httpResponseStatus="Permanent" />
<httpProtocol>
<customHeaders>
<remove name="X-Powered-By" />
</customHeaders>
</httpProtocol>
<rewrite>
<outboundRules>
<rule name="Remove RESPONSE_Server">
<match serverVariable="RESPONSE_Server" pattern=".+" />
<action type="Rewrite" value="" />
</rule>
</outboundRules>
</rewrite>
</system.webServer>
</configuration>
Questa è la nostra soluzione preferita per un paio di motivi: possiamo facilmente registrare separatamente il traffico reindirizzato (poiché si trova in un diverso registro IIS), non comporta più codice in Global.asax.cs (non abbiamo alcun codice lì dentro, che è un po 'più conveniente per un sito Umbraco) e, soprattutto, significa che tutta la configurazione è ancora presente nel nostro repository GIT.
Modificato per aggiungere: per essere chiari, al fine di ottemperare a RFC 6797 , l' Strict-Transport-Securityintestazione personalizzata NON DEVE essere aggiunta alle richieste fatte da HTTP non crittografato. Per essere conforme a RFC6797, DEVI avere due siti in IIS, come ho descritto dopo il primo blocco di codice. Come sottolinea Chris , RFC 6797 include:
Un host HSTS NON DEVE includere il campo di intestazione STS nelle risposte HTTP trasmesse su trasporto non sicuro.
pertanto l'invio Strict-Transport-Securitydell'intestazione del cliente in risposta a una richiesta non SSL non sarebbe conforme alle specifiche.