IIS 10.0, Version 1709: Unterstützung von HTTP Strict Transport Security (HSTS)
von Yanbing Shi
In IIS 10.0, Version 1709 hat der Administrator die Möglichkeit, die HSTS- und HTTP-zu-HTTPS-Umleitung auf Websiteebene zu aktivieren.
Kompatibilität
| Version | Hinweise |
|---|---|
| IIS 10.0, Version 1709 | Die in diesem Artikel beschriebenen Funktionen wurden in IIS 10.0, Version 1709 eingeführt. |
| IIS 10.0 und früher | Die in diesem Artikel beschriebenen Funktionen wurden vor IIS 10.0, Version 1709 nicht unterstützt. |
HTTP Strict Transport Security (HSTS)
HTTP Strict Transport Security (HSTS) wie in RFC 6797 angegeben, ermöglicht es einer Website, sich als sicherer Host zu deklarieren und Browser zu informieren, dass sie nur über HTTPS-Verbindungen kontaktiert werden darf. HSTS ist eine Opt-In-Sicherheitsverbesserung, die HTTPS erzwingt und die Möglichkeiten von Man-in-the-Middle-Angriffen, Anforderungen und Antworten zwischen Servern und Clients abzufangen, erheblich verringert.
HSTS erzwingt die Verwendung von HTTPS über eine Richtlinie, die Unterstützung sowohl von Webservern als auch von Browsern erfordert. Ein Webhost mit aktivierter HSTS kann einen speziellen HTTP-Antwortheader „Strict-Transport-Security“ (STS) zusammen mit einer „max-age“-Anweisung in einer HTTPS-Antwort enthalten, um vom Browser zur weiteren Kommunikation HTTPS anzufordern. Der Browser empfängt die Kopfzeile und merkt sich die HSTS-Richtlinie für die Anzahl der Sekunden, die in der „max-age“-Anweisung angegeben ist. Wenn ein Benutzer innerhalb dieses Zeitraums versucht, dieselbe Website zu besuchen, aber „http://“ eingibt oder das Schema vollständig weglässt, wird der Browser automatisch den unsicheren Link in einen sicheren (https://) umwandeln und eine HTTPS-Verbindung mit dem Server herstellen. Sobald eine Antwort über HTTPS empfangen wird, verhindert der Browser auch, dass der Benutzer eine Sicherheitswarnung „wegklickt“ (z. B. eine Warnung über ein ungültiges Serverzertifikat). Um HSTS nutzen zu können, muss der Browser mindestens einmal den HSTS-Header sehen. Um den Benutzer bei der ersten Verbindung mit einer bestimmten Domäne zu schützen, verfügt HSTS über einen separaten Mechanismus, um vorab eine Liste registrierter Domänen in den Browser zu laden.
Herausforderungen beim Aktivieren von HSTS vor IIS 10.0, Version 1709
Vor IIS 10.0, Version 1709 erfordert das Aktivieren von HSTS auf einem IIS-Server eine komplexe Konfiguration.
Es werden zwei Lösungen zum Aktivieren von HSTS vor IIS 10.0, Version 1709 für ein Beispielszenario bereitgestellt: Der Webadministrator möchte HSTS für eine „contoso.com“-Domäne aktivieren, die sowohl HTTP- als auch HTTPS-Verbindungen akzeptiert, und den gesamten HTTP-Datenverkehr an HTTPS umleiten. Die Umleitung in diesem Szenario ist grundsätzlich unsicher. Dennoch folgen noch immer viele Websites, die HTTPS unterstützen, diesem Muster. Der wesentliche Grund dafür, dass immer noch nach HTTP gelauscht wird, besteht darin, dass die Website keine Kontrolle darüber hat, wie Besucher sich mit ihr zu verbinden versuchen – über HTTPS oder einfach nur über HTTP. Durch Aktivieren von HSTS wird die Anzahl unsicherer HTTP-zu HTTPS-Umleitungen erheblich reduziert, sofern der Browser den STS-Header während der ersten erfolgreichen HTTPS-Verbindung (entweder durch direkten Besuch oder durch Umleitung) sieht.
Lösung 1: HTTP-Umleitungsmodul und benutzerdefinierte Header
Das Umleiten des gesamten HTTP-Datenverkehrs zu HTTPS kann mithilfe des HTTP-Umleitungsmoduls mit zwei separaten Websites erreicht werden – eine für HTTP und die andere für HTTPS – um eine unendliche Umleitungsschleife zu vermeiden.
<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>
Eine Umleitungsregel wird in der „web.config“ der HTTP-Website konfiguriert, um den gesamten Datenverkehr an die HTTPS-Website umzuleiten, und die später tatsächlich die Inhalte bereitstellt.
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<system.webServer>
<httpRedirect enabled="true" destination="https://contoso.com" httpResponseStatus="Permanent" />
</system.webServer>
</configuration>
Der STS-Header kann über Benutzerdefinierte Header hinzugefügt werden, indem die „web.config“ der HTTPS-Website konfiguriert wird.
<?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>
Lösung 2: URL Rewrite Modul
Eine alternative Lösung ist die Installation des URL Rewrite Moduls und das Konfigurieren von Neuschreibungsregeln für eine einzelne Website mit HTTP- und HTTPS-Bindungen. Die HTTP-zu-HTTPS-Umleitung kann durch eine Regel für eingehenden Datenverkehr angegeben werden, während das Hinzufügen des STS-Headers zu HTTPS-Antworten durch eine Regel für ausgehenden Datenverkehr erreicht werden kann.
<?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>
IIS 10.0, Version 1709: Native HSTS-Unterstützung
Ab der Version 1709 von IIS 10.0 wird HSTS jetzt nativ unterstützt. Die Konfiguration für das Aktivieren von HSTS wurde erheblich vereinfacht: HSTS kann auf Standortebene aktiviert werden, indem die Attribute des <hsts>-Elements unter den einzelnen <site>-Elementen konfiguriert werden. Weitere Details finden Sie in der Konfigurationsreferenz von HSTS HSTS Einstellungen für eine Website <HSTS>.
Das Beispielszenario kann einfach erreicht werden, indem die enabled-, max-age- und redirectHttpToHttps-Attribute des <hsts>-Elements der Website mithilfe von IISAdministration PowerShell-Cmdlets konfiguriert werden, wie im Tutorial erläutert.
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
Die HSTS-Konfigurationen für die Website sind unten dargestellt:
<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>
Die native Unterstützung von HSTS kann für komplexere Szenarien auch zusammen mit dem HTTP-Umleitungsmodul verwendet werden.
Beispielsweise leitet eine „contoso.com“-Website den gesamten Datenverkehr zu ihrer www.contoso.com-Subdomäne um, und beide Websites akzeptieren HTTP- und HTTPS-Verbindungen. Dies ist ein typisches Szenario, wenn bevorzugt wird, dass die Website eine einzelne kanonische Adresse hat. Das Aktivieren von HSTS wird sowohl für die Stammdomäne als auch für die Subdomäne empfohlen, da Benutzer eine der beiden möglicherweise direkt über HTTP oder HTTPS besuchen. Das Aktivieren des includeSubDomains-Attributs des <hsts>-Elements der Stammdomäne erweitert die Abdeckung der HSTS-Richtlinie auf alle untergeordneten Subdomänen.
<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>
Darüber hinaus kann die Umleitung von der Stammdomäne zur Subdomäne über das <httpRedirect>-Element in der „web.config“ der Stammdomänensite konfiguriert werden. Bei einer solchen Konfiguration wird zunächst eine HTTP-Anforderung an „contoso.com“ an HTTPS umgeleitet. Dann wird die HTTPS-Anforderung an dieselbe Website an www.contoso.com umgeleitet, wobei der STS-Header zur Antwort hinzugefügt wird.
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<system.webServer>
<httpRedirect enabled="true" destination="https://www.contoso.com" httpResponseStatus="Permanent" />
</system.webServer>
</configuration>
Die obigen Beispielkonfigurationen gelten auch für das Szenario der Umleitung von Datenverkehr von einer Quell- zu einer Zielwebsite, die keine Subdomäne der Quellwebsite ist, allerdings mit einer geringfügigen Konfigurationsänderung: der Deaktivierung von includeSubDomains für die Quellwebsite.
Feedback
Bald verfügbar: Im Laufe des Jahres 2024 werden wir GitHub-Issues stufenweise als Feedbackmechanismus für Inhalte abbauen und durch ein neues Feedbacksystem ersetzen. Weitere Informationen finden Sie unter https://aka.ms/ContentUserFeedback.
Feedback senden und anzeigen für