Detaillierte Erklärung, wie man HSTS in nginx aktiviert, um den Browser zu zwingen, auf HTTPS-Zugriff umzuleiten

Im vorherigen Artikel haben wir den lokalen Knotendienstzugriff über https implementiert. Die Auswirkungen des vorherigen Artikels sind wie folgt zu sehen:

Wenn wir jetzt jedoch http für den Zugriff verwenden, können wir nicht darauf zugreifen. Wie in der folgenden Abbildung dargestellt:

Das erste, was ich jetzt tun muss, ist die Nginx-Konfiguration. Wenn der Benutzer eine HTTP-Anforderung im Browser eingibt, wird sie mithilfe von Nginx auf HTTPS umgeleitet. Also müssen wir jetzt eine einfache Nginx-Umleitungsfunktion erstellen.

Daher müssen wir in unserem Nginx die folgende Umleitungskonfiguration hinzufügen:

Server {
 hören Sie xxx.abc.com;
 Servername xxx.abc.com;
 schreibe ^/(.*)$ https://$host$1 permanent um;
}

Daher lautet der Hauptkonfigurationscode von nginx wie folgt:

Server {
 hören Sie xxx.abc.com;
 Servername xxx.abc.com;
 schreibe ^/(.*)$ https://$host$1 permanent um;
}
Server {
 hören Sie 443 SSL;
 Servername xxx.abc.com;

 SSL-Zertifikat cert/server.crt;
 SSL-Zertifikatsschlüssel cert/server.key;

 ssl_session_cache geteilt:SSL:1m;
 SSL-Sitzungszeitüberschreitung 5 Min.

 ssl_ciphers HOCH:!aNULL:!MD5;
 ssl_prefer_server_ciphers ein;

 Standort / {
 Proxy-Passwort http://localhost:3001;
 }
}

Nach der obigen Konfiguration müssen wir nginx neu starten, damit die Änderungen wirksam werden. Wenn wir den Domänennamen http://xxx.abc.com in den Browser eingeben, wird automatisch eine Weiterleitung zu https://xxx.abc.com/ durchgeführt. Werfen wir einen Blick auf die Anfragen in unserem Netzwerk. Es gibt 2 Anfragen, wie unten gezeigt:

Wie aus der obigen Anfrage ersichtlich ist, initiiert der Browser zunächst eine HTTP-Anfrage an die Website (http://xxx.abc.com) und initiiert nach Erhalt einer Umleitungsantwort eine HTTPS-Anfrage und erhält den endgültigen Antwortinhalt. Für Benutzer ist die Funktionsweise transparent und das Benutzererlebnis gut, allerdings erfolgen vor dem https-Link eine HTTP-Anforderung im Klartext und eine Umleitung. Anschließend kann der Angreifer die HTTP-Anfrage im Wege eines Man-in-the-Middle-Vorgangs kapern. um weitere Angriffe durchzuführen. Beispielsweise das Abhören von Daten. Manipulation von Anfragen oder Antworten, Aufrufen von Phishing-Websites usw. Aus diesem Grund sind http-Anfragen nicht sicher genug, weshalb seit einigen Jahren alle Websites über https aufgerufen werden müssen.

Nehmen wir als Beispiel das Hijacking von HTTP-Anfragen und den Sprung zu Phishing-Websites, um zu sehen, wie der allgemeine Hijacking-Prozess aussieht.

Die Schritte sind wie folgt:
1. Der Browser initiiert eine HTTP-Anfrage (z. B. http://xxx.abc.com). Nachdem die Anfrage gesendet wurde, kapert der Angreifer die HTTP-Anfrage als Man-in-the-Middle.
2. Nachdem der Angreifer die HTTP-Anfrage gekapert hat, leitet er die aktuelle Anfrage an die Phishing-Website weiter (z. B. http://xxx.yyy.com).
3. Die Phishing-Website gibt gefälschte Webseiteninhalte zurück.
4. Schließlich gibt der Angreifer den gefälschten Webseiteninhalt an den Browser zurück.

Wie oben gezeigt, wird die HTTP-Anforderung überhaupt nicht auf die HTTPS-Website umgeleitet. Stattdessen kapert der Angreifer die HTTP-Anforderung direkt und gibt die Phishing-Website schließlich an den Browser zurück. Wenn daher eine HTTP-Umleitung direkt verwendet wird, tritt das Problem der HTTP-Anforderung im Klartext auf. Daher ist es nicht sicher, eine HTTP-Umleitung direkt zu verwenden. Daher scheint HSTS dieses Problem zu lösen. Werfen wir einen Blick auf HSTS.

2. HSTS verstehen

Bei der Umleitung von http zu https mit der oben genannten Umleitungsmethode besteht ein Sicherheitsproblem, da vor der Umleitung zu https eine HTTP-Klartextanforderung vorliegt, sodass Angreifer die HTTP-Anforderung leicht kapern können. Daher möchten wir jetzt, dass der Browser sie direkt in eine HTTP-Anforderung umwandelt, wenn der Browser des Benutzers eine HTTP-Anforderung initiiert. Fordern Sie die Seite dann über https an, sodass ein Angriff für Angreifer grundsätzlich schwierig ist. Wir können uns das folgende schematische Diagramm ansehen, wie unten dargestellt:

Die einzelnen Schritte können wie folgt verstanden werden:

1. Wenn der Benutzer http://xxx.abc.com in den Browser eingibt, weiß der Browser, dass der Domänenname zur Kommunikation https verwenden muss.
2. Daher initiiert der Browser direkt eine https-Anfrage an die Website (z. B. https://xxx.abc.com).
3. Die Website gibt den Antwortinhalt zurück.

Die Frage ist nun: Woher weiß der Browser, dass der Domänenname https verwenden muss? Also haben wir derzeit HSTS.

Was ist HSTS?

Der vollständige Name von HSTS lautet HTTP Strict-Transport-Security. Es handelt sich um einen von der International Internet Engineering Organization IETF herausgegebenen Mechanismus für Internetsicherheitsrichtlinien. Websites, die die HSTS-Richtlinie übernehmen, stellen sicher, dass Browser immer eine Verbindung zur https-verschlüsselten Version der Website herstellen. Um das Risiko eines Session Hijackings zu verringern, müssen Benutzer die verschlüsselte Adresse nicht manuell in die URI-Adressleiste eingeben.

Die grundlegende Syntax von HSTS lautet wie folgt:

Strikte Transportsicherheit: max-age=expireTime [; includeSubDomains] [; vorladen]

max-age ist ein erforderlicher Parameter. Es handelt sich um einen Wert in Sekunden. Er stellt die Ablaufzeit des HSTS-Headers dar und ist im Allgemeinen auf 1 Jahr oder 31536000 Sekunden eingestellt.
includeSubDomains ist ein optionaler Parameter. Wenn dieser Parameter gesetzt ist, bedeutet dies, dass der HSTS-Schutz für die aktuelle Domäne und ihre Subdomänen aktiviert ist.
„Preload“ ist ein optionaler Parameter und wird nur benötigt, wenn Sie Ihren Domänennamen zur integrierten Liste des Browsers hinzufügen möchten.

Als nächstes schauen wir uns an, wie Baidu damit umgeht. Zuerst geben wir http://www.baidu.com/ in die Browser-URI ein und drücken die Eingabetaste. Der Browser konvertiert es automatisch in eine Anfrage wie https://www.baidu.com/. Wenn wir jedoch den Chrome-Browser verwenden, um die Netzwerkanfrage anzuzeigen, können wir sehen, dass zwei Anfragen wie folgt gesendet werden:

Die zweite ist eine https-Anfrage, wie unten gezeigt:

Wir können oben sehen, dass der Statuscode der ersten Anfrage 307 ist und der Anfrageheader die folgende Markierung „Vorläufige Header werden angezeigt“ aufweist, was bedeutet, dass der Browser die Anfrage abgefangen hat und die Anfrage nicht gesendet wurde. Der Browser stellt daher fest, dass der Domänenname per https angefordert werden muss, und sendet eine zweite https-Anforderung.

HSTS in nginx konfigurieren

Legen Sie den HSTS-Antwortheader in der nginx-Konfigurationsdatei fest. Der Code lautet wie folgt:

add_header Strict-Transport-Security "max-age=172800; includeSubDomains"

Daher ist die Konfiguration von nginx wie folgt:

Server {
 hören Sie xxx.abc.com;
 Servername xxx.abc.com;
 schreibe ^/(.*)$ https://$host$1 permanent um;
}
Server {
 hören Sie 443 SSL;
 Servername xxx.abc.com;
 add_header Strict-Transport-Security "max-age=172800; includeSubDomains";
 SSL-Zertifikat cert/server.crt;
 SSL-Zertifikatsschlüssel cert/server.key;

 ssl_session_cache geteilt:SSL:1m;
 SSL-Sitzungszeitüberschreitung 5 Min.

 ssl_ciphers HOCH:!aNULL:!MD5;
 ssl_prefer_server_ciphers ein;

 Standort / {
 Proxy-Passwort http://localhost:3001;
 }
}

Speichern Sie dann die Nginx-Konfiguration und starten Sie sie neu.

Wenn ich nach dem Neustart zum ersten Mal https verwende, um auf meine Website zuzugreifen, teilt nginx dem Client-Browser mit, dass der Browser, wenn der Benutzer in Zukunft http eingibt, auch über https auf meinen nginx-Server zugreifen soll, wie unten gezeigt:

Wenn nginx jedoch neu gestartet wird und für den ersten Zugriff http verwendet wird, wird HSTS trotz der Sprünge nicht verwendet, da HSTS nur beim Springen zu https verwendet wird. Aber wenn ich http erneut eingebe, wird ein Statuscode 307 und eine Eingabeaufforderung wie „Vorläufige Header werden angezeigt“ angezeigt.

Grundlegendes zur HSTS-Vorladeliste

Obwohl HSTS den Downgrade-Angriff von HTTPS lösen kann, kann es das Problem der Entführung der HTTP-Anforderung für die erste HTTP-Anforderung nicht vermeiden, bevor HSTS wirksam wird. Wenn wir beispielsweise den Browser-Cache zum ersten Mal leeren und dann die HTTP-Anforderung zum ersten Mal verwenden, wird das erste HTTP auch im Klartext übertragen. Beim Springen zu https wird HSTS verwendet. In Zukunft wird HSTS-Schutz verwendet, solange der Browser-Cache nicht geleert und nginx nicht neu gestartet wird. Um das Problem der ersten http-Anforderung zu lösen, haben Browserhersteller daher die HSTS-Preload-List-Lösung vorgeschlagen, die über eine integrierte Tabelle verfügt, die regelmäßig aktualisiert werden kann. Domänennamen in der Liste werden mithilfe des https-Protokolls angefordert, auch wenn der Benutzer sie noch nie zuvor besucht hat.

Derzeit wird diese Preload-Liste von Google Chrome verwaltet und von Chrome, Firefox, Safari, IE 11 und Microsoft Edge verwendet. Wenn Sie Ihren Domänennamen zu dieser Liste hinzufügen möchten, müssen Sie zunächst die folgenden Bedingungen erfüllen:

1. Sie müssen über ein gültiges Zertifikat verfügen (bei Verwendung eines SHA-1-Zertifikats muss das Ablaufdatum vor 2016 liegen);

2. Leiten Sie den gesamten HTTP-Verkehr auf HTTPS um.
3. Stellen Sie sicher, dass HTTPS auf allen Subdomains aktiviert ist;
4. HSTS-Antwortheader ausgeben:
5. Das Höchstalter darf nicht weniger als 18 Wochen (10886400 Sekunden) betragen.
6. Der Parameter „includeSubdomains“ muss angegeben werden;
7. Der Vorladeparameter muss angegeben werden;

Auch wenn alle oben genannten Bedingungen erfüllt sind, werden Sie möglicherweise nicht in die HSTS-Preload-Liste aufgenommen. Weitere Informationen finden Sie unter: https://hstspreload.org/.

Mit dem Chrome-Tool „chrome://net-internals/#hsts“ können Sie prüfen, ob sich eine Website in der PreloadList befindet. Außerdem können Sie der lokalen Preload-Liste manuell einen Domänennamen hinzufügen.

Nachteile von HSTS

HSTS ist keine perfekte Lösung gegen HTTP-Session-Hijacking. Wenn ein Benutzer eine Website zum ersten Mal besucht, ist diese nicht durch HSTS geschützt. Dies liegt daran, dass der Browser beim ersten Besuch kein HSTS empfangen hat und daher weiterhin ein Zugriff über Klartext-HTTP möglich ist.

Wenn ein Benutzer über HTTP auf eine durch HSTS geschützte Website zugreift, kann es in den folgenden Situationen zu einem Downgrade-Hijacking kommen:

1. Ich habe diese Website noch nie zuvor besucht.
2. Das Betriebssystem wurde vor Kurzem neu installiert.
3. Den Browser vor Kurzem neu installiert.
4. Wechseln Sie zu einem neuen Browser.
5. Löschen Sie den Cache Ihres Browsers.
6. Die Site wurde in letzter Zeit nicht besucht und das Höchstalter ist überschritten.
Um dieses Problem zu lösen, können Sie die oben vorgestellte HSTS-Preload-List-Methode verwenden.

HSTS-unterstützte Browser

Derzeit unterstützen gängige Browser bereits HSTS-Funktionen. Weitere Einzelheiten finden Sie in der folgenden Liste:

Google Chrome 4 und höher
Firefox 4 und höher
Opera 12 und höher
Safari seit OS X Mavericks
Internet Explorer und höher

Das Obige ist der vollständige Inhalt dieses Artikels. Ich hoffe, er wird für jedermanns Studium hilfreich sein. Ich hoffe auch, dass jeder 123WORDPRESS.COM unterstützen wird.