Microsoft unterstützt seit Kurzem ganz offiziell HSTS (HTTP Strict Transport Security). In der Standardeinstellung ist HSTS jedoch nicht aktiviert und muss daher vom Benutzer aktiviert werden. Zunächst aber ein paar Worte zu HSTS und der Funktionsweise.
Was ist HSTS und wie funktioniert es?
Bei HTTP Strict Transport Security (HSTS) handelt es sich um eine Richtlinie um dem Browser anzuweisen, dass eine Webseite nur per HTTPS aufgerufen werden darf. HSTS verwendet dazu einen HTTP-Header, welcher dem Browser verschiedene Parameter mitteilt. Ruft beispielsweise ein Benutzer zum ersten Mal OWA auf einem Exchange Server auf, wird dem Browser per HSTS Header angewiesen Verbindungen zu dieser Webseite (und ggf. den Subdomains) nur noch per HTTPS herzustellen. Der HSTS-Header enthält außerdem eine Zeitangabe, in der der Browser die HSTS-Richtlinie speichern und befolgen muss.
Mit dem HSTS-Header soll somit verhindert werden, dass Browser schlimmstenfalls eine unverschlüsselte Verbindung zur OWA Webseite aufbauen und Benutzer ihre Zugangsdaten unverschlüsselt übertragen. Ebenfalls unterbinden Browser bei aktiver HSTS-Richtlinie, dass der Benutzer eine Zertifikatswarnung ignorieren kann. Ohne HSTS können Benutzer die Zertifikatswarnungen einfach ignorieren und werden in manchen Umgebungen ja auch gerade dazu trainiert:
HSTS soll zum einen dieses Ignorieren der Zertifikatsfehler durch den Benutzer verhindern, sowie auch Man-in-the-Middle, Copokie Hijacking und SSL Downgrade Angriffe. Natürlich ist es dann zwingend erforderlich, dass das Zertifikat gültig ist und rechtzeitig vor Ablauf erneuert wird. Die Zeitangabe in der HSTS-Richtlinie soll verhindern, dass bei fehlendem HSTS-Header der Browser einfach wieder eine unsichere Verbindung herstellen. Sprich, HSTS einschalten, Mist bauen, HSTS abschalten, g eht so nicht.
HSTS auf Windows Server aktivieren
HSTS kann auf Windows Server 2019 und Windows Server 2022 bequem über den IIS Manger aktiviert werden. HSTS darf dabei nur auf der Default Web Site ein geschaltet werden:
Der Parameter „Max-Age“ legt fest, wie lange der Browser die HSTS RIchtlinie speichern soll. Zum Start können hier 300 Sekunden eingestellt werden. HSTS lässt sich mit den 300 Sekunden testen, lasst es mal ein paar Tage mit dieser Einstellung laufen. Treten keine Probleme auf, sollte hier ein deutlich höherer Wert eingetragen werden. Nach erfolgreichen Test kann man hier beispielsweise 31536000 Sekunden (1 Jahr) oder sogar 63072000 Sekunden (2 Jahre) konfigurieren:
Auf Windows Server 2016 ist die Einstellung nicht in der IIS Manager GUI verfügbar. Hier kann die PowerShell bemüht werden:
Import-Module IISAdministration
Reset-IISServerManager -Confirm:$false
Start-IISCommitDelay
$iisConfig = Get-IISConfigSection -SectionPath "system.webServer/httpProtocol" -CommitPath "Default Web Site" | Get-IISConfigCollection -CollectionName "customHeaders"
New-IISConfigCollectionElement -ConfigCollection $iisConfig -ConfigAttribute @{"name"="Strict-Transport-Security"; "value"="max-age=300; includeSubDomains";}
Stop-IISCommitDelay
Remove-Module IISAdministration
Falls HSTS Probleme verursacht, kann das Feature direkt im IIS Manager deaktiviert werden. Hier muss man dann bedenken, dass der Browser die Richtlinie für 5 Minuten (300 Sekunden) speichert. Über die PowerShell kann HSTS mit den folgenden Befehlen deaktiviert werden:
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"="Default Web Site"}
$hstsElement = Get-IISConfigElement -ConfigElement $siteElement -ChildElementName "hsts"
Set-IISConfigAttributeValue -ConfigElement $hstsElement -AttributeName "enabled" -AttributeValue $false
Set-IISConfigAttributeValue -ConfigElement $hstsElement -AttributeName "max-age" -AttributeValue 0
Set-IISConfigAttributeValue -ConfigElement $hstsElement -AttributeName "includeSubDomains" -AttributeValue $false
Stop-IISCommitDelay
Remove-Module IISAdministration
Einstellung prüfen
Nachdem HSTS aktiviert wurde, lässt es sich mit einem Browser wie beispielsweise Edge prüfen, ob der HSTS Header durch die Webserver gesendet wird. Hierzu kann man einmal OWA aufrufen und danach via edge://net-internals/#hsts prüfen, ob Edge HSTS anzeigt:
Wenn Edge, wie im Screenshot zu sehen, die Richtlinie anzeigt, funktioniert HSTS korrekt.
wie verhält sich das mit einer WAF (Sophos)?
Genauso. Nur hilft es nach extern nix, da müßte das auf der WAF konfiguriert werden. Da die Sophos das afair nicht per GUI anbietet, müßte man irgendwie per shell ran.
Nun habe ich das leider vorher nicht getestet, weiß also nicht, ob das nun von meiner Sophos-WAF oder meinem Exchange kommt, aber: Nach dem Setzen der Einstellungen auf dem EX und ohne an der Sophos WAF was gemacht zu haben, ist der o.g. „Edge-Test“ extern erfolgreich (Intern auch, aber da ist die WAF ja raus).
Set-IISConfigAttributeValue -ConfigElement $hstsElement -AttributeName „preload“ -AttributeValue $false
Hi, hast du vergessen
Ich frage mich, was das den soll. Generell sollte ein exchange an einer Firewall nur auf 443 hören. Wenn dann noch das Zertifikat auf der FW und dem Exchange liegt, dann kann auch IPS genutzt werden.
Warum man jetzt noch HSTS aktivieren sollte, erschließt sich mir nicht ganz
Ist ja auch keine Sicherheit für den Server, sondern für den Client. Der Client stellt dann nicht „schädlicherweise“ eine Verbindung zu kompromitierten Systemen her, nur weil die sich als dein Exchange ausgeben.
Ich überlege immer noch wer den Exchange so im Internet hat, dass diese Einstellung überhaupt Sinn macht – alleine das ist ja schon Fahrlässig.
Was hat das mit Internet zu tun?
Anmerken muß man dabei aber, das HSTS bei selbstsignierten Zertifikaten den Zugriff auf die Webseite blockiert.
Danke Franky für diese eindeutige Erklärung! Genial! :D
„Sprich, HSTS einschalten, Mist bauen, HSTS abschalten, geht so nicht.“
Warum auch immer das bei ms so lange gedauert hat. Ich vermute fast jeder der vor dem exchange einen Reverse Proxy hat, hat hsts schon seit Jahren aktiv. ;)