In einem Abschnitt haben wir den sicheren Kommunikationsprozess von HTTPS analysiert und erfahren, dass HTTPS Man-in-the-Middle-Angriffe wirksam verhindern kann. Aber jeder, der Paketerfassungstools verwendet hat, weiß, dass beispielsweise Charles und Fiddler HTTPS-Anfragen erfassen und entschlüsseln können.
Schauen wir uns zunächst die Beschreibung des HTTPS-Proxys auf der offiziellen Website von Charles an: (empfohlenes Lernen: Webfront- Video-Tutorial beenden)
Charles fungiert als Vermittler. Wenn der Browser mit dem Server kommuniziert, empfängt Charles das Zertifikat des Servers, generiert es jedoch dynamisch und sendet es an den Browser Das heißt, Charles fungiert als Vermittler im Browser und kommuniziert mit dem Server, sodass die Kommunikationsdaten von Charles abgefangen und entschlüsselt werden können. Da Charles das Zertifikat geändert hat, wird eine Sicherheitswarnung ausgegeben, wenn die Browserüberprüfung fehlschlägt, und Charles‘ Zertifikat muss installiert werden, bevor der normale Zugriff durchgeführt werden kann.
Was Charles tun muss, ist, den Server für den Client und den Client für den Server zu tarnen:
Die HTTPS-Anfrage des echten Clients abfangen und Den Client verschleiern Der Client sendet eine HTTPS-Anfrage an den echten Server
Akzeptiert die Antwort des echten Servers, verwendet Charles‘ eigenes Zertifikat, um den Server zu verschleiern und sendet den Dateninhalt an den echten Client
Sehen wir uns den spezifischen Prozess an:
Der Client initiiert eine HTTPS-Anfrage an den Server
Charles fängt die Anfrage des Clients ab und gibt vor, ein Client zu sein, um eine Anfrage an den Server zu stellen Server
Der Server sendet eine Anfrage an den „Client“ (eigentlich Oben ist Charles) und gibt das CA-Zertifikat des Servers zurück
Charles fängt die Antwort des Servers ab, erhält den öffentlichen Schlüssel des Serverzertifikats und erstellt dann einen Zertifikat selbst, ersetzt das Serverzertifikat und sendet es an den Client. (In diesem Schritt erhält Charles den öffentlichen Schlüssel des Serverzertifikats)
Nachdem der Client das Zertifikat des „Servers“ (eigentlich Charles) erhalten hat, generiert er einen symmetrischen Schlüssel und verschlüsselt ihn mit Charles‘ öffentlichem Schlüssel und sendet es an den „Server“ (Charles)
Charles fängt die Antwort des Clients ab, entschlüsselt den symmetrischen Schlüssel mit seinem eigenen privaten Schlüssel, verschlüsselt ihn dann mit dem öffentlichen Schlüssel des Serverzertifikats und sendet ihn an den Server. (In diesem Schritt erhält Charles den symmetrischen Schlüssel)
Der Server entschlüsselt den symmetrischen Schlüssel mit seinem eigenen privaten Schlüssel und sendet eine Antwort an den „Client“ (Charles)
Charles fängt die des Servers ab Antwort: Ersetzen Sie es durch sein eigenes Zertifikat und senden Sie es an den Client
Zu diesem Zeitpunkt ist die Verbindung hergestellt. Charles hat den öffentlichen Schlüssel des Serverzertifikats und den zwischen Client und Server ausgehandelten symmetrischen Schlüssel erhalten . Er kann dann die verschlüsselte Nachricht entschlüsseln oder ändern.
Das Prinzip der HTTPS-Paketerfassung ist ganz einfach: Charles erhält als „Mittelsmann“ den öffentlichen Schlüssel des Serverzertifikats und den symmetrischen Schlüssel der HTTPS-Verbindung. Die Voraussetzung ist, dass der Client „Vertrauen“ wählt und das CA-Zertifikat von Charles installiert, andernfalls gibt der Client „Alarm“ aus und beendet die Verbindung. Unter diesem Gesichtspunkt ist HTTPS immer noch sehr sicher
Das obige ist der detaillierte Inhalt vonPrinzip der https-Paketerfassung. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!