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) unverschlüsselt erfolgen, bietet das Netzwerkprotokoll HTTPS („Hypertext Transfer Protocol Secure“ 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 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, 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 und ein zuverlässiges SSL/TLS-Zertifikat 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.

Sichern Sie sich Ihr SSL-Zertifikat
  • Verschlüsselt Webseiten-Kommunikation
  • Verhindert Sicherheits-Warnungen
  • Verbessert Google-Platzierung

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, Cypherpunk und Gründer von Open Whisper Systems, mit dem selbstentwickelten SSL-Stripping bereits 2009 im Rahmen der Sicherheitskonferenz Black Hat. Um die Angreifbarkeit von HTTPS zu zeigen, entwickelte Marlinspike die Proxy-Software SSLStrip. 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 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.

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: 

sudo a2enmod headers

Ist das Apache-Header-Modul aktiviert, sollte der Webserver neu gestartet werden:

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: 

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: 

<VirtualHost *:443>
    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/
</VirtualHost>

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: 

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:

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: 

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.

War dieser Artikel hilfreich?
Zum Hauptmenü