Prise en charge d’IIS 10.0 version 1709 HTTP Strict Transport Security (HSTS)

par Yanbing Shi

Dans IIS 10.0 version 1709, l’administrateur a la possibilité d’activer la redirection HSTS et HTTP vers HTTPS au niveau du site.

Compatibilité

Version	Notes
IIS 10.0 version 1709	Les fonctionnalités décrites dans cet article ont été introduites dans IIS 10.0 version 1709
IIS 10.0 et versions antérieures	Les fonctionnalités décrites dans cet article n’étaient pas prises en charge avant IIS 10.0 version 1709

HSTS (HTTP Strict Transport Security)

HTTP Strict Transport Security (HSTS), spécifié dans RFC 6797, permet à un site web de se déclarer en tant qu’hôte sécurisé et d’informer les navigateurs qu’il doit être contacté uniquement via les connexions HTTPS. HSTS est une amélioration de sécurité d’opt-in qui applique HTTPS et réduit considérablement la capacité des attaques de type intercepteur à intercepter les requêtes et les réponses entre les serveurs et les clients.

HSTS applique l’utilisation du protocole HTTPS via une stratégie qui nécessite la prise en charge des serveurs web et des navigateurs. Un hôte web compatible HSTS peut inclure un en-tête de réponse HTTP spécial « Strict-Transport-Security » (STS) ainsi qu’une directive « max-age » dans une réponse HTTPS pour demander au navigateur d’utiliser HTTPS pour une communication supplémentaire. Le navigateur reçoit l’en-tête et mémorise la stratégie HSTS pour le nombre de secondes spécifié par la directive « max-age ». Au cours de cette période, si un utilisateur tente de visiter le même site web, mais entre http:// ou omet complètement le schéma, le navigateur transforme automatiquement le lien non sécurisé en lien sécurisé (https://) et établit une connexion HTTPS au serveur. Une fois qu’une réponse est reçue via HTTPS, le navigateur empêche également l’utilisateur de « cliquer au travers » de tout avertissement de sécurité (par exemple, un avertissement concernant un certificat de serveur non valide). Pour pouvoir bénéficier de HSTS, il faut que le navigateur voie l’en-tête HSTS au moins une fois. Pour protéger l’utilisateur à la première connexion à un domaine donné, HSTS dispose d’un mécanisme distinct pour précharger une liste de domaines inscrits dans le navigateur hors de la zone.

Défis liés à l’activation de HSTS avant IIS 10.0 version 1709

Avant IIS 10.0 version 1709, l’activation de HSTS sur un serveur IIS nécessite une configuration complexe.

Deux solutions pour activer HSTS avant IIS 10.0 version 1709 sont présentées comme exemple de scénario : l’administrateur web souhaite activer HSTS pour un domaine contoso.com qui accepte à la fois les connexions HTTP et HTTPS et rediriger tout le trafic HTTP vers HTTPS. La redirection dans ce scénario est non sécurisée par nature, mais il s’agit néanmoins d’un schéma appliqué par de nombreux sites web qui prennent en charge HTTPS. La raison fondamentale d’écouter quand même HTTP est que le site web n’a aucun contrôle sur la façon dont les visiteurs peuvent essayer de le connecter – via HTTPS ou simplement HTTP brut. L’activation de HSTS réduit considérablement le nombre de redirections HTTP non sécurisées vers HTTPS à la condition que le navigateur voie l’en-tête STS lors de la première connexion HTTPS réussie (via une visite directe ou une redirection).

Solution 1 : Module de redirection HTTP + En-têtes personnalisés

La redirection de tout le trafic HTTP vers HTTPS peut être obtenue à l’aide du module de redirection HTTP avec deux sites web distincts, l’un pour HTTP et l’autre pour HTTPS, afin d’éviter une boucle de redirection infinie.

<sites>
    <site name="Contoso-http" id="1" serverAutoStart="true">
        <application path="/" applicationPool="Contoso-http">
            <virtualDirectory path="/" physicalPath="C:\inetpub\Contoso-http" />
        </application>
        <bindings>
            <binding protocol="http" bindingInformation="*:80:contoso.com" />
        </bindings>
    </site>
    <site name="Contoso-https" id="2" serverAutoStart="true">
        <application path="/" applicationPool="Contoso-https">
            <virtualDirectory path="/" physicalPath="C:\inetpub\Contoso-https" />
        </application>
        <bindings>
            <binding protocol="https" bindingInformation="*:443:contoso.com" sslFlags="0" />
        </bindings>
    </site>
    <siteDefaults>
        <logFile logFormat="W3C" directory="%SystemDrive%\inetpub\logs\LogFiles" />
        <traceFailedRequestsLogging directory="%SystemDrive%\inetpub\logs\FailedReqLogFiles" />
    </siteDefaults>
    <applicationDefaults applicationPool="DefaultAppPool" />
    <virtualDirectoryDefaults allowSubDirConfig="true" />
</sites>

Une règle de redirection est configurée dans le site web.config du site HTTP pour acheminer tout son trafic vers le site HTTPS, et la version ultérieure sert réellement le contenu.

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
    <system.webServer>
        <httpRedirect enabled="true" destination="https://contoso.com" httpResponseStatus="Permanent" />
    </system.webServer>
</configuration>

Vous pouvez ajouter l’en-tête STS via des en-têtes personnalisés en configurant le fichier web.config du site HTTPS.

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
    <system.webServer>
        <httpProtocol>
            <customHeaders>
                <add name="Strict-Transport-Security" value="max-age=31536000" />
            </customHeaders>
        </httpProtocol>
    </system.webServer>
</configuration>

Solution 2 : Module de réécriture d’URL

Une autre solution consiste à installer le module de réécriture d’URL et à configurer des règles de réécriture pour un site web unique avec des liaisons HTTP et HTTPS. La redirection HTTP vers HTTPS peut être spécifiée par une règle de trafic entrant lors de l’ajout de l’en-tête STS aux réponses HTTPS par une règle de trafic sortant.

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
    <system.webServer>
        <rewrite>
            <rules>
                <rule name="Redirect HTTP to HTTPS" stopProcessing="true">
                    <match url="(.*)" />
                    <conditions>
                        <add input="{HTTPS}" pattern="off" />
                    </conditions>
                    <action type="Redirect" url="https://{HTTP_HOST}/{R:1}" redirectType="Permanent" />
                </rule>
            </rules>
            <outboundRules>
                <rule name="Add the STS header in HTTPS responses">
                    <match serverVariable="RESPONSE_Strict_Transport_Security" pattern=".*" />
                    <conditions>
                        <add input="{HTTPS}" pattern="on" />
                    </conditions>
                    <action type="Rewrite" value="max-age=31536000" />
                </rule>
            </outboundRules>
        </rewrite>
    </system.webServer>
</configuration>

Prise en charge des HSTS natifs d’IIS 10.0 version 1709

Avec la version d’IIS 10.0 version 1709, HSTS est désormais pris en charge en mode natif. La configuration de l’activation de HSTS est considérablement simplifiée : HSTS peut être activé au niveau du site en configurant les attributs de l’élément <hsts> élément sous chaque <site>. Vous trouverez plus de détails dans la référence de configuration des paramètres HSTS pour un site web< HSTS >.

L’exemple de scénario peut être réalisé simplement en configurant les attributs enabled, max-age et redirectHttpToHttps de l’<hsts>élément du site web à l’aide des applets de commande PowerShell IISAdministration en suivant le tutoriel.

Import-Module IISAdministration
Reset-IISServerManager -Confirm:$false
Start-IISCommitDelay

$sitesCollection = Get-IISConfigSection -SectionPath "system.applicationHost/sites" | Get-IISConfigCollection
$siteElement = Get-IISConfigCollectionElement -ConfigCollection $sitesCollection -ConfigAttribute @{"name"="Contoso"}
$hstsElement = Get-IISConfigElement -ConfigElement $siteElement -ChildElementName "hsts"
Set-IISConfigAttributeValue -ConfigElement $hstsElement -AttributeName "enabled" -AttributeValue $true
Set-IISConfigAttributeValue -ConfigElement $hstsElement -AttributeName "max-age" -AttributeValue 31536000
Set-IISConfigAttributeValue -ConfigElement $hstsElement -AttributeName "redirectHttpToHttps" -AttributeValue $true

Stop-IISCommitDelay
Remove-Module IISAdministration

Les configurations HSTS pour le site web sont indiquées ci-dessous :

<site name="Contoso" id="1">
    <application path="/" applicationPool="Contoso">
        <virtualDirectory path="/" physicalPath="C:\Contoso\Content" />
    </application>
    <bindings>
        <binding protocol="http" bindingInformation="*:80:contoso.com" />
        <binding protocol="https" bindingInformation="*:443:contoso.com" sslFlags="0" />
    </bindings>
    <hsts enabled="true" max-age="31536000" redirectHttpToHttps="true" />
</site>

La prise en charge native de HSTS peut également être utilisée avec le module de redirection HTTP pour des scénarios plus complexes.

Par exemple, un site web contoso.com redirige tout le trafic vers son sous-domaine www.contoso.com, et les deux sites web acceptent les connexions HTTP et HTTPS. Il s’agit d’un scénario classique si le site web est préférable pour avoir une adresse canonique unique. Il est recommandé d’activer HSTS pour le domaine racine et le sous-domaine, car les utilisateurs peuvent visiter directement l’un ou l’autre via HTTP ou HTTPS. L’activation de l’élément includeSubDomains l’attribut du <hsts> du domaine racine étend davantage la couverture de la stratégie HSTS à tous ses sous-domaines.

<sites>
    <site name="Contoso" id="1">
        <application path="/" applicationPool="Contoso">
            <virtualDirectory path="/" physicalPath="C:\inetpub\Contoso" />
        </application>
        <bindings>
            <binding protocol="http" bindingInformation="*:80:contoso.com" />
            <binding protocol="https" bindingInformation="*:443:contoso.com" sslFlags="0" />
        </bindings>
        <hsts enabled="true" max-age="31536000" includeSubDomains="true" redirectHttpToHttps="true" />
    </site>
    <site name="Contoso-www" id="2">
        <application path="/" applicationPool="Contoso-www">
            <virtualDirectory path="/" physicalPath="C:\inetpub\Contoso-www" />
        </application>
        <bindings>
            <binding protocol="http" bindingInformation="*:80:www.contoso.com" />
            <binding protocol="https" bindingInformation="*:443:www.contoso.com" sslFlags="0" />
        </bindings>
        <hsts enabled="true" max-age="31536000" redirectHttpToHttps="true" />
    </site>
    <siteDefaults>
        <logFile logFormat="W3C" directory="%SystemDrive%\inetpub\logs\LogFiles" />
        <traceFailedRequestsLogging directory="%SystemDrive%\inetpub\logs\FailedReqLogFiles" />
    </siteDefaults>
    <applicationDefaults applicationPool="DefaultAppPool" />
    <virtualDirectoryDefaults allowSubDirConfig="true" />
</sites>

En outre, la redirection du domaine racine vers le sous-domaine peut être configurée par le biais de l’élément <httpRedirect> dans web.config du site de domaine racine. Avec cette configuration, une requête HTTP à contoso.com est d’abord redirigée vers HTTPS, puis la requête HTTPS au même site est redirigée vers www.contoso.com avec l’en-tête STS ajouté dans la réponse.

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
    <system.webServer>
        <httpRedirect enabled="true" destination="https://www.contoso.com" httpResponseStatus="Permanent" />
    </system.webServer>
</configuration>

Les exemples de configurations ci-dessus s’appliquent également au scénario de redirection du trafic d’un site source vers un site de destination qui n’est pas un sous-domaine du site source, avec une modification mineure de la configuration de désactivation includeSubDomains pour le site source.