Erläuterung der HTTPS-Prinzipien

Erläuterung der HTTPS-Prinzipien

Da die Kosten für die Erstellung von HTTPS-Websites sinken, verwenden die meisten Websites mittlerweile das HTTPS-Protokoll. Jeder weiß, dass HTTPS sicherer ist als HTTP, und wir haben auch von Konzepten gehört, die mit dem HTTPS-Protokoll in Zusammenhang stehen, wie SSL, asymmetrische Verschlüsselung und CA-Zertifikate. Allerdings können wir die folgenden drei tiefgründigen Fragen möglicherweise nicht beantworten:

1. Warum ist die Verwendung von HTTPS sicher?

2. Wie wird das zugrunde liegende Prinzip von HTTPS implementiert?

3. Ist die Verwendung von HTTPS sicher?

Dieser Artikel geht tiefer in die Materie und erklärt die Sicherheit von HTTPS grundsätzlich.

So funktioniert HTTPS

Sie haben vielleicht gehört, dass das HTTPS-Protokoll deshalb sicher ist, weil es die übertragenen Daten verschlüsselt und der Verschlüsselungsprozess mithilfe einer asymmetrischen Verschlüsselung implementiert wird. Tatsächlich verwendet HTTPS jedoch eine symmetrische Verschlüsselung für die Inhaltsübertragung, und die asymmetrische Verschlüsselung funktioniert nur bei der Zertifikatsüberprüfung.

Der Gesamtprozess von HTTPS ist in die Phasen Zertifikatsüberprüfung und Datenübertragung unterteilt. Der spezifische Interaktionsprozess ist wie folgt:

① Zertifikatsüberprüfungsphase

Der Browser initiiert eine HTTPS-Anfrage

Der Server gibt das HTTPS-Zertifikat zurück

Der Client überprüft, ob das Zertifikat legal ist. Wenn es nicht legal ist, wird ein Alarm ausgelöst.

② Datenübertragungsphase

1. Sobald die Echtheit des Zertifikats bestätigt ist, wird lokal eine Zufallszahl generiert

2. Verschlüsseln Sie die Zufallszahl mit dem öffentlichen Schlüssel und übertragen Sie die verschlüsselte Zufallszahl an den Server

3. Der Server entschlüsselt die Zufallszahl mit dem privaten Schlüssel

4. Der Server erstellt einen symmetrischen Verschlüsselungsalgorithmus unter Verwendung der vom Client übergebenen Zufallszahl und verschlüsselt das zurückgegebene Ergebnis, bevor es übertragen wird

Warum wird bei der Datenübertragung eine symmetrische Verschlüsselung verwendet?

Erstens ist die Effizienz der asymmetrischen Verschlüsselung beim Ver- und Entschlüsseln sehr gering. In HTTP-Anwendungsszenarien gibt es normalerweise viel Interaktion zwischen den Enden, sodass die Effizienz der asymmetrischen Verschlüsselung nicht akzeptabel ist.

Darüber hinaus speichert im HTTPS-Szenario nur der Server den privaten Schlüssel, und ein Paar aus öffentlichen und privaten Schlüsseln kann nur eine Einweg-Verschlüsselung und -Entschlüsselung erreichen, sodass für die Verschlüsselung der Inhaltsübertragung in HTTPS eine symmetrische Verschlüsselung anstelle einer asymmetrischen Verschlüsselung verwendet wird.

Warum benötigen wir eine Zertifizierungsstelle (CA) für die Ausstellung eines Zertifikats?

Das HTTP-Protokoll gilt als unsicher, da der Übertragungsvorgang leicht abgefangen und der Server von Lauschern gefälscht werden kann, während das HTTPS-Protokoll hauptsächlich das Sicherheitsproblem der Netzwerkübertragung löst.

Zunächst gehen wir davon aus, dass es keine Zertifizierungsstelle gibt und jeder ein Zertifikat erstellen kann. Das damit verbundene Sicherheitsrisiko ist das klassische „Man-in-the-Middle-Angriffs“-Problem.

Der konkrete Ablauf eines „Man-in-the-Middle-Angriffs“ sieht wie folgt aus:

Verfahrensprinzip:

1. Lokale Anfragen werden entführt (z. B. DNS-Hijacking usw.) und alle Anfragen werden an den Server des Mittelsmanns gesendet

2. Der Zwischenhändler-Server gibt das Zertifikat des Zwischenhändlers zurück

3. Der Client erstellt eine Zufallszahl, verschlüsselt sie mit dem öffentlichen Schlüssel des Zertifikats des Mittelsmanns und sendet sie an den Mittelsmann. Anschließend verwendet er die Zufallszahl, um eine symmetrische Verschlüsselung zum Verschlüsseln des Übertragungsinhalts zu erstellen.

4. Der Mittelsmann kann den Inhalt durch den symmetrischen Verschlüsselungsalgorithmus entschlüsseln, da er die Zufallszahl des Kunden hat

5. Der Mittelsmann sendet eine Anfrage mit dem Anfrageinhalt des Kunden an die reguläre Website

6. Da der Kommunikationsprozess zwischen dem Mittelsmann und dem Server legal ist, gibt die legitime Website die verschlüsselten Daten über den etablierten sicheren Kanal zurück

7. Der Mittelsmann entschlüsselt den Inhalt mithilfe des symmetrischen Verschlüsselungsalgorithmus, der auf der offiziellen Website festgelegt wurde

8. Der Mittelsmann verschlüsselt und überträgt die vom regulären Inhalt zurückgegebenen Daten über den mit dem Client festgelegten symmetrischen Verschlüsselungsalgorithmus

9. Der Client entschlüsselt die zurückgegebenen Ergebnisdaten mit dem mit dem Mittelsmann festgelegten symmetrischen Verschlüsselungsalgorithmus.

Aufgrund der fehlenden Zertifikatsüberprüfung ist sich der Client, obwohl er eine HTTPS-Anforderung initiiert, überhaupt nicht bewusst, dass sein Netzwerk abgefangen wurde und der Übertragungsinhalt vom Mittelsmann vollständig gestohlen wurde.

Wie stellt der Browser die Legitimität des CA-Zertifikats sicher?

1. Welche Informationen enthält das Zertifikat?

Angaben zur herausgebenden Stelle

Öffentlicher Schlüssel

Informationen zum Unternehmen

Domänenname

Gültigkeit

Fingerabdruck

......

2. Was ist die Rechtsgrundlage des Zertifikates?

Zunächst muss eine autoritative Organisation zertifiziert sein. Nicht jede Organisation ist dazu befugt, Zertifikate auszustellen, sonst kann sie nicht als autoritative Organisation bezeichnet werden.

Darüber hinaus basiert die Glaubwürdigkeit des Zertifikats auf dem Vertrauenssystem. Die autoritative Organisation muss die von ihr ausgestellten Zertifikate bestätigen. Solange das Zertifikat von einer autoritativen Organisation erstellt wird, betrachten wir es als legal.

Daher überprüfen die zuständigen Stellen die Angaben des Antragstellers. Die zuständigen Stellen auf verschiedenen Ebenen stellen unterschiedliche Anforderungen an die Überprüfung, daher werden die Zertifikate in kostenlose, günstige und teure unterteilt.

3. Wie überprüft der Browser die Legitimität des Zertifikats?

Wenn der Browser eine HTTPS-Anforderung initiiert, gibt der Server das SSL-Zertifikat der Website zurück. Der Browser muss das Zertifikat wie folgt überprüfen:

1. Überprüfen Sie, ob Domänenname, Gültigkeitsdauer und weitere Angaben korrekt sind. Das Zertifikat enthält diese Informationen und erleichtert die Überprüfung.

2. Stellen Sie fest, ob die Quelle des Zertifikats legal ist. Jedes ausgestellte Zertifikat kann das entsprechende Stammzertifikat anhand der Überprüfungskette finden. Das Betriebssystem und der Browser speichern das Stammzertifikat der Zertifizierungsstelle lokal. Das lokale Stammzertifikat kann verwendet werden, um die Quellenüberprüfung des von der entsprechenden Organisation ausgestellten Zertifikats abzuschließen.

3. Stellen Sie fest, ob das Zertifikat manipuliert wurde. Muss mit dem CA-Server überprüft werden;

4. Stellen Sie fest, ob das Zertifikat widerrufen wurde. Dies wird durch CRL (Certificate Revocation List) und OCSP (Online Certificate Status Protocol) erreicht. OCSP kann in Schritt 3 verwendet werden, um die Interaktion mit dem CA-Server zu reduzieren und die Überprüfungseffizienz zu verbessern.

Der Browser betrachtet das Zertifikat nur dann als legitim, wenn einer der oben genannten Schritte erfüllt ist.

Hier ist eine Frage, über die ich schon lange nachgedacht habe, aber die Antwort ist eigentlich ganz einfach:

Da das Zertifikat öffentlich ist, kann ich, wenn ich einen Man-in-the-Middle-Angriff starten möchte, ein Zertifikat von der offiziellen Website als mein Serverzertifikat herunterladen. Der Client erkennt dann mit Sicherheit, dass dieses Zertifikat legitim ist. Wie kann ich diese Art der Zertifikatsfälschung vermeiden?

Tatsächlich handelt es sich hierbei um die Verwendung von öffentlichen und privaten Schlüsseln bei der unverschlüsselten symmetrischen Authentifizierung. Obwohl der Mittelsmann das Zertifikat erhalten kann, ist der private Schlüssel nicht erhältlich. Es ist unmöglich, den entsprechenden privaten Schlüssel aus einem öffentlichen Schlüssel abzuleiten. Selbst wenn der Mittelsmann das Zertifikat erhält, kann er sich nicht als legitimer Server tarnen, da er die vom Client übermittelten verschlüsselten Daten nicht entschlüsseln kann.

4. Können nur Zertifizierungsstellen Zertifikate erstellen?

Wenn Sie möchten, dass Ihr Browser keine Sicherheitsrisiken birgt, können Sie nur ein Zertifikat einer Zertifizierungsstelle verwenden. Allerdings weisen Browser normalerweise nur auf Sicherheitsrisiken hin und schränken den Zugriff auf die Website nicht ein. Technisch gesehen kann also jeder ein Zertifikat generieren und, sofern er über ein Zertifikat verfügt, die HTTPS-Übertragung der Website abschließen. Beispielsweise wurde zu Beginn des Jahres 12306 die Methode übernommen, private Zertifikate manuell zu installieren, um HTTPS-Zugriff zu erhalten.

Was tun, wenn die lokale Zufallszahl gestohlen wird?

Die Zertifikatsüberprüfung erfolgt über asymmetrische Verschlüsselung, der Übertragungsprozess jedoch über symmetrische Verschlüsselung. Die wichtigen Zufallszahlen im symmetrischen Verschlüsselungsalgorithmus werden lokal generiert und gespeichert. Wie stellt HTTPS sicher, dass die Zufallszahlen nicht gestohlen werden?

Tatsächlich bietet HTTPS keine Sicherheitsgarantien für Zufallszahlen. HTTPS garantiert nur die Sicherheit des Übertragungsprozesses. Zufallszahlen werden lokal gespeichert und lokale Sicherheit gehört zu einer anderen Sicherheitskategorie. Gegenmaßnahmen umfassen die Installation von Antivirensoftware, Antitrojanersoftware und Browser-Upgrades zur Behebung von Schwachstellen.

Werde ich erfasst, wenn ich HTTPS verwende?

HTTPS-Daten sind verschlüsselt. Normalerweise ist der vom Paketerfassungstool nach der Proxy-Anforderung erfasste Paketinhalt verschlüsselt und kann nicht direkt angezeigt werden. Folgen Sie dem öffentlichen WeChat-Konto: Java Technology Stack, und antworten Sie im Hintergrund: Tools, um N der neuesten Tutorials zu Entwicklungstools zu erhalten, die ich zusammengestellt habe und die alle praktisch sind.

Wie oben erwähnt, weist der Browser jedoch nur auf ein Sicherheitsrisiko hin. Wenn der Benutzer dies autorisiert, kann er weiterhin auf die Website zugreifen und die Anfrage abschließen. Solange der Client unser eigenes Terminal ist und wir ihn autorisieren, können wir ein Vermittlernetzwerk bilden und das Paketerfassungstool fungiert als Vermittleragent.

Normalerweise besteht die Verwendung von HTTPS-Paketerfassungstools darin, ein Zertifikat zu generieren. Der Benutzer muss das Zertifikat manuell auf dem Client installieren. Anschließend schließen alle vom Terminal initiierten Anforderungen die Interaktion mit dem Paketerfassungstool über das Zertifikat ab. Das Paketerfassungstool leitet die Anforderung dann an den Server weiter. Schließlich wird das vom Server zurückgegebene Ergebnis an die Konsole ausgegeben und dann an das Terminal zurückgegeben, wodurch der geschlossene Kreislauf der gesamten Anforderung abgeschlossen wird.

Da HTTPS die Paketerfassung nicht verhindern kann, was ist dann der Sinn von HTTPS?

A: Der Client initiiert eine HTTPS-Anforderung, der Server gibt ein Zertifikat zurück und der Client überprüft das Zertifikat. Nach erfolgreicher Überprüfung wird lokal eine Zufallszahl generiert, um den symmetrischen Verschlüsselungsalgorithmus zu transformieren. Die Zufallszahl wird mit dem öffentlichen Schlüssel im Zertifikat verschlüsselt und an den Server übertragen. Nach Erhalt der Zufallszahl entschlüsselt der Server sie mit dem privaten Schlüssel, um die Zufallszahl zu erhalten. Nachfolgende Dateninteraktionen werden mit dem symmetrischen Verschlüsselungsalgorithmus verschlüsselt und entschlüsselt.

F: Warum brauche ich ein Zertifikat?

A: Es verhindert „Man-in-the-Middle“-Angriffe und ermöglicht eine Identitätsüberprüfung für Websites.

F: Werde ich erfasst, wenn ich HTTPS verwende?

A: Die Pakete werden abgefangen. HTTPS verhindert lediglich, dass die Kommunikation des Benutzers ohne dessen Wissen überwacht wird. Wenn der Benutzer aktiv Vertrauen schenkt, kann ein „Man-in-the-Middle“-Netzwerk aufgebaut werden und die Proxy-Software kann den übertragenen Inhalt entschlüsseln.

Oben finden Sie eine ausführliche Erklärung des HTTPS-Prinzips. Weitere Informationen zum HTTPS-Prinzip finden Sie in den anderen verwandten Artikeln auf 123WORDPRESS.COM!

Das könnte Sie auch interessieren:
  • HTTPS-Kommunikationsprinzip und detaillierte Einführung
  • Die beste Erklärung zu HTTPS

<<:  Detaillierte Erklärung der allgemeinen Verwendung von MySQL-Abfragebedingungen

>>:  Native JavaScript-Karussell-Implementierungsmethode

Artikel empfehlen

Eine kurze Diskussion über die Magie von parseInt() in JavaScript

Ursache Der Grund für das Schreiben dieses Blogs ...

Erste Schritte mit Nginx Reverse Proxy

Inhaltsverzeichnis Überblick Die Rolle des Revers...

Vorteile und Prinzipien der MySQL-Replikation im Detail erklärt

Bei der Replikation werden die DDL- und DML-Opera...

So fügen Sie einem laufenden Docker-Container dynamisch ein Volume hinzu

Jemand hat mich schon einmal gefragt, ob es mögli...

CentOS8-Netzwerkkarten-Konfigurationsdatei

1. Einleitung CentOS8-Systemupdate, die neue Vers...

CentOS 8 offiziell veröffentlicht, basierend auf Red Hat Enterprise Linux 8

Das CentOS-Projekt, ein 100 % kompatibler Neuaufb...

Vue hält den Benutzer angemeldet (verschiedene Token-Speichermethoden)

Inhaltsverzeichnis So setzen Sie Cookies Nachteil...

Tutorial zur Samba-Konfiguration für die Dateifreigabe im Linux-System

Inhaltsverzeichnis Deinstallieren und installiere...

WeChat Mini-Programm: Position des Videofeuers zufällig

In diesem Artikel wird der spezifische Code zur z...

So zeichnen Sie eine Schaltfläche in XAML als Kreis neu

Beim Verwenden des XAML-Layouts müssen manchmal ei...

Mehrere Möglichkeiten zum Festlegen der Ablaufzeit von localStorage

Inhaltsverzeichnis Problembeschreibung 1. Basislö...

So beheben Sie den MySQL-FEHLER 1045 (28000) - Zugriff wegen Benutzer verweigert

Problembeschreibung (die folgende Diskussion besc...