HTTP Strict Transport Security

HTTP Strict Transport Security ( HSTS ) ist ein Sicherheitsmechanismus, der Websites vor Man-in-the-Middle-Angriffen wie Protokoll-Downgrade-Angriffen ^{[ 1 ]} und Cookie-Hijacking schützt . Er ermöglicht es Webservern, festzulegen, dass Webbrowser (oder andere kompatible Benutzeragenten ) automatisch ausschließlich über HTTPS -Verbindungen mit dem Server kommunizieren sollen. HTTPS bietet Transport Layer Security (TLS/SSL) anstelle des unsicheren HTTP allein. HSTS ist ein IETF- Standardprotokoll und in RFC  6797 spezifiziert .

Die HSTS-Richtlinie wird vom Server über ein HTTP- Antwortheaderfeld namens „HSTS-Richtlinie “ an den Benutzeragenten übermittelt Strict-Transport-Security. Die HSTS-Richtlinie legt einen Zeitraum fest, in dem der Benutzeragent ausschließlich sicher auf den Server zugreifen darf. ^{[ 2 ] : §5.2} Websites, die HSTS verwenden, akzeptieren häufig keine unverschlüsselten HTTP-Anfragen, indem sie entweder HTTP-Verbindungen ablehnen oder Benutzer systematisch auf HTTPS umleiten (obwohl dies in der Spezifikation nicht vorgeschrieben ist). Die Folge ist, dass ein Benutzeragent, der TLS nicht unterstützt, keine Verbindung zur Website herstellen kann.

Der Schutz greift normalerweise erst, nachdem ein Nutzer die Website mindestens einmal besucht hat, und basiert auf dem Prinzip „ Vertrauen beim ersten Besuch “. Dieser Schutz funktioniert folgendermaßen: Wenn ein Nutzer eine HTTP-URL (nicht HTTPS) für die Website eingibt oder auswählt, stellt der Client, beispielsweise ein Webbrowser, automatisch auf HTTPS um, ohne eine HTTP-Anfrage zu senden. Dadurch wird ein HTTP-Man-in-the-Middle-Angriff verhindert. Um diesem Problem entgegenzuwirken, wird eine HSTS-Preload-Liste von Google Chrome geführt , die auch von anderen gängigen Webbrowsern verwendet wird . Befindet sich eine Domain auf dieser Liste, überspringt der Browser die erste Anfrage und verschlüsselt die gesamte Kommunikation sofort. ^{[ 3 ]} Zusätzliche Domains können kostenlos registriert werden. ^{[ 4 ]}

Die HSTS-Spezifikation wurde am 19. November 2012 als RFC 6797 veröffentlicht, nachdem sie am 2. Oktober 2012 von der IESG als vorgeschlagener Standard (RFC) zur Veröffentlichung freigegeben worden war . ^{[ 5 ]} Die Autoren hatten sie ursprünglich am 17. Juni 2010 als Internet-Draft eingereicht . Mit der Umwandlung in einen Internet-Draft wurde der Name der Spezifikation von „Strict Transport Security“ (STS) in „HTTP Strict Transport Security“ geändert, da die Spezifikation nur für HTTP gilt . ^{[ 6 ]} Das in der HSTS-Spezifikation definierte HTTP-Antwortheader-Feld behält jedoch die Bezeichnung „Strict-Transport-Security“.

Die letzte sogenannte „Community-Version“ der damals noch so genannten „STS“-Spezifikation wurde am 18. Dezember 2009 veröffentlicht und enthielt Überarbeitungen, die auf dem Feedback der Community basierten. ^{[ 7 ]}

Der ursprüngliche Entwurf der Spezifikation von Jeff Hodges ( PayPal) , Collin Jackson und Adam Barth wurde am 18. September 2009 veröffentlicht. ^{[ 8 ]}

Die HSTS-Spezifikation basiert auf der Originalarbeit von Jackson und Barth, wie sie in ihrem Artikel „ForceHTTPS: Protecting High-Security Web Sites from Network Attacks“ beschrieben wird. ^{[ 9 ]}

Darüber hinaus ist HSTS die Verwirklichung eines Aspekts einer Gesamtvision zur Verbesserung der Websicherheit, die von Jeff Hodges und Andy Steingruebl in ihrem 2010 veröffentlichten Artikel „ The Need for Coherent Web Security Policy Framework(s)“ vorgestellt wurde . ^{[ 10 ]}

Ein Server implementiert eine HSTS-Richtlinie, indem er einen Header über eine HTTPS-Verbindung bereitstellt (HSTS-Header über HTTP werden ignoriert). ^{[ 1 ]} Beispielsweise könnte ein Server einen Header senden, sodass zukünftige Anfragen an die Domain im nächsten Jahr (max-age wird in Sekunden angegeben; 31.536.000 entspricht einem Nicht-Schaltjahr) ausschließlich über HTTPS erfolgen: Strict-Transport-Security: max-age=31536000.

Wenn eine Webanwendung eine HSTS-Richtlinie an Benutzeragenten ausgibt, verhalten sich konforme Benutzeragenten wie folgt: ^{[ 2 ] : §5}

1. Unsichere Links, die auf die Webanwendung verweisen, werden automatisch in sichere Links umgewandelt (z. B. http://example.com/some/page/wird der Link https://example.com/some/page/vor dem Zugriff auf den Server geändert).
2. Kann die Sicherheit der Verbindung nicht gewährleistet werden (z. B. weil das TLS- Zertifikat des Servers nicht vertrauenswürdig ist), muss der Benutzeragent die Verbindung beenden ^{[ 2 ] : §8.4} und darf dem Benutzer den Zugriff auf die Webanwendung nicht gestatten. ^{[ 2 ] : §12.1}

Dies trägt dazu bei, Benutzer von Webanwendungen vor passiven ( Abhören ) und aktiven Netzwerkangriffen zu schützen . ^{[ 2 ] : §2.4} Ein Man-in-the-Middle-Angreifer hat deutlich eingeschränkte Möglichkeiten, Anfragen und Antworten zwischen einem Benutzer und einem Webanwendungsserver abzufangen, solange im Browser des Benutzers die HSTS-Richtlinie für diese Webanwendung aktiv ist.

Die wichtigste Sicherheitslücke, die HSTS beheben kann, sind SSL-Stripping- Man-in-the-Middle-Angriffe . Diese wurden erstmals 2009 von Moxie Marlinspike in seinem Vortrag „New Tricks For Defeating SSL In Practice“ auf der Black Hat Federal öffentlich vorgestellt. ^{[ 11 ] [ 12 ]} Der SSL- (und TLS- )Stripping-Angriff funktioniert, indem eine sichere HTTPS -Verbindung transparent in eine unverschlüsselte HTTP-Verbindung umgewandelt wird. Der Benutzer erkennt zwar, dass die Verbindung unsicher ist, kann aber nicht feststellen, ob sie eigentlich sicher sein sollte . Zum Zeitpunkt von Marlinspikes Vortrag nutzten viele Websites kein TLS/SSL. Daher war es ohne Vorwissen unmöglich zu erkennen, ob die Verwendung von unverschlüsseltem HTTP auf einen Angriff zurückzuführen war oder einfach darauf, dass die Website kein TLS/SSL implementiert hatte. Zudem werden dem Benutzer während des Downgrade-Prozesses keine Warnungen angezeigt, wodurch der Angriff für die meisten außer den aufmerksamsten Nutzern schwer zu entdecken ist. Das auf der Black Hat DC 2009 vorgestellte Tool sslstrip von Marlinspike automatisiert den Angriff vollständig. ^{[ 13 ]}

HSTS behebt dieses Problem ^{[ 2 ] : §2.4} , indem es den Browser darüber informiert, dass Verbindungen zur Website stets über TLS/SSL erfolgen sollen. Der HSTS-Header kann von einem Angreifer entfernt werden, wenn es sich um den ersten Besuch des Nutzers handelt. Google Chrome , Mozilla Firefox , Internet Explorer und Microsoft Edge versuchen, dieses Problem durch die Bereitstellung einer vordefinierten Liste von HSTS-Websites einzuschränken. ^{[ 14 ] [ 15 ] [ 16 ]} Leider ist diese Lösung nicht für alle Websites im Internet geeignet. Siehe dazu die Einschränkungen weiter unten.

HSTS kann auch dazu beitragen, dass die auf Cookies basierenden Anmeldeinformationen für Websites nicht durch weit verbreitete Tools wie Firesheep gestohlen werden . ^{[ 17 ]}

Da HSTS zeitlich begrenzt ist, reagiert es empfindlich auf Angriffe, bei denen die Computerzeit des Opfers verändert wird, z. B. durch Verwendung gefälschter NTP- Pakete. ^{[ 18 ]}

Die ursprüngliche Anfrage bleibt ungeschützt vor aktiven Angriffen, wenn sie ein unsicheres Protokoll wie unverschlüsseltes HTTP verwendet oder wenn die URI für die ursprüngliche Anfrage über einen unsicheren Kanal abgerufen wurde . ^{[ 2 ] : §14.6} Dasselbe gilt für die erste Anfrage nach Ablauf des in der veröffentlichten HSTS-Richtlinie festgelegten Aktivitätszeitraums max-age(Websites 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 durch die Implementierung einer „HSTS-Vorabliste“, einer Liste bekannter Websites, die HSTS unterstützen. ^{[ 19 ] [ 14 ] [ 15 ] [ 16 ]} Diese Liste wird mit dem Browser ausgeliefert, sodass dieser auch für die erste Anfrage an die aufgeführten Websites HTTPS verwendet. Wie bereits erwähnt, können diese Vorablisten nicht das gesamte Web abdecken. Eine mögliche Lösung wäre die Verwendung von DNS- Einträgen zur Deklaration der HSTS-Richtlinie und der sichere Zugriff darauf über DNSSEC , optional mit Zertifikats-Fingerabdrücken zur Gewährleistung der Gültigkeit (was den Einsatz eines validierenden Resolvers erfordert, um Probleme auf der letzten Meile zu vermeiden ). ^{[ 20 ]}

Junade Ali hat festgestellt, dass HSTS gegen die Verwendung gefälschter Domains unwirksam ist; durch DNS-basierte Angriffe ist es einem Man-in-the-Middle-Angreifer möglich, Datenverkehr von einer künstlichen Domain abzufangen, die nicht auf der HSTS-Preload-Liste steht, ^{[ 21 ] dies kann durch DNS-Spoofing-Angriffe [ 22 ]} oder einfach durch einen Domainnamen ermöglicht werden , der dem echten Domainnamen täuschend ähnlich sieht, wie z. B. www.example.org statt www.example.com .

Selbst mit einer vorinstallierten HSTS-Liste kann HSTS fortgeschrittene Angriffe gegen TLS selbst, wie die von Juliano Rizzo und Thai Duong eingeführten BEAST- oder CRIME- Angriffe, nicht verhindern. Angriffe gegen TLS selbst sind unabhängig von der HSTS-Richtliniendurchsetzung. HSTS schützt auch nicht vor Angriffen auf den Server selbst – wenn dieser kompromittiert wird, liefert er ungehindert beliebige Inhalte über TLS aus.

HSTS ermöglicht es, Besucherbrowser nahezu dauerhaft mit wiederherstellbaren Identifikationsdaten ( Supercookies ) zu versehen, die auch im Inkognito -Modus des Browsers erhalten bleiben. Durch die Erstellung einer Webseite, die mehrere HTTP-Anfragen an ausgewählte Domains sendet – beispielsweise zwanzig Browseranfragen an zwanzig verschiedene Domains –, lassen sich theoretisch über eine Million Besucher unterscheiden (2^²⁰ ), da die resultierenden Anfragen über HTTP bzw. HTTPS eintreffen. Letzteres sind die zuvor über HSTS-Header festgelegten binären „Bits“. ^{[ 23 ]}

• Chromium und Google Chrome seit Version 4.0.211.0 ^{[ 24 ] [ 25 ]}
• Firefox seit Version 4; ^{[ 1 ]} ab Firefox 17 integriert Mozilla eine Liste von Websites, die HSTS unterstützen. ^{[ 15 ]}
• Opera seit Version 12 ^{[ 26 ]}
• Safari seit OS X Mavericks (Version 10.9, Ende 2013) ^{[ 27 ]}
• Internet Explorer 11 unter Windows 8.1 und Windows 7 mit installiertem KB3058515 (Veröffentlicht als Windows-Update im Juni 2015) ^{[ 28 ]}
• Microsoft Edge und Internet Explorer 11 unter Windows 10 ^{[ 29 ] [ 30 ]}
• BlackBerry 10 Browser und WebView seit BlackBerry OS 10.3.3.

Je nach konkreter Implementierung gibt es bestimmte Bedrohungen (z. B. Cookie-Injection-Angriffe), die durch die Einhaltung bewährter Verfahren vermieden werden können.

• HSTS-Hosts sollten ihre HSTS-Richtlinie in ihrer Top-Level-Domain deklarieren. Beispielsweise sollte ein HSTS-Host unter https://sub.example.com auch unter https://example.com mit dem entsprechenden HSTS-Header antworten. Dieser Header sollte die includeSubDomainsHSTS-Direktive spezifizieren. ^{[ 2 ] : §6.1.2}
• Zusätzlich zur HSTS-Implementierung sollte ein Host für https://www.example.com eine Anfrage an eine Ressource von https://example.com senden, um sicherzustellen, dass HSTS für die übergeordnete Domain aktiviert ist und den Benutzer vor potenziellen Cookie-Injection-Angriffen durch einen Man-in-the-Middle-Angreifer schützt. Dieser würde einen Verweis auf die übergeordnete Domain (oder sogar http://nonexistentpeer.example.com) einschleusen, den der Angreifer dann beantworten würde. ^{[ 2 ] : §11.4}

• RFC  6797 – eine Diskussion über allgemeine Sicherheitsaspekte von HSTS
• Inhaltssicherheitsrichtlinie
• .app TLD – eine von Google betriebene Top-Level-Domain, die standardmäßig in der HSTS-Preload-Liste enthalten ist.
• .dev TLD – eine von Google betriebene Top-Level-Domain, die standardmäßig in der HSTS-Preload-Liste enthalten ist.
• HTTP Public Key Pinning

• IETF WebSec Arbeitsgruppe
• Security Now 262: Strenge Transportsicherheit
• Open Web Application Security Project (OWASP): HSTS-Beschreibung
• HSTS- und Public-Key-Pinning-Test im Online-Browser
• HSTS-Vorab-Übermittlung für Google Chrome, Mozilla Firefox, Safari, IE 11 und Edge
• Chromium HSTS-Vorladeliste
• Strenge Transportsicherheit auf MDN Web Docs