Diese Seite wurde von der Cloud Translation API übersetzt.

Böswillige Zwischenhändler mit HTTPS- und HTTP Strict-Transport-Sicherheit verwirren

Mike West

Angesichts der Menge personenbezogener Daten, die durch die große Reihe von Röhren im Internet fließt, ist Verschlüsselung nichts, was wir leicht ignorieren können oder sollten. Moderne Browser bieten mehrere Mechanismen, mit denen Sie dafür sorgen können, dass die Daten Ihrer Nutzer während der Übertragung sicher sind: sichere Cookies und Strict Transport Security sind zwei der wichtigsten. Sie ermöglichen einen nahtlosen Schutz Ihrer Nutzer, ein Upgrade ihrer Verbindungen auf HTTPS und die Garantie, dass Nutzerdaten nie unverschlüsselt gesendet werden.

Warum ist das wichtig? Bedenken Sie Folgendes:

Wenn Sie eine Webseite über eine unverschlüsselte HTTP-Verbindung bereitstellen, ist mehr oder weniger dasselbe wie das Übergeben eines unversiegelten Briefumschlags an die erste Person auf der Straße, die aussieht, als würde sie in Richtung der Post gehen. Wenn Sie Glück haben, kann sie es bis hierher nehmen oder der nächsten Person geben, die sieht, wer auf dem richtigen Weg ist. Diese Person könnte dasselbe machen und so weiter.

Die meisten Fremden in dieser spontanen Kette sind vertrauenswürdig und würden niemals auf Ihren offenen Brief spähen oder ihn verändern. Je häufiger der Brief jedoch den Besitzer wechselt, desto mehr Personen haben uneingeschränkten Zugriff auf den von Ihnen gesendeten Brief. Am Ende erhält der beabsichtigte Empfänger Ihres Briefs etwas per Post. Ob es sich dabei um dasselbe handelt, das Sie ursprünglich übermittelt haben, ist eine offene Frage. Vielleicht hätten Sie den Umschlag versiegeln sollen...

Zwischenhändler

Im Schlechten oder Schlechten: Unmengen des Internets stützen sich auf die Vertrauenswürdigkeit von Fremden. Server sind nicht direkt miteinander verbunden, sondern leiten Anfragen und Antworten in einem gigantischen Telefonspiel von Router zu Router weiter.

Mit Traceroute können Sie diese Hops in Aktion sehen. Der Weg von meinem Computer zu HTML5Rocks sieht in etwa so aus:

$ traceroute html5rocks.com
traceroute to html5rocks.com (173.194.71.102), 30 hops max, 60 byte packets
 1  router1-lon.linode.com (212.111.33.229)  0.453 ms
 2  212.111.33.233 (212.111.33.233)  1.067 ms
 3  217.20.44.194 (217.20.44.194)  0.704 ms
 4  google1.lonap.net (193.203.5.136)  0.804 ms
 5  209.85.255.76 (209.85.255.76)  0.925 ms
 6  209.85.253.94 (209.85.253.94)  1.226 ms
 7  209.85.240.28 (209.85.240.28)  48.714 ms
 8  216.239.47.12 (216.239.47.12)  22.575 ms
 9  209.85.241.193 (209.85.241.193)  36.033 ms
10  72.14.233.180 (72.14.233.180)  43.222 ms
11  72.14.233.170 (72.14.233.170)  43.242 ms
12  *
13  lb-in-f102.1e100.net (173.194.71.102)  44.523 ms

13 Sprünge sind gar nicht schlecht. Wenn ich jedoch Anfragen über HTTP sende, hat jeder dieser zwischengeschalteten Router vollständigen Zugriff auf meine Anfragen und die Antworten der Server. Alle Daten werden als unverschlüsselter Klartext übertragen und jeder dieser Vermittler könnte als Man in the Middle agieren, meine Daten lesen oder sogar während der Übertragung manipulieren.

Schlimmer noch: Diese Art des Abfangens ist praktisch nicht erkennbar. Eine böswillig geänderte HTTP-Antwort sieht genauso aus wie eine gültige Antwort, da es keinen Mechanismus gibt, mit dem Sie sicherstellen können, dass die empfangenen Daten _exakt mit den gesendeten Daten übereinstimmen. Wenn jemand mein Internet wegen Lachens auf den Kopf gestellt hat, dann habe ich mehr oder weniger Glück.

Ist das eine sichere Linie?

Der Wechsel von Klartext-HTTP zu einer sicheren HTTPS-Verbindung bietet den besten Schutz gegen Zwischenhändler. HTTPS-Verbindungen verschlüsseln den gesamten Kanal Ende-zu-Ende, bevor Daten gesendet werden. Dadurch ist es für Maschinen zwischen Ihnen und Ihrem Ziel unmöglich, Daten während der Übertragung zu lesen oder zu ändern.

Die Omnibox von Chrome bietet viele Details zum Verbindungsstatus. — Die Omnibox von Chrome gibt viele Details zum Verbindungsstatus aus.

Die Sicherheit, die HTTPS bietet, basiert auf dem Konzept von öffentlichen und privaten kryptografischen Schlüsseln. Eine ausführliche Erläuterung der Details kann den Rahmen dieses Artikels (glücklicherweise) weit sprengen, aber das Kernstück ist ziemlich einfach: Daten, die mit einem bestimmten öffentlichen Schlüssel verschlüsselt sind, können nur mit dem entsprechenden privaten Schlüssel entschlüsselt werden. Wenn ein Browser einen HTTPS-Handshake startet, um einen sicheren Kanal zu erstellen, stellt der Server ein Zertifikat bereit, das dem Browser alle Informationen zur Überprüfung seiner Identität liefert. Dazu wird geprüft, ob der Server im Besitz des richtigen privaten Schlüssels ist. Die gesamte Kommunikation ab diesem Punkt wird so verschlüsselt, dass Anfragen an den authentifizierten Server zugestellt und Antworten vom authentifizierten Server empfangen werden.

HTTPS gibt Ihnen daher die Gewissheit, dass Sie mit dem Server kommunizieren, mit dem Sie sprechen, und dass niemand zuhört oder sich die Bits irrt. Diese Art der Verschlüsselung ist eine absolute Voraussetzung für die Sicherheit im Web. Wenn Ihre Anwendung derzeit nicht über HTTPS bereitgestellt wird, ist sie anfällig für Angriffe. Problem beheben. Ars Technica bietet einen hervorragenden Leitfaden zum Erhalt und zur Installation eines kostenlosen Zertifikats, den Sie sich im Hinblick auf die technischen Details durchlesen sollten. Die Konfiguration unterscheidet sich von Anbieter zu Anbieter und von Server zu Server, die Zertifikatsanforderung ist jedoch überall gleich.

Standardmäßig sicher

Stellen Sie nach dem Anfordern und Installieren eines Zertifikats sicher, dass Ihre Nutzer von Ihrer harten Arbeit profitieren: Migrieren Sie Ihre vorhandenen Nutzer mithilfe von HTTP-Weiterleitungen transparent zu HTTPS-Verbindungen und stellen Sie sicher, dass Cookies nur über sichere Verbindungen gesendet werden.

Bitte beachten Sie Folgendes:

Wenn ein Nutzer http://example.com/ aufruft, kannst du ihn zu https://example.com/ weiterleiten, indem er eine 301 Moved Permanently-Antwort mit einem entsprechenden Location-Header sendet:

$ curl -I http://mkw.st/
HTTP/1.1 301 Moved Permanently
Server: nginx/1.3.7
...
Keep-Alive: timeout=20
Location: https://mkw.st/

Diese Weiterleitung lässt sich in Servern wie Apache oder Nginx ganz einfach einrichten. Eine Nginx-Konfiguration mit einer Weiterleitung von http://example.com/ zu https://example.com/ sieht beispielsweise so aus:

server {
    listen [YOUR IP ADDRESS HERE]:80;
    server_name example.com www.example.com;
    location "/" {
        rewrite ^(.*) https://www.example.com$1 permanent;
    }
}

Cookie-Speicher verriegeln

Mithilfe von Cookies können wir Nutzern über das zustandslose HTTP-Protokoll eine nahtlose Anmeldung ermöglichen. In Cookies gespeicherte Daten, einschließlich vertraulicher Informationen wie Sitzungs-IDs, werden mit jeder Anfrage gesendet. So kann der Server nachvollziehen, auf welchen Nutzer er gerade reagiert. Sobald wir sichergestellt haben, dass Nutzer unsere Website über HTTPS aufrufen, sollten wir auch dafür sorgen, dass die in Cookies gespeicherten sensiblen Daten nur über eine sichere Verbindung übertragen und nicht unverschlüsselt übertragen werden.

Das Setzen eines Cookies erfordert im Allgemeinen einen HTTP-Header, der in etwa so aussieht:

set-Cookie: KEY=VALUE; path=/; expires=Sat, 01-Jan-2022 00:00:00 GMT

Sie können den Browser anweisen, die Verwendung des Cookies auf sichere Sitzungen zu beschränken, indem Sie ein einzelnes Keyword verwenden:

Set-Cookie: KEY=VALUE; path=/; expires=Sat, 01-Jan-2022 00:00:00 GMT; secure

Cookies, die mit dem Keyword sicher gesetzt werden, werden niemals über HTTP gesendet.

Geöffnetes Fenster schließen

Eine transparente Weiterleitung zu HTTPS bedeutet, dass Ihre Nutzer auf Ihrer Website größtenteils eine sichere Verbindung verwenden. Allerdings bleibt ein kleines Angriffsfenster übrig: Die erste HTTP-Verbindung ist weit offen und anfällig für SSL-Striping und damit verbundene Angriffe. Da ein Man-in-the-Middle vollständigen Zugriff auf die ursprüngliche HTTP-Anfrage hat, kann er als Proxy zwischen Ihnen und dem Server fungieren und Sie unabhängig von den Absichten des Servers in einer unsicheren HTTP-Verbindung halten.

Sie können das Risiko dieser Angriffsklasse reduzieren, indem Sie den Browser auffordern, HTTP Strict Transport Security (HSTS) zu erzwingen. Durch Senden des HTTP-Headers Strict-Transport-Security wird der Browser angewiesen, die HTTP-zu-HTTPS-Weiterleitung clientseitig durchzuführen, ohne das Netzwerk zu berühren. Dies verbessert auch die Leistung. Die beste Anfrage ist die, die Sie gar nicht stellen müssen:

$ curl -I https://mkw.st/
HTTP/1.1 200 OK
Server: nginx/1.3.7
...
Strict-Transport-Security: max-age=2592000

In Browsern, die diesen Header unterstützen (derzeit Firefox, Chrome und Opera: Caniuse hat Details), wird darauf hingewiesen, dass diese Website Nur-HTTPS-Zugriff angefordert hat. Das bedeutet, dass die Website über HTTPS aufgerufen wird, unabhängig davon, wie ein Nutzer auf die Website gelangt. Selbst wenn sie http://example.com/ in den Browser eingibt, verwendet sie HTTPS, ohne dass eine HTTP-Verbindung hergestellt werden muss. Und noch besser: Wenn der Browser ein ungültiges Zertifikat erkennt (was möglicherweise versucht, die Identität Ihres Servers zu stehlen), können Nutzer nicht über HTTP fortfahren. Es ist alles oder nichts, was einwandfrei ist.

Der Browser läuft den HSTS-Status des Servers nach max-age Sekunden ab (in diesem Beispiel etwa einen Monat). Legen Sie diesen Wert auf einen angemessenen Wert fest.

Sie können auch dafür sorgen, dass alle Subdomains eines Ursprungs geschützt sind, indem Sie dem Header die Anweisung includeSubDomains hinzufügen:

$ curl -I https://mkw.st/
HTTP/1.1 200 OK
Server: nginx/1.3.7
...
Strict-Transport-Security: max-age=2592000

Sicheres Gehen

HTTPS ist die einzige Möglichkeit, auch aus der Ferne sicher zu sein, dass die von Ihnen gesendeten Daten den gewünschten Empfänger intakt erreichen. Sie sollten schon heute sichere Verbindungen für Ihre Websites und Anwendungen einrichten. Das ist relativ einfach und hilft, die Daten Ihrer Kunden zu schützen. Sobald Sie einen verschlüsselten Kanal eingerichtet haben, sollten Sie Nutzer transparent zu dieser sicheren Verbindung weiterleiten, unabhängig davon, wie sie auf Ihre Website gelangen, indem Sie eine 301-HTTP-Antwort senden. Achten Sie dann darauf, dass alle vertraulichen Sitzungsinformationen Ihrer Nutzer nur diese sichere Verbindung verwenden. Fügen Sie dazu beim Setzen von Cookies das Keyword secure hinzu. Sorgen Sie anschließend dafür, dass Ihre Nutzer nie versehentlich vom Bus abweichen. Schützen Sie sie, indem Sie einen Strict-Transport-Security-Header senden, damit ihr Browser richtig funktioniert.

Die Einrichtung von HTTPS ist nicht viel Arbeit und bietet enorme Vorteile für Ihre Website und ihre Nutzer. Der Aufwand lohnt sich.

Ressourcen

StartSSL bietet kostenlose Zertifikate mit Domainbestätigung. Uns geht es ums Kostenlose. Eine höhere Stufe ist natürlich möglich und ein angemessener Preis.
SSL-Servertest: Wenn Sie HTTPS für Ihre Server eingerichtet haben, prüfen Sie, ob dies richtig gemacht wurde. Führen Sie dazu den Servertest der SSL Labs aus. Sie erhalten einen praktisch detaillierten Bericht, der Ihnen zeigt, ob Sie wirklich produktiv sind.
Im aktuellen Artikel Securing your Web Server with SSL/TLS von Ars Technica finden Sie weitere Hintergrundinformationen zu den praktischen Funktionen der Servereinrichtung.
Es lohnt sich, die HTTP Strict Transport Security-Spezifikation (RFC6797) zu überfliegen, um alle technischen Informationen zum Strict-Transport-Security-Header zu überfliegen.
Sobald ihr euch klar seid, was ihr macht, könnt ihr als nächsten Schritt dafür werben, dass eure Website nur über einen bestimmten Satz von Zertifikaten erreichbar sein sollte. An der IETF gibt es derzeit einige Arbeit, um genau dies über den Public-Key-Pins-Header zu tun. Es gibt zwar noch am Anfang, aber interessant und es lohnt sich, dem zu folgen.