# HSTS: So funktioniert die HTTPS-Erweiterung Immer mehr Anbieter im Netz sind bemüht, Internetnutzern einen sicheren Zugang zu Online-Inhalten zu ermöglichen. Im World Wide Web hat sich dafür das **Verschlüsselungsprotokoll TLS** (Transport Layer Security) etabliert. Große Bekanntheit erlangte dieses unter der Vorgängerbezeichnung **SSL** (Secure Sockets Layer). Während Verbindungen zu Webseiten via [HTTP (Hypertext Transfer Protocol)](https://www.ionos.at/digitalguide/hosting/hosting-technik/was-ist-http/ "Was ist HTTP?") unverschlüsselt erfolgen, bietet das Netzwerkprotokoll [HTTPS („Hypertext Transfer Protocol Secure](https://www.ionos.at/digitalguide/hosting/hosting-technik/was-ist-https/ "Was ist HTTPS?")“ oder „Hypertext Transfer Protocol over SSL/TLS“) dank SSL/TLS-Verschlüsselung die Möglichkeit, den Datenverkehr im Web sicherer zu gestalten. Auch Internetgigant Google geht mit gutem Beispiel voran und bietet seine vielbesuchten Webservices ausschließlich SSL/TLS-verschlüsselt an. Seit August 2014 fließt HTTPS zudem als [Rankingfaktor](https://webmasters.googleblog.com/2014/08/https-as-ranking-signal.html "Mehr zu HTTPS auf dem Google Webmaster Central Blog") in den Algorithmus der organischen Websuche ein. Damit ist die Relevanz einer SSL/TLS-gestützten Transportverschlüsselung für Webseitenbetreiber deutlich gestiegen. Einen zuverlässigen Schutz bietet HTTPS in der Standardkonfiguration jedoch nicht. Immer wieder decken IT-Experten **Sicherheitslücken** auf. Gefahren sind vor allem [**Man-in-the-Middle-Attacken**](https://www.ionos.at/digitalguide/server/sicherheit/man-in-the-middle-attack-angriffsmuster-im-ueberblick/ "Man-in-the-middle-Attack: Angriffsmuster im Überblick"), die es Hackern ermöglichen, die SSL/TLS-Verschlüsselung auszuhebeln. Erst seit 2012 steht mit HSTS ein **Sicherheitsmechanismus für HTTPS-Verbindungen** zur Verfügung, der Angriffe dieser Art unterbindet. ## Mehr zu HTTPS auf dem Google Webmaster Central Blog Wird eine Website über das Netzwerkprotokoll [HTTPS](https://www.ionos.at/digitalguide/websites/webseiten-erstellen/wie-stelle-ich-meine-seite-auf-ssl-und-https-um/) und ein **zuverlässiges [SSL/TLS-Zertifikat](https://www.ionos.at/sicherheit/ssl-zertifikat "SSL Zertifikat kaufen")** aufgerufen, ist diese Art der Transportverschlüsselung prinzipiell sicher. In der Vergangenheit kam es jedoch immer wieder zu Angriffen auf Zertifizierungsstellen, die zur Folge hatten, dass eine Vielzahl unsicherer Zertifikate in Umlauf kam. Zudem bieten verbreitete Nutzungsgewohnheiten und die allgemeine Unachtsamkeit im Umgang mit verschlüsselten Verbindungen zahlreiche Angriffspunkte für Phishing-Attacken und Man-in-the-Middle-Angriffe. ### Umleitung von HTTP auf HTTPS Internetnutzer geben URLs nur selten vollständig ein. Stattdessen werden Internetadressen auf ihre Domain verkürzt. Das Netzwerkprotokoll HTTPS, das die verschlüsselte Verbindung sicherstellen soll, geht dabei verloren. Tippt ein Internetnutzer beispielsweise statt *https:// example.com* lediglich *example.com* in die Adresszeile seines Browsers ein, ergänzt dieser die offensichtlich als URL zu interpretierende Suchanfrage automatisch um das Standard-Netzwerkprotokoll für Webseitenaufrufe: HTTP. *example.com* -> *http:// example.com* Handelt es sich bei der Zielseite um eine verschlüsselte Website, kommt es erst im Anschluss zur serverseitigen Weiterleitung von HTTP auf HTTPS. *http:// example.com -> https:// example.com* So wird letztendlich zwar eine verschlüsselte Verbindung hergestellt, der Umweg über die unverschlüsselte URL gibt Hackern jedoch die Möglichkeit, sich schon vorher unbemerkt als Man-in-the-Middle zwischen Browser und Server zu positionieren. In diesem Fall kann sämtlicher Datenverkehr im Klartext mitgelesen werden, ohne dass sich Angreifer die Mühe machen müssen, die SSL/TLS-Verschlüsselung zu knacken. Handelt es sich bei der Zielseite um eine Direktbank oder einen Onlineshop, kann diese Sicherheitslücke für Nutzer, die Geldgeschäfte online abwickeln, gravierende Folgen haben. Veranschaulichen lässt sich dies an einem Beispiel: An zahlreichen Orten stehen öffentliche WLAN-Spots zur Verfügung. Unvorsichtige Nutzer verbinden sich mit diesen oft, ohne zu prüfen, wer den Zugang zum Internet bereitstellt. Hacker nutzen diese Unachtsamkeit, um den eigenen Rechner als Hotspot auszugeben und sämtlichen Datenverkehr mitzuschneiden. Ruft einer der Nutzer die Website seiner Onlinebank über einen solchen Pseudo-Hotspot aus Bequemlichkeit unverschlüsselt auf, gibt dies dem Hacker die Möglichkeit, einen Redirect zu einer Phishing-Website einzuschleusen, bevor der Server der Onlinebank die Chance hat, die HTTP-Verbindung auf HTTPS umzuleiten. ### SSL-Stripping Eine Technik, mit der sich gewöhnliche HTTPS-Verbindungen aushebeln lassen, demonstrierte [Moxie Marlinspike](https://moxie.org/ "Offizielle Website von Moxie Marlinspike"), Cypherpunk und Gründer von Open Whisper Systems, mit dem selbstentwickelten [SSL-Stripping](https://www.heise.de/security/meldung/Black-Hat-Neue-Angriffsmethoden-auf-SSL-vorgestellt-198285.html "Mehr zum Angriffsmuster auf heise.de") bereits 2009 im Rahmen der Sicherheitskonferenz Black Hat. Um die Angreifbarkeit von HTTPS zu zeigen, entwickelte Marlinspike die Proxy-Software [SSLStrip](https://github.com/moxie0/sslstrip "Weitere Informationen zum Tool auf github.com"). Diese nutzt die Sicherheitslücke, die bei der Weiterleitung von HTTP- auf HTTPS-URLs entsteht, und wandelt alle HTTPS-Requests des Browsers in gleichlautende HTTP-Requests um. Während SSLStrip zum Browser des Nutzers eine unverschlüsselte HTTP-Verbindung aufbaut, kommuniziert das Programm mit dem Server auf HTTPS-Ebene. Dem Nutzer wird dabei durch ein Favicon in Form eines Schlosses vorgegaukelt, er hätte es mit einer sicheren Verbindung zu tun. Voraussetzung für einen solchen Angriff ist, dass der Hacker die Kommunikation zwischen Browser und Server mitlesen kann. Eine Lösung für das von Marlinspike dargelegte Sicherheitsproblem präsentierte die Internet Engineering Task Force (IETF) erst drei Jahre später: 2012 wurde in RFC 6797 die HTTPS-Erweiterung HTTP Strict Transport Security (HSTS) spezifiziert. ## Was ist HSTS? Bei HSTS (HTTP Strict Transport Security) handelt es sich um einen Sicherheitsmechanismus, der entwickelt wurde, um HTTPS-Verbindungen gegen **Man-in-the-Middle-Angriffe** und **Session-Hijacking** abzusichern. Mit der HTTPS-Erweiterung können Webseitenbetreiber Webbrowsern durch optionale Angaben im [HTTP-Header](https://www.ionos.at/digitalguide/hosting/hosting-technik/http-header/ "HTTP-Header") signalisieren, dass eine Website für einen definierten Zeitraum ausschließlich SSL/TLS-verschlüsselt abgerufen werden kann. Serverseitig wird dazu das Header-Feld *Strict-Transport-Security* verwendet. Dieses beinhaltet die obligatorische Direktive *max-age* und kann um die optionalen Direktiven *includeSubDomains* und *preload* erweitert werden: *Strict-Transport-Security: max-age=31536000* Die Direktive *max-age* gibt an, wie lange eine Website ausschließlich verschlüsselt zur Verfügung stehen soll. Der Zeitraum wird in **Sekunden** definiert. Ein *max-age* von 31.536.000 Sekunden entspricht einem Zeitraum von einem Jahr. Besucht ein Internetnutzer eine HSTS-gesicherte Website zum ersten Mal, erhält der Browser über das Header-Feld *Strict-Transport-Security* folgende Anweisungen: - Alle unverschlüsselten Links zur jeweiligen Website müssen in verschlüsselte Links umgeschrieben werden (*http://* wird zu *https://*). - Kann die Sicherheit der Verbindung (z. B. aufgrund eins ungültigen Zertifikats) nicht sichergestellt werden, muss diese abgebrochen werden. Der Nutzer bekommt eine Fehlermeldung angezeigt. Optional besteht die Möglichkeit, **HSTS-Angaben auf Subdomains auszuweiten**. In diesem Fall wird das Header-Feld *Strict-Transport-Security* um die Direktive *includeSubDomains* ergänzt. Diese signalisiert dem Browser, dass der HSTS-Header nicht nur für den aktuellen Host (z. B. *www.example.com*) gilt, sondern für alle Subdomains unter der jeweiligen Domain (z. B. auch für *blog.example.com* oder *adserver.example.com*). *Strict-Transport-Security: max-age=31536000; includeSubDomains* Die Direktive *preload* ermöglicht es, Webseiten für das sogenannte **Preloading** zu markieren, um das „First-Visit-Problem“ zu umgehen. *Strict-Transport-Security: max-age=31536000; includeSubDomains; preload* Ohne den preload-Parameter wirkt sich HSTS nur auf zukünftige Webseitenbesuche aus: Kennt ein Browser die Informationen im HSTS-Header einer Website, werden spätere Aufrufe entsprechend umgesetzt. Beim ersten Aufruf der Website greift dieser Sicherheitsmechanismus nicht. Browserhersteller wie Google und Mozilla bieten daher die Möglichkeit, Webseiten in sogenannte Preload-Listen einzutragen. Webseiten, die für ein Preloading registriert wurden, sind ausschließlich über HTTPS abrufbar. Preload-Listen werden von Browserbereitern zentral geführt und im Rahmen von Updates an die Browser der Nutzer übermittelt. ## Preload-Listen für HTTPS-Seiten Da HSTS nur funktioniert, wenn eine Website in der Vergangenheit mindestens einmal über eine nicht manipulierbare HTTPS-Verbindung aufgerufen wurde, ist jeder **Erstbesuch** prinzipiell anfällig für SSL-Stripping-Attacken. Um dies zu verhindern, greifen alle gängigen Browser heutzutage auf Listen zurück, die auf einem **HSTS-Preload-Service** \[HSTS-Preload-Service im Rahmen des Chromium-Projekts\] (https://hstspreload.appspot.com/) basieren, der von Google im Rahmen des Chromium-Projekts zur Verfügung gestellt wird. Prinzipiell steht es jedem Webseitenbetreiber frei, die eigene Domain in die HSTS-Preload-Liste einzutragen. Die Aufnahme einer Website ist jedoch an **Grundvoraussetzungen** gebunden, die die Qualität des Kontrollsystems sicherstellen sollen: - Alle Webseiten müssen ein gültiges SSL-Zertifikat ausliefern. - HTTP-URLs müssen auf HTTPS-URLs desselben Hosts weitergeleitet werden. - Alle Subdomains (inclusive der *www*-Subdomain) müssen über HTTPS abrufbar sein. - Der HSTS-Header muss über die Basis-Domain mit folgenden Parametern ausgeliefert werden: - Der Wert für *max-age* muss mindestens acht Wochen betragen (4.838.400 Sekunden) - Der HSTS-Header muss die Direktive *includeSubDomains* enthalten. - Der HSTS-Header muss die Direktive *preload* enthalten. - Alle zusätzlichen Redirects von der HTTPS-Website müssen den HSTS-Header beinhalten. Prominente Nutzer des HSTS-Preload-Features sind Google, Paypal, Twitter und LastPass. Die komplette Liste eingetragener Domains finden Nutzer auf der [Website des Chromium-Projekt](https://cs.chromium.org/chromium/src/net/http/transport_security_state_static.json "Zur HSTS-Preload-Liste auf Chromium.org"). ## HSTS einrichten: Kurzanleitung für Apache2, Lighttpd und NGINX Anbieter von Online-Inhalten, die ihr Projekt mittels HSTS gegen SSL-Stripping absichern möchten, müssen ihren Webserver entsprechend einrichten. Die folgende Kurzanleitung zeigt die HSTS-Konfiguration für **Apache**, **NGINX**, **Lighttpd** und **Microsoft IIS**. ### Apache HTTP Server Damit HSTS auf dem Apache HTTP Server zum Einsatz kommen kann, muss zunächst das **Apache-Header-Modul** (*mod\_headers*) aktiviert werden. Webseitenbetreiber schreiben dazu folgenden Befehl ins Terminal: ```none sudo a2enmod headers ``` Ist das Apache-Header-Modul aktiviert, sollte der **Webserver neu gestartet** werden: ```none sudo service apache restart ``` Der Apache HTTP Server bietet die Möglichkeit, verschiedene Domains auf ein und demselben Server zu betreiben. Jede dieser Domains wird in der Apache-Terminologie als **VirtualHost** (vhost) bezeichnet und unabhängig von anderen Domains auf dem Server konfiguriert. Da es sich bei HSTS um eine Erweiterung für HTTPS handelt, steht dieser Sicherheitsmechanismus lediglich für VirtualHosts mit der Portnummer 443 zur Verfügung – dem Standard-Port für HTTPS. Um die verschlüsselte Verbindung zu einer HTTPS-Website für künftige Besuche zu erzwingen, ergänzen Webseitenbetreiber den gewünschten VirtualHost in der **Apache-Konfigurationsdatei *https.conf*** um folgende Code-Zeile: ```none Header always set Strict-Transport-Security "max-age=4838400; includeSubdomains;" ``` Dazu wird das Header-Feld *Strict-Transport-Security* zusammen mit den anderen Direktiven in den VirtualHost-Container geschrieben: ```none ServerAdmin support@example.com ServerName www.example.com SSLEngine on SSLCertificateFile /path/to/www.example.com.cert SSLCertificateKeyFile /path/to/www.example.com.key […] Header always set Strict-Transport-Security "max-age=4838400; includeSubdomains;" DocumentRoot /var/www/ ``` Jedes Mal wenn ein Browser die so konfigurierte Website aufruft, gibt der Apache einen HSTS-Header mit den gewünschten Parametern aus. In diesem Beispiel wird der Browser angewiesen, Webseiten unter der Domain *example.com* inclusive Subdomains f**ür die nächsten acht Wochen ausschließlich SSL/TLS-verschlüsselt** abzurufen. Damit die Konfiguration übernommen wird, muss Apache neu gestartet werden. ### NGINX Auch unter NGINX lassen sich SSL/TLS-verschlüsselte Verbindungen durch eine simple Codezeile erzwingen: ```none add_header Strict-Transport-Security "max-age=4838400; includeSubDomains"; ``` Die Anpassung wird in der **Konfigurationsdatei */etc/nginx/nginx.conf*** vorgenommen. Statt VirtualHosts kommen bei NGINX sogenannte **Server-Blocks** zum Einsatz, um Direktiven zu definieren: ```none server { listen 443 ssl; server_name example.com; ssl_certificate www.example.com.crt; ssl_certificate_key www.example.com.key; […] add_header Strict-Transport-Security "max-age=4838400; includeSubDomains"; } ``` Auch NGINX muss nach der Konfiguration neu gestartet werden. ### Lighttpd Um HSTS für Lighttpd zu aktivieren, genügt eine Anpassung der **Konfigurationsdatei */etc/lighttpd/lighttpd.conf***: ```none server.modules += ( "mod_setenv" ) $HTTP["scheme"] == "https" { setenv.add-response-header = ( "Strict-Transport-Security" => "max-age=4838400; includeSubdomains; ") } ``` Die Einstellungen werden nach einem Neustart des Webservers übernommen. ### Microsoft IIS Anders als Apache, NGINX und Lighttpd wird Microsofts Webserver Internet Information Services (IIS) über eine **grafische Benutzeroberfläche** konfiguriert. Um HSTS zu aktivieren, gehen Webseitenbetreiber folgendermaßen vor: - IIS-Manager starten und erwünschte Website auswählen. - Menüpunkt „HTTP Response Header“ auswählen und auf „Add“ klicken. - Im Dialogfenster „Add Custom HTTP Response Header“ unter „Name“ *Strict-Transport-Security* eintragen und unter „Value“ die gewünschte Zeitspanne in Sekunden definieren. Im Anschluss muss IIS neu gestartet werden. This is a markdown version of: [https://www.ionos.at/digitalguide/websites/web-entwicklung/hsts-https-verbindungen-zuverlaessig-absichern/](https://www.ionos.at/digitalguide/websites/web-entwicklung/hsts-https-verbindungen-zuverlaessig-absichern/) for AI/LLM consumption.