HTTP Strenge Transportsicherheit - HTTP Strict Transport Security

HTTP Strict Transport Security ( HSTS ) ist ein Richtlinienmechanismus, der Websites vor Man-in-the-Middle-Angriffen wie Protokoll-Downgrade-Angriffen und Cookie-Hijacking schützt . Es ermöglicht Webservern zu erklären, dass Webbrowser (oder andere entsprechende Benutzeragenten ) automatisch nur über HTTPS- Verbindungen mit ihm interagieren sollen , die Transport Layer Security (TLS/SSL) bieten , im Gegensatz zu dem unsicheren HTTP, das allein verwendet wird. HSTS ist ein IETF- Standard-Track-Protokoll und ist in RFC 6797 spezifiziert.

Die HSTS-Richtlinie wird vom Server über ein HTTP-Response- Header- Feld namens „ Strict-Transport-Security “ an den User-Agent übermittelt . Die HSTS-Richtlinie gibt einen Zeitraum an, in dem der Benutzeragent nur auf sichere Weise auf den Server zugreifen soll. Websites, die HSTS verwenden, akzeptieren häufig kein Klartext-HTTP, indem sie entweder Verbindungen über HTTP ablehnen oder Benutzer systematisch auf HTTPS umleiten (obwohl dies in der Spezifikation nicht erforderlich ist). Dies hat zur Folge, dass ein User-Agent, der nicht TLS-fähig ist, sich nicht mit der Site verbinden kann.

Der Schutz gilt erst, nachdem ein Benutzer die Website mindestens einmal besucht hat und sich dabei auf das Vertrauensprinzip bei der ersten Nutzung stützt. Dieser Schutz funktioniert so, dass ein Benutzer, der eine URL für die Site eingibt oder auswählt, die HTTP angibt, automatisch auf HTTPS aktualisiert, ohne eine HTTP-Anfrage zu stellen, wodurch der HTTP-Man-in-the-Middle-Angriff verhindert wird.

Spezifikationshistorie

Die HSTS-Spezifikation wurde am 19. November 2012 als RFC 6797 veröffentlicht, nachdem sie am 2. Oktober 2012 von der IESG zur Veröffentlichung als vorgeschlagener Standard RFC genehmigt wurde . Die Autoren haben ihn ursprünglich als Internet Draft am 17. Juni 2010 eingereicht . Mit der Umstellung auf einen Internet Draft wurde der Spezifikationsname von „Strict Transport Security“ (STS) in „HTTP Strict Transport Security“ geändert, da die Spezifikation nur für HTTP- . Das in der HSTS-Spezifikation definierte HTTP-Response-Header-Feld bleibt jedoch "Strict-Transport-Security" genannt.

Die letzte sogenannte „Community-Version“ der damaligen „STS“-Spezifikation wurde am 18. Dezember 2009 veröffentlicht, mit Überarbeitungen basierend auf Community-Feedback.

Der ursprüngliche Spezifikationsentwurf von Jeff Hodges von PayPal , Collin Jackson und Adam Barth wurde am 18. September 2009 veröffentlicht.

Die HSTS-Spezifikation basiert auf Originalarbeiten von Jackson und Barth, wie sie in ihrem Papier "ForceHTTPS: Protecting High-Security Web Sites from Network Attacks" beschrieben sind.

Darüber hinaus ist HSTS die Umsetzung einer Facette einer Gesamtvision zur Verbesserung der Websicherheit, die von Jeff Hodges und Andy Steingruebl in ihrem 2010 erschienenen Papier The Need for Coherent Web Security Policy Framework(s) vorgestellt wurde .

Übersicht über den HSTS-Mechanismus

Ein Server implementiert eine HSTS-Richtlinie, indem er einen Header über eine HTTPS-Verbindung bereitstellt (HSTS-Header über HTTP werden ignoriert). Ein Server könnte beispielsweise einen Header senden, sodass zukünftige Anfragen an die Domäne für das nächste Jahr (max-age wird in Sekunden angegeben; 31.536.000 entspricht einem Nicht-Schaltjahr) nur HTTPS verwenden: Strict-Transport-Security: max-age=31536000.

Wenn eine Webanwendung eine HSTS-Richtlinie an Benutzeragenten ausgibt, verhalten sich konforme Benutzeragenten wie folgt (RFC 6797):

  1. Wandeln Sie alle unsicheren Links, die auf die Webanwendung verweisen, automatisch in sichere Links um (zB http://example.com/some/page/werden sie https://example.com/some/page/ vor dem Zugriff auf den Server geändert ).
  2. Kann die Sicherheit der Verbindung nicht gewährleistet werden (zB das TLS- Zertifikat des Servers ist nicht vertrauenswürdig), muss der User Agent die Verbindung beenden (RFC 6797 Abschnitt 8.4, Fehler beim sicheren Transportaufbau) und sollte dem Benutzer keinen Zugriff auf die Webanwendung erlauben (Abschnitt 12.1, Kein Nutzerregress).

Die HSTS-Richtlinie trägt dazu bei, die Benutzer von Webanwendungen vor einigen passiven ( Lauschangriffen ) und aktiven Netzwerkangriffen zu schützen . Ein Man-in-the-Middle-Angreifer hat eine stark eingeschränkte Fähigkeit, Anfragen und Antworten zwischen einem Benutzer und einem Webanwendungsserver abzufangen, während im Browser des Benutzers die HSTS-Richtlinie für diese Webanwendung gilt.

Anwendbarkeit

Die wichtigste Sicherheitslücke, die HSTS beheben kann, sind SSL-stripping Man-in-the-Middle-Angriffe , die erstmals von Moxie Marlinspike in seinem BlackHat Federal Talk 2009 "New Tricks For Defeating SSL In Practice" vorgestellt wurden. Der SSL- (und TLS- ) Stripping-Angriff funktioniert durch die transparente Umwandlung einer sicheren HTTPS- Verbindung in eine einfache HTTP-Verbindung. Der Benutzer kann sehen, dass die Verbindung unsicher ist, aber vor allem gibt es keine Möglichkeit zu wissen, ob die Verbindung sicher sein soll. Zum Zeitpunkt des Vortrags von Marlinspike verwendeten viele Websites kein TLS/SSL, daher gab es keine Möglichkeit (ohne Vorkenntnisse) zu wissen, ob die Verwendung von reinem HTTP auf einen Angriff zurückzuführen war oder einfach darauf, dass die Website TLS nicht implementiert hatte /SSL. Darüber hinaus werden dem Benutzer während des Downgrade-Prozesses keine Warnungen angezeigt, was den Angriff für alle, außer für die wachsamsten, ziemlich subtil macht. Das sslstrip-Tool von Marlinspike automatisiert den Angriff vollständig.

HSTS behebt dieses Problem, indem es den Browser informiert, dass Verbindungen zur Site immer TLS/SSL verwenden sollten. Der HSTS-Header kann vom Angreifer entfernt werden, wenn dies der erste Besuch des Benutzers ist. Google Chrome , Mozilla Firefox , Internet Explorer und Microsoft Edge versuchen, dieses Problem zu begrenzen, indem sie eine "vorinstallierte" Liste von HSTS-Sites hinzufügen. Leider kann diese Lösung nicht auf alle Websites im Internet skaliert werden. Siehe Einschränkungen unten.

HSTS kann auch dazu beitragen, den Diebstahl der Cookie-basierten Website-Anmeldedaten durch weit verbreitete Tools wie Firesheep zu verhindern .

Da HSTS zeitbegrenzt ist, reagiert es empfindlich auf Angriffe, bei denen die Computerzeit des Opfers verschoben wird, z. B. unter Verwendung falscher NTP- Pakete.

Einschränkungen

Die Erstanfrage bleibt vor aktiven Angriffen ungeschützt, wenn sie ein unsicheres Protokoll wie reines HTTP verwendet oder wenn der URI für die Erstanfrage über einen unsicheren Kanal abgerufen wurde . Gleiches gilt für die erste Anfrage nach dem in der beworbenen HSTS-Richtlinie max-age angegebenen Aktivitätszeitraum (Sites sollten je nach Benutzeraktivität und -verhalten einen Zeitraum von mehreren Tagen oder Monaten festlegen). Google Chrome , Mozilla Firefox und Internet Explorer / Microsoft Edge beheben diese Einschränkung, indem sie eine "HSTS Preloaded List" implementieren, eine Liste, die bekannte Websites enthält, die HSTS unterstützen. Diese Liste wird mit dem Browser verteilt, sodass dieser HTTPS auch für die anfängliche Anfrage an die aufgelisteten Sites verwendet. Wie bereits erwähnt, können diese vorinstallierten Listen nicht das gesamte Web abdecken. Eine mögliche Lösung könnte erreicht werden, indem DNS- Einträge verwendet werden, um die HSTS-Richtlinie zu deklarieren, und sicher über DNSSEC darauf zugreifen , optional mit Zertifikatsfingerabdrücken, um die Gültigkeit sicherzustellen (was den Betrieb eines validierenden Resolvers erfordert, um Probleme auf der letzten Meile zu vermeiden ).

Junade Ali hat festgestellt, dass HSTS gegen die Verwendung von gefälschten Domänen unwirksam ist; Durch die Verwendung von DNS-basierten Angriffen ist es einem Man-in-the-Middle-Abfangjäger möglich, Verkehr von einer künstlichen Domäne zu bedienen, die nicht auf der HSTS-Preload-Liste steht, dies kann durch DNS-Spoofing-Angriffe oder einfach eine Domäne ermöglicht werden Name, der fälschlicherweise dem echten Domainnamen ähnelt, z. B. www.example.org anstelle von www.example.com .

Selbst mit einer "HSTS vorinstallierten Liste" kann HSTS fortgeschrittene Angriffe gegen TLS selbst nicht verhindern, wie die von Juliano Rizzo und Thai Duong eingeführten BEAST- oder CRIME- Angriffe. Angriffe gegen TLS selbst sind orthogonal zur Durchsetzung von HSTS-Richtlinien. Es kann auch nicht vor Angriffen auf den Server schützen - wenn jemand es kompromittiert, stellt es gerne alle Inhalte über TLS bereit.

Siehe RFC  6797 für eine Erörterung der allgemeinen HSTS-Sicherheitsüberlegungen.

Datenschutzprobleme

HSTS kann verwendet werden, um besuchende Browser nahezu unauslöschlich mit wiederherstellbaren Identifizierungsdaten ( Supercookies ) zu versehen, die in und außerhalb der Browser- Inkognito- Datenschutzmodi bestehen bleiben können. Durch Erstellen einer Web - Seite , die mehr HTTP - Anforderungen an ausgewählten Domänen, zum Beispiel, wenn zwanzig Browser - Anfragen zu zwanzig verschiedenen Domänen verwendet werden, theoretisch über eine Million Besucher kann unterschieden werden (2 macht 20 ) aufgrund der resultierenden Anfragen ankommen via HTTP vs. HTTPS; wobei letztere die zuvor aufgezeichneten binären "Bits" sind, die zuvor über HSTS-Header eingerichtet wurden.

Browser-Unterstützung

Einstellungsseite für HTTPS Strict Transport Security in Chromium 45, die den Status der Sicherheitsrichtlinie für die Domain "en.wikipedia.org" anzeigt.

Best Practices für die Bereitstellung

Abhängig von der tatsächlichen Bereitstellung gibt es bestimmte Bedrohungen (z. B. Cookie-Injection-Angriffe), die durch Befolgen von Best Practices vermieden werden können.

  • HSTS-Hosts sollten die HSTS-Richtlinie in ihrem Domänennamen der obersten Ebene deklarieren. Beispielsweise sollte ein HSTS-Host unter https://sub.example.com auch mit dem HSTS-Header unter https://example.com antworten. Der Header sollte die includeSubDomainsDirektive angeben .
  • Zusätzlich zur HSTS-Bereitstellung sollte ein Host für https://www.example.com eine Anfrage an eine Ressource von https://example.com einschließen, um sicherzustellen, dass HSTS für die übergeordnete Domäne festgelegt ist und den Benutzer vor möglichen schützt Cookie-Injection-Angriffe, die von einem MITM durchgeführt werden und einen Verweis auf die übergeordnete Domäne (oder sogar http://nonexistentpeer.example.com) injizieren, auf die der Angreifer dann antworten würde.

Siehe auch

Verweise

Externe Links