Donnerstag, 28 Dezember 2017 16:26

HSTS & HPKP Header, IIS, Apache und Cloudflare

geschrieben von
HSTS-Header HSTS-Header iotex

Mit HSTS haste hastig Stress

HTTP Strict Transport Security (HSTS) stellt mittlerweile eine wichtige Methode zur Sicherung der Übertragung von Daten zwischen Client und Server dar. Bei der Einrichtung ist es jedoch wichtig, sich im Klaren darüber zu sein, was man tut. Sonst kann die Seite schnell nicht mehr erreichbar sein oder durch unbedachte Nutzung von HPKP unbrauchbar sein. Es gilt also: keine Hastig, sondern Ruhe bei der Einrichtung.


 

I. Theoretischer Teil

Wer nur wissen will, wie man HSTS einrichtet, der kann nach unten zum praktischen Teil springen.

Was ist HSTS?

HSTS soll die Datenübertragung vor sogenannten Downgrade-Attacken beschützen. Dabei handelt es sich um eine besondere Art der Man-In-The-Middle-Attack, bei der der Angreifer die Verbindung zwischen Client und Server auf einen schwächeren Standard herunterhandelt, um so Schwachstellen nutzen zu können.

Beispielszenario für Downgrade-Angriff

Sie betreiben einen Webshop, der sowohl über https://ihr.shop erreichbar ist, als auch über ihr.shop. Ihr Server leitet HTTP-Requests auf ihr.shop auf https://ihr.shop um. Genau an dieser Stelle kann der Angreifer, z.B. ein "WLAN Hotspot" der eigentlich einem Hacker gehört, den Besucher umlenken und zwar auf eine geklonte Seite oder ähnliches. Hierbei könnte er rein theoretisch sogar ein Zertifikat verwenden (hiergegen HPKP). Nun greift der Hacker alle Daten ab.

Wie funktioniert HSTS?

Grundprinzip

An dieser Stelle kommt HSTS ins Spiel. Der Server teilt dem Client-Browser beim ersten Kontakt mit, dass eine Verbindung zu diesem Server lediglich über SSL hergestellt werden können soll. Versucht nun ein Angreifer einen Downgrade-Angriff, lässt sich der Browser hierauf bereits nicht mehr ein. Die Daten werden verschlüsselt oder gar nicht übertragen.

Was ist HSTS Preloading?

Soweit so gut!  Wenn ich also meine Bank bereits besucht habe, und dann von einem WLAN-Hotspot eine gekaperte Verbindung zum Bankserver aufbauen will, schützt mich mein Browser durch einen Block, für den ich keine Ausnahme hinzufügen kann. Die Schwachstelle ist aber das das "trust on first use" Prinzip. Wenn ich ohne vorige Verbindung "in die Falle tappe", also der HSTS-Header in meinem Browser noch nicht gesetzt wurde, dann bestehen nach wie vor erhebliche Risiken. Daher gibt es eine sogenannte Preloadliste, die von Googles Chrome ins Leben gerufen wird. Hierbei registriert sich der Server mit seinem Header in der Liste, die automatisch auf die Browser per Update verteilt wird. Entsprechend funktioniert der Schutz auch ohne vorigen Kontakt, wenn der Header für den Server bereits in der Liste geführt wird.

Achtung bei der Verwendung von HSTS Preloading

Wieso ist Vorsicht geboten?

Wer seine Seite unter https://hstspreload.org/ registriert hat, kommt aus der Nummer auch nicht mehr so schnell heraus, wie er hereingekommen ist. Es ist also dringend erforderlich einige Gedanken zu investieren, ob die Verbindung dauerhaft nur über HTTPS Requests (SSL) erreichbar sein soll. Ein späteres Downgrade ist serverseitig zwar möglich, jedoch werden Browser durch die Preloadliste dennoch angewiesen nur eine Verbindung per SSL herzustellen und alles andere abzulehnen. Außerdem sollten Sie darauf achten, dass Sie die Direktive "include Subdomains" nicht unbedacht setzen. Sonst wird auch der Zugang zur Entwicklungsseite (z.B. dev.ihr.shop) nur noch über SSL möglich sein!

HSTS Preloading beenden / austragen

Über diesen Link https://hstspreload.org/removal/ kann der Server wieder ausgetragen werden. Hierzu muss natürlich die Preload Direktive aus dem Header entfernt werden. Bis dies Effekt zeigt, können jedoch Wochen vergehen. Wer schon auf der Seite gesurft hat, hat den Header im Cache, der über Max-Age eine extrem lange Gültigkeit zugewiesen bekommt. HSTS sollte also nur angewendet werden, wenn SSL wirklich "für immer" eingesetzt werden soll.

HSTS mit HPKP nutzen?

HTTP Public Key Pinning (HPKP) soll zusätzlich davor schützen, dass der Angreifer seine gekaperte Verbindung durch ein gefälschtes aber durch eine ordentliche CA signiertes Zertifikat "schützt" bzw. treffender einen solchen Schutz vorgibt. Somit würde beim Browser selbst in der gekaperten Verbindung das grüne Schloss erscheinen, HSTS ggf. leerlaufen, da die Verbindung zu "einem" Server ja "geschützt" ist. Hiergegen hilft die öffentliche Kundmachung des öffentlichen Schlüssels der für die Domain zugelassenen SSL-Zertifikate. Diese Technik bringt ein erhebliches "Mehr" an Sicherheit, ist jedoch Komplex und mir ganz erheblichen Risiken verbunden. So kann bei Verlust des Schlüssels, Hardwaredefekten etc. schnell die ganze Seite unbrauchbar gemacht werden. Auch Zertifikatswechsel sind sehr komplex und schwierig. Nutzern von Cloudflare rate ich erst Recht, die Finger von HPKP zu lassen, da durch die vorgeschalteten SSL Zertifikate von Cloudflare eine schier unüberschaubare Komplexität zu entstehen droht, die kaum noch kontrollierbar ist.

II. Praktischer Teil

Wer nun weiß, was er tun will, der kann wie folgend HSTS aktivieren. Bitte überprüft vor dem Ausführen jeden Schritt auf Aktualität und Richtigkeit. Ihr arbeitet auf eigene Gefahr, keine Haftung oder Gewähr für Richtigkeit oder Vollständigkeit.

Werbung unterstüzt den Erhalt dieser Seite

HSTS Header unter Apache2 einrichten

Nutzungsbedingungen

Sie können diesen Code entsprechend unserer Nutzungsbedingungen nutzen. Wir untersagen ausdrücklich die direkte Nutzung in Produktivumgebungen. Wir übernehmen keine Haftung für Schäden, die Sie durch Nutzung unseres Codes verursachen, noch Gewähr auf Vollständigkeit oder Richtigkeit oder Markttauglichkeit der dargestellten Elemente. Sie nutzen diese Elemente gänzlich auf eigene Gefahr!

Zunächst sollte klar sein, dass die HSTS Einstellung denklogisch in die .conf Datei für den HTTPS-Host gehört. In die .conf Datei des HTTP-Hosts wird lediglich der Redirect geschrieben.
# Optional den Headers Mod laden
LoadModule headers_module modules/mod_headers.so
<VirtualHost 12.34.567.89:443>
    Header always set Strict-Transport-Security "max-age=63072000;"
    ...hier kommt der Rest der Config, wie bekannt.
</VirtualHost>

 

Das Einfügen des hervorgehobenen Teils führt dazu, dass der Server bei jeder Verbindung erneut die Anforderung an den Client mitsendet, dass für die nächsten 2 Jahre (in Sekunden) HSTS gelten soll. Nach dem Semikolon können noch folgende Direktiven eingefügt werden, wobei äußerste Vorsicht geboten ist:

  1. includeSubdomains;
  2. preload;

Die 1. Direktive führt dazu, dass der HSTS-Header auch für alle Subdomains gilt, und zwar auch dann, wenn der Server / VHost der Subdomain selbst keinen HSTS-Header sendet! Wer sich also nicht sicher ist, ob jemals eine Subdomain ohne SSL ansteuern will, sollte hiervon absehen. Das gilt insbesondere für Entwicklungsseiten wie dev.ihr.shop.

Noch heikler ist die preload; Direktive, die dazu führt, dass der HSTS-Header bereits vor dem ersten Kontakt mit dem Client eventuell über den Browser vorgeladen wird. Wird diese direktive gesetzt, reicht ein Entfernen des Headers nicht mehr aus, um zumindest neuen Clients den Zugriff auf die Seite zu ermöglichen. Wer IncludeSubdomains und preload aktiviert hat, macht seine Domain unbrauchbar für HTTP-Requests, solange der HSTS-Eintrag nicht vollständig zurückgerollt wurde (s.o). Das kann bestensfalls Wochen dauern.

IIS HSTS Header einrichten

Unter IIS gehen Sie wie folgend vor:

  1. Öffnen Sie IIS
  2. Öffnen Sie die Site, der Sie HSTS-Header zuordnen möchten
  3. Klicken Sie auf "HTTP-Antwort-Header"
  4. Klicken Sie auf "Hinzufügen"
  5. Unter Name geben Sie "Strict-Transport-Security" ein
  6. Unter Wert geben Sie wie oben bspw. max-age=63072000;  ein und ergänzen es ggf. durch preload; und / oder IncludeSubdomains nach dem Semikolon.

HSTS Header IIS Einstellung

Nach der Einrichtung kann der Erfolg hier geprüft werden: https://hstspreload.org/


 

 
Letzte Änderung am Dienstag, 16 Januar 2018 09:22
iotex

THE DIGITAL TECHNOLOGY EXPERTS

iotex.co
Cookies erleichtern die Bereitstellung unserer Dienste. Mit der Nutzung unserer Dienste erklären Sie sich damit einverstanden, dass wir Cookies verwenden.
Weitere Informationen