Wie gewährleistet HTTPS die Websicherheit? (Codebeispiel)

Der Inhalt dieses Artikels befasst sich mit der Frage, wie HTTPS die Websicherheit gewährleistet. (Codebeispiel) hat einen gewissen Referenzwert. Freunde in Not können darauf verweisen.

HTTPS (vollständiger Name: HyperText Transfer Protocol over Secure Socket Layer) soll die Sicherheit der Datenübertragung zwischen dem Client und dem Server gewährleisten. In den letzten zwei Jahren haben Internetgiganten wie Google, Baidu und Facebook begonnen, HTTPS energisch zu fördern. Viele große Internetunternehmen im In- und Ausland haben auch HTTPS für die gesamte Website aktiviert. Für Front-End-Ingenieure ist das Verständnis der Prinzipien von HTTPS ebenfalls ein Pflichtkurs.
2019 ist nicht mehr weit von der Verwendung von HTTPS im gesamten Netzwerk entfernt. Hier sind einige Anforderungen, die von großen Internetunternehmen gestellt werden, um die Verwendung von HTTPS zu fördern:
1 um bei Suchanfragen effektiver zu sein
2. Apple verlangt, dass alle Apps im App Store HTTPS-verschlüsselte Verbindungen verwenden
4. Eine neue Generation von HTTP/2. Die Unterstützung des Protokolls muss auf HTTPS basieren.
5 Die neue Version von Chrome hat die HTTP-Protokoll-Website als
Versteckte Gefahr: Warum S zu HTTP hinzufügen?

Das HTTP-Protokoll ist seit seiner Einführung sehr gut und praktisch. Allerdings hat HTTP nicht nur gute Seiten, alles hat zwei Seiten, und seine Mängel liegen auch auf der Hand:

Die Kommunikation wird im Klartext übertragen und der Inhalt kann abgehört werden

• Die Identität der kommunizierenden Partei wird nicht überprüft, sodass es zu einer Tarnung kommen kann

• Die Integrität der Nachricht kann nicht nachgewiesen werden, daher wurde sie möglicherweise manipuliert

• Darüber hinaus weist HTTP selbst viele Mängel auf. Darüber hinaus gibt es auch Mängel (die man auch als Schwachstellen oder Sicherheitslücken bezeichnen kann) in tatsächlichen Anwendungen bestimmter spezifischer Webserver und bestimmter Webbrowser. Darüber hinaus können Webanwendungen vorhanden sein, die mit Programmiersprachen wie Java und PHP entwickelt wurden können auch Sicherheitslücken sein.

1. Kommunikation mit Klartext kann abgehört werden

Da HTTP selbst keine Verschlüsselungsfunktion hat, kann es nicht zur Verschlüsselung der gesamten Kommunikation (Kommunikation mit) verwendet werden (Anforderungs- und Antwortinhalte des HTTP-Protokolls) werden verschlüsselt. Daher werden HTTP-Nachrichten im Klartext gesendet. Wenn Sie sich fragen möchten, warum die Nichtverschlüsselung der Kommunikation einen Nachteil darstellt, liegt dies daran, dass gemäß dem Arbeitsmechanismus der TCP/IP-Protokollsuite der Kommunikationsinhalt möglicherweise auf allen Kommunikationsleitungen abgehört wird. Das sogenannte Internet besteht aus Netzwerken, die mit der ganzen Welt verbunden werden können, unabhängig davon, wo der Server auf der Welt mit dem Client kommuniziert, einige Netzwerkgeräte, optische Kabel, Computer usw. über diese Kommunikationsleitung Es kann sich nicht um Privatbesitz handeln, sodass es nicht ausgeschlossen ist, dass es in einem bestimmten Zusammenhang zu böswilligem Voyeurismus kommt.

Selbst wenn die Kommunikation verschlüsselt wurde, wird der Inhalt der Kommunikation eingesehen, was der unverschlüsselten Kommunikation entspricht. Dies bedeutet lediglich, dass es bei verschlüsselter Kommunikation möglicherweise unmöglich ist, die Bedeutung der Nachrichteninformationen zu entschlüsseln, die verschlüsselte Nachricht selbst jedoch weiterhin sichtbar ist.

Das Abhören der Kommunikation im selben Segment ist nicht schwierig. Sammeln Sie einfach die im Internet fließenden Datenpakete. Die Analyse der gesammelten Datenpakete kann diesen Paketerfassungs- oder Sniffing-Tools überlassen werden.


2. Wenn die Identität der kommunizierenden Partei nicht überprüft wird, kann dies zu einer Verschleierung führen.

Die Anfrage und Antwort im HTTP-Protokoll bestätigt die kommunizierende Partei nicht. Mit anderen Worten, es gibt ähnliche Probleme wie „ob der Server der tatsächlich durch den URI in der Anfrage angegebene Host ist und ob die zurückgegebene Antwort tatsächlich an den Client zurückgegeben wird, der die Anfrage tatsächlich gestellt hat.“ Da es während der HTTP-Protokollkommunikation keinen Verarbeitungsschritt zur Bestätigung der kommunizierenden Partei gibt, kann jeder gleichzeitig eine Anfrage senden, solange der Server die Anfrage empfängt, solange die IP-Adresse und die Portnummer von Der Absender wird nicht durch den Webserver eingeschränkt. Unabhängig davon, wer die Gegenpartei ist, wird eine Antwort zurückgegeben, sodass verschiedene versteckte Gefahren bestehen:

Es ist unmöglich festzustellen Unabhängig davon, ob der Webserver, der die Anfrage an das Ziel sendet, der Server ist, der die Antwort gemäß der wahren Absicht zurückgibt, kann es sich um einen getarnten Webserver handeln.

• Es ist unmöglich festzustellen, ob der durch die Antwort zurückgegebene Kunde der Kunde ist, der die Antwort gemäß der wahren Absicht erhalten hat. Möglicherweise handelt es sich um einen getarnten Kunden.

• Es kann nicht festgestellt werden, ob die andere Partei, mit der Sie kommunizieren, Zugriffsrechte hat. Da einige Webserver wichtige Informationen speichern, die auf Berechtigungen für die an bestimmte Benutzer gesendete Kommunikation hinweisen.

• Es lässt sich nicht feststellen, woher die Anfrage kommt und wer sie gestellt hat.

• Anfragen, die zeitlich bedeutungslos sind, werden vollumfänglich angenommen. DoS-Angriffe (Denial of Service, Denial of Service-Angriffe) können bei massiven Anfragen nicht verhindert werden.
3. Die Integrität der Nachricht kann nicht nachgewiesen werden und wurde möglicherweise manipuliert

Die sogenannte Vollständigkeit bezieht sich auf die Richtigkeit von Informationen. Wenn die Vollständigkeit nicht nachgewiesen werden kann, kann in der Regel nicht beurteilt werden, ob die Informationen korrekt sind.
Daher gibt es keine Möglichkeit, dies festzustellen, selbst wenn die Anfrage oder der entsprechende Inhalt in der Zeit nach dem Senden der Anfrage oder Antwort und vor dem Empfang durch die andere Partei manipuliert wurde.
Mit anderen Worten: Es gibt keine Möglichkeit zu bestätigen, dass die gesendete Anfrage und Antwort mit der empfangenen Anfrage und Antwort identisch sind. Der Dateiinhalt wurde möglicherweise während der Übertragung in einen anderen Inhalt geändert. In diesem Fall wird ein Angriff, bei dem die Anfrage oder Antwort während der Übertragung von einem Angreifer abgefangen und der Inhalt manipuliert wird, als Man-in-the-Middle-Angriff (MITM) bezeichnet ).

Lösung: HTTP + Verschlüsselung + Authentifizierung + Integritätsschutz = HTTPS

Bei so vielen oben genannten Mängeln von HTTP müssen wir sie natürlich als Nächstes in HTTPS beheben Werfen wir einen Blick darauf, wie HTTPS die Sicherheit unserer Datenübertragung gewährleistet.

1. HTTPS ist eigentlich HTTP, das in einer SSL-Shell verpackt ist

HTTPS ist kein neues Protokoll auf der Anwendungsebene. Der Teil der HTTP-Kommunikationsschnittstelle wird durch die Protokolle SSL (Secure Socket Layer) und TLS (Transport Layer Security) ersetzt.
Normalerweise kommuniziert HTTP direkt mit TCP. Bei der Verwendung von SSL wird zunächst mit SSL kommuniziert, und dann kommuniziert SSL mit TCP. Einfach ausgedrückt wird HTTP, das in Kombination mit SSL verwendet wird, HTTPS (HTTP Secure, Hypertext Transfer Security Protocol) oder HTTP über SSL genannt.
Nach der Einführung von SSL verfügt HTTP über die Verschlüsselungs-, Zertifikats- und Integritätsschutzfunktionen von HTTPS. SSL ist ein von HTTP unabhängiges Protokoll, sodass nicht nur das HTTP-Protokoll, sondern auch andere Protokolle wie SMTP und Telnet, die auf der Anwendungsebene ausgeführt werden, mit dem SSL-Protokoll verwendet werden können. Man kann sagen, dass SSL heute die weltweit am weitesten verbreitete Netzwerksicherheitstechnologie ist.

Verschlüsselungsprinzip von HTTPS

In modernen Verschlüsselungsalgorithmen ist der Verschlüsselungsalgorithmus öffentlich, und der Der Verschlüsselungsalgorithmus ist öffentlich. Der Schlüssel wird geheim gehalten. Dadurch bleibt die Sicherheit des Verschlüsselungsverfahrens erhalten.

Für die Verschlüsselung und Entschlüsselung ist ein Schlüssel erforderlich. Ohne den Schlüssel gibt es keine Möglichkeit, das Passwort zu entschlüsseln. Mit anderen Worten: Jeder, der den Schlüssel besitzt, kann den Chiffretext entschlüsseln.

HTTPS verwendet im Verschlüsselungsprozess asymmetrische Verschlüsselungstechnologie und symmetrische Verschlüsselungstechnologie.

Symmetrischer Verschlüsselungsalgorithmus

Verwendet die Verschlüsselungsmethode des Einzelschlüssel-Kryptographiesystems. Derselbe Schlüssel kann Informationen gleichzeitig verschlüsseln und entschlüsseln. Diese Verschlüsselungsmethode wird auch als symmetrische Verschlüsselung bezeichnet Einzelschlüsselverschlüsselung.

Der symmetrische Verschlüsselungsalgorithmus wird im Folgenden als Shared-Key-Verschlüsselungsalgorithmus bezeichnet.

Angenommen, SSL verwendet während des Kommunikationsprozesses einen symmetrischen Verschlüsselungsalgorithmus, was bedeutet, dass der Client und der Server gleichzeitig einen Schlüssel teilen.

Um mit einem gemeinsamen Schlüssel zu verschlüsseln, muss der Schlüssel an die andere Partei gesendet werden. Wenn zu diesem Zeitpunkt der Kommunikationsprozess überwacht wird und der Angreifer den Schlüssel erhält, geht die Bedeutung der Verschlüsselung zu diesem Zeitpunkt verloren.

Gibt es also eine Möglichkeit, dieses Problem zu lösen? Die Antwort lautet: Ja, das heißt, verwenden Sie zwei Schlüssel.

Sehen wir uns den asymmetrischen Verschlüsselungsalgorithmus mit zwei Schlüsseln an.

Asymmetrischer Verschlüsselungsalgorithmus

Im Gegensatz zum symmetrischen Verschlüsselungsalgorithmus erfordert der asymmetrische Verschlüsselungsalgorithmus zwei Schlüssel für die Verschlüsselung und Entschlüsselung, nämlich den öffentlichen Schlüssel und den öffentlichen Schlüssel (öffentlicher Schlüssel) und privater Schlüssel (privater Schlüssel).

Im Allgemeinen kann der öffentliche Schlüssel öffentlich gemacht werden und wird hauptsächlich zur Verschlüsselung von Klartext verwendet. Dementsprechend kann der private Schlüssel nicht öffentlich gemacht werden und wird zum Entschlüsseln des durch den öffentlichen Schlüssel verschlüsselten Chiffretextes verwendet.

Es ist zu beachten, dass der mit dem öffentlichen Schlüssel verschlüsselte Chiffretext nur mit dem entsprechenden privaten Schlüssel entschlüsselt werden kann, während der mit dem privaten Schlüssel verschlüsselte Chiffretext mit dem entsprechenden öffentlichen Schlüssel entschlüsselt werden kann.

Oben werden die Verschlüsselung mit öffentlichem Schlüssel und die Entschlüsselung mit privatem Schlüssel für die Verschlüsselung verwendet, und die Verschlüsselung mit privatem Schlüssel und die Entschlüsselung mit öffentlichem Schlüssel werden für die Signatur verwendet. Verwandte Verwendungen werden später besprochen.

Der asymmetrische Verschlüsselungsalgorithmus wird im Folgenden als Public-Key-Verschlüsselungsalgorithmus bezeichnet.

Angenommen, der Server generiert ein Paar aus öffentlichem Schlüssel und geheimem Schlüssel.

Wenn der Client zum ersten Mal eine Anfrage stellt und mit dem Server verhandelt, generiert der Server ein Paar aus öffentlichen und privaten Schlüsseln.

Dann sendet der Server den öffentlichen Schlüssel an den Client (Klartext, keine Verschlüsselung erforderlich). Nach dem Empfang generiert der Client zufällig einen Schlüssel und verwendet den vom Server gesendeten öffentlichen Schlüssel zur Verschlüsselung.

Dann sendet der Client den mit dem öffentlichen Schlüssel verschlüsselten Schlüssel an den Server. Nachdem der Server ihn empfangen hat, verwendet er den gepaarten privaten Schlüssel, um ihn zu entschlüsseln, und erhält den vom Client zufällig generierten Schlüssel.

Zu diesem Zeitpunkt sind die vom Client und vom Server gehaltenen Schlüssel identisch. An diesem Punkt ist der Schlüsselaustauschprozess abgeschlossen.

Dann kann die oben beschriebene Shared-Key-Verschlüsselungsmethode zum Verschlüsseln verwendet werden, wenn die Kommunikation beginnt.

Es ist möglich,

gleichzeitig zu verwenden. Einige Freunde werden fragen, warum wir uns die Mühe machen sollten, asymmetrische Verschlüsselung zu verwenden und dann denselben Schlüssel für die verschlüsselte Kommunikation mit gemeinsamem Schlüssel zu erhalten. Wollstoff?

Da die Verschlüsselung mit öffentlichen Schlüsseln komplexer zu verarbeiten ist als die Verschlüsselung mit gemeinsamen Schlüsseln, ist die Effizienz der Verwendung der Verschlüsselung mit öffentlichen Schlüsseln während der Kommunikation sehr gering.

Wir müssen also eine asymmetrische Verschlüsselung verwenden, um die Sicherheit des Schlüssels während des Schlüsselaustauschprozesses zu gewährleisten, und dann den symmetrischen Verschlüsselungsalgorithmus während des Kommunikationsprozesses verwenden. Dies ist die vernünftigste Entwurfsmethode bei gleichzeitiger Sicherstellung der Leistung.

Daher verwendet HTTPS einen hybriden Verschlüsselungsmechanismus, der sowohl Shared-Key-Verschlüsselung als auch Public-Key-Verschlüsselung verwendet. In der Phase des Schlüsselaustauschs wird die Verschlüsselung mit öffentlichen Schlüsseln verwendet, und in der anschließenden Phase des Austauschs von Kommunikationsnachrichten wird die Verschlüsselung mit gemeinsamen Schlüsseln verwendet.

Das Obige ist wahrscheinlich der Prozess der Verwendung von symmetrischer und asymmetrischer Verschlüsselung. Der Prozess scheint perfekt zu sein, aber es gibt immer noch ein Problem: Wie kann die Richtigkeit des vom Server übergebenen öffentlichen Schlüssels sichergestellt werden? Mit anderen Worten: Es soll sichergestellt werden, dass es nicht abgefangen und manipuliert werden kann.

Verwenden Sie Zertifikate, um die Richtigkeit des öffentlichen Schlüssels sicherzustellen

Wenn Sie sich jetzt darauf vorbereiten, eine Verschlüsselungskommunikation mit einem öffentlichen Schlüssel mit einem Server einzurichten, wie können Sie nachweisen, dass der Client ihn erhalten hat? Ist der öffentliche Schlüssel der vom Server ausgegebene öffentliche Schlüssel, wie ursprünglich erwartet? Möglicherweise wurde bei der Übermittlung des öffentlichen Schlüssels der echte öffentliche Schlüssel vom Angreifer ausgetauscht.

Um dieses Problem zu lösen, können Sie öffentliche Schlüsselzertifikate verwenden, die von Behörden für digitale Zertifikate und den damit verbundenen Behörden ausgestellt wurden.

Im Folgenden wird der Geschäftsprozess der Zertifizierungsstelle (CA) für digitale Zertifikate beschrieben:

Zuerst beantragt der Serverbetreiber einen öffentlichen Schlüssel bei der Zertifizierungsstelle für digitale Zertifikate. Nachdem die Zertifizierungsstelle für digitale Zertifikate die Identität des Antragstellers ermittelt hat, signiert sie den angewendeten öffentlichen Schlüssel digital, verteilt dann den signierten öffentlichen Schlüssel, fügt den öffentlichen Schlüssel in das Zertifikat des öffentlichen Schlüssels ein und bindet ihn an Together.

Übersetzen wir den obigen Absatz in die Landessprache:
Zuerst stellt die Zertifizierungsstelle dem Antragsteller ein Zertifikat aus. Der Inhalt dieses Zertifikats umfasst: den Aussteller, den Zweck des Zertifikats und was darin enthalten ist die Serveranwendung, der Serververschlüsselungsalgorithmus, der verwendete HASH-Algorithmus, die Ablaufzeit des Zertifikats usw.
Führen Sie als Nächstes eine HASH-Auswertung des oben genannten Inhalts durch, um einen HASH-Wert zu erhalten.

Anschließend verschlüsseln Sie mit dem privaten Schlüssel der Zertifizierungsstelle und vervollständigen so die digitale Signatur. Nach der Verschlüsselung mit dem privaten Schlüssel der Zertifizierungsstelle wird eine Signatur generiert, die einem menschlichen Fingerabdruck ähnelt. Jeder Versuch, das Zertifikat zu manipulieren, wird durch die digitale Signatur erkannt.
Zuletzt fügen Sie die digitale Signatur am Ende des digitalen Zertifikats hinzu und übertragen Sie es zurück an den Server.
Als nächstes sendet der Server das von der Zertifizierungsstelle für digitale Zertifikate ausgestellte öffentliche Schlüsselzertifikat an den Client. Zu diesem Zeitpunkt kann der Client den öffentlichen Schlüssel der digitalen Zertifizierungsstelle zur Überprüfung verwenden. Nach erfolgreicher Verifizierung kann der Kunde sicher sein, dass der öffentliche Schlüssel vertrauenswürdig ist.

Übersetzen wir es in die Landessprache:
Nachdem der Client dieses digitale Zertifikat erhalten hat, kann er den öffentlichen Schlüssel, der dem privaten CA-Schlüssel entspricht, verwenden, um die digitale Signatur am Ende des digitalen Zertifikats zu entschlüsseln und das zu erhalten ursprünglicher HASH-Wert.
Als nächstes berechnet der Client den HASH-Wert für den Inhalt des Zertifikats gemäß dem HASH-Algorithmus im Zertifikat. Wenn der durch den öffentlichen CA-Schlüssel entschlüsselte HASH-Wert mit dem durch Berechnung erhaltenen HASH-Wert übereinstimmt, ist die Authentifizierung erfolgreich, andernfalls schlägt sie fehl.
Wenn die Authentifizierung erfolgreich ist, können Sie den öffentlichen Schlüssel des Servers erhalten.

Woher kommt der öffentliche CA-Schlüssel auf dem Client?
Wenn die meisten Browserentwickler Versionen veröffentlichen, werden sie die öffentlichen Schlüssel häufig verwendeter Zertifizierungsstellen im Voraus intern implantieren. Auf diese Weise kann der Kunde bequem die Authentizität des digitalen Zertifikats überprüfen.

Der spezifische Prozess ist wie folgt (der Prozess der digitalen Signatur ist im Bild vereinfacht dargestellt):

Es wird tatsächlich verwendet hier Asymmetrischer Verschlüsselungsalgorithmus, außer dass dieser Verschlüsselungsalgorithmus jetzt für die Signatur anstelle der Verschlüsselung verwendet wird.

Mithilfe der Verschlüsselung mit privatem Schlüssel und der Entschlüsselung mit öffentlichem Schlüssel wird der Inhaber des öffentlichen Schlüssels verwendet, um zu überprüfen, ob der mit dem privaten Schlüssel verschlüsselte Inhalt manipuliert wurde. Er wird jedoch nicht verwendet, um sicherzustellen, dass der Inhalt manipuliert wurde von anderen erhalten.

Die Verwendung der Verschlüsselung mit öffentlichem Schlüssel und der Entschlüsselung mit privatem Schlüssel ist das Gegenteil. Sie garantiert nicht, dass die Informationen von anderen abgefangen und manipuliert werden, aber sie garantiert, dass die Informationen nicht von einem Vermittler erhalten werden können.

Client-Zertifikat

In HTTPS können nicht nur Serverzertifikate, sondern auch Client-Zertifikate verwendet werden. Verwenden Sie das Client-Zertifikat für die Client-Authentifizierung, das dieselbe Funktion wie das Server-Zertifikat hat.

Da der Client das Client-Zertifikat installieren muss, um das Zertifikat zu erhalten, steht er auch vor dem Kostenproblem.

Daher ist die aktuelle Situation so, dass Zertifizierungsstellen mit extrem hohen Sicherheitsanforderungen Client-Zertifikate erhalten können, jedoch nur für spezielle Dienste. Zum Beispiel Unternehmen, die die Kosten für Kundenzertifikate übernehmen können.

Zum Beispiel nutzt das Online-Banking der Bank Kundenzertifikate. Bei der Anmeldung zum Online-Banking muss der Nutzer nicht nur die Eingabe von Benutzerkennung und Passwort bestätigen, sondern es wird auch das Kundenzertifikat des Nutzers benötigt, um zu bestätigen, ob der Nutzer von einem bestimmten Endgerät aus auf das Online-Banking zugreift.

Sicherer Kommunikationsmechanismus von HTTPS

Um HTTPS besser zu verstehen, hat Xiaosi das folgende Diagramm gezeichnet, damit jeder die Kommunikationsschritte von HTTPS beobachten kann:

Schritt 1: Die Der Client startet die SSL-Kommunikation, indem er eine Client-Hello-Nachricht sendet. Die Nachricht enthält die angegebene vom Client unterstützte SSL-Version und eine Liste der Verschlüsselungskomponenten (verwendeter Verschlüsselungsalgorithmus, Schlüssellänge usw.).

Schritt 2: Wenn der Server SSL-Kommunikation durchführen kann, antwortet er mit einer Server-Hallo-Nachricht. Wie beim Client sind auch die SSL-Version und die Verschlüsselungskomponenten in der Nachricht enthalten. Der Inhalt der kryptografischen Komponente des Servers wird aus der kryptografischen Komponente des empfangenen Clients herausgefiltert.

Schritt 3: Der Server sendet dann die Zertifikatsnachricht. Die Nachricht enthält ein Public-Key-Zertifikat.

Schritt 4: Abschließend sendet der Server eine Server-Hello-Done-Nachricht, um den Client darüber zu informieren, dass die Anfangsphase der SSL-Handshake-Aushandlung beendet ist.

Schritt 5: Nachdem der erste SSL-Handshake abgeschlossen ist, antwortet der Client mit einer Client Key Exchange-Nachricht. Die Nachricht enthält eine zufällige Passwortzeichenfolge namens Pre-Master-Geheimnis, die bei der Kommunikationsverschlüsselung verwendet wird. Die Nachricht wurde mit dem öffentlichen Schlüssel aus Schritt 3 verschlüsselt.

Schritt 6: Der Client sendet dann weiterhin Nachrichten zum Ändern der Verschlüsselungsspezifikation. Diese Nachricht weist den Server darauf hin, dass die Kommunikation nach dieser Nachricht mit dem geheimen Pre-Master-Schlüssel verschlüsselt wird.

Schritt 7: Der Client sendet eine Fertig-Nachricht. Diese Nachricht enthält den Gesamtvalidierungswert aller bisher verbundenen Nachrichten. Ob diese Handshake-Aushandlung erfolgreich sein kann, hängt davon ab, ob der Server die Nachricht korrekt entschlüsseln kann.

Schritt 8: Der Server sendet außerdem eine Nachricht „Cipher Spec ändern“.

Schritt 9: Der Server sendet außerdem eine Fertig-Nachricht.

Schritt 10: Nach dem Austausch der fertigen Nachrichten zwischen dem Server und dem Client wird die SSL-Verbindung hergestellt. Selbstverständlich wird die Kommunikation durch SSL geschützt. Von hier aus beginnt die Kommunikation mit dem Protokoll der Anwendungsschicht, also das Senden von HTTP-Anfragen.

Schritt 11: Protokollkommunikation auf Anwendungsebene, d. h. Senden einer HTTP-Antwort.

Schritt 12: Schließlich trennt der Client die Verbindung. Beim Trennen der Verbindung wird eine close_notify-Nachricht gesendet. In der obigen Abbildung wurden einige Auslassungen gemacht. Nach diesem Schritt wird eine TCP-FIN-Nachricht gesendet, um die Kommunikation mit TCP zu schließen.

Wenn die Anwendungsschicht im obigen Prozess Daten sendet, hängt sie einen Nachrichtenauszug namens MAC (Message Authentication Code) an. MAC kann erkennen, ob eine Nachricht manipuliert wurde, und so die Integrität der Nachricht schützen.

Nun stellt sich die Frage: Welchen Nutzen haben die drei im gesamten Prozess generierten Zufallszahlen? Außerdem erfahren Sie bei der späteren HTTP-Kommunikation, welcher Schlüssel zur Verschlüsselung verwendet wird und wie die Integrität der Nachricht sichergestellt werden kann.

Sehen Sie sich das Bild unten an.

Für den Kunden:

Nachdem das Pre-Master-Geheimnis generiert wurde, werden die ursprünglichen A- und B-Zufallszahlen kombiniert Verwenden Sie den DH-Algorithmus, um ein Master-Geheimnis zu berechnen, und leiten Sie dann das Hash-Geheimnis und das Sitzungsgeheimnis basierend auf diesem Master-Geheimnis ab.

Für den Server:

Nach der Entschlüsselung und dem Erhalt des Pre-Master-Geheimnisses werden die ursprünglichen A- und B-Zufallszahlen kombiniert und mithilfe des DH-Algorithmus ein Master-Geheimnis berechnet und dann verwendet Dies Das Hauptgeheimnis leitet das Hash-Geheimnis und das Sitzungsgeheimnis ab.

Das Hauptgeheimnis auf dem Client und dem Server wird auf der Grundlage von drei Zufallszahlen abgeleitet. Es wird nicht im Netzwerk übertragen, und kein Dritter wird es erfahren. Gleichzeitig stimmen das vom Client abgeleitete Sitzungsgeheimnis und das Hash-Geheimnis genau mit denen des Servers überein.

Wenn also die beiden Parteien beginnen, für die Kommunikation einen symmetrischen Verschlüsselungsalgorithmus zu verwenden, welcher wird dann als gemeinsamer Schlüssel verwendet? Der Prozess ist wie folgt:

Beide Parteien verwenden einen symmetrischen Verschlüsselungsalgorithmus zum Verschlüsseln, führen mithilfe des Hash-Geheimnisses eine Operation an der HTTP-Nachricht durch, um einen MAC zu generieren, hängen ihn an das Ende der HTTP-Nachricht an und fügen dann Verwenden Sie das Sitzungsgeheimnis, um alle Daten zu verschlüsseln (HTTP+MAC), und senden Sie es dann.

Der Empfänger verwendet zuerst das Sitzungsgeheimnis, um die Daten zu entschlüsseln, ruft dann HTTP+MAC ab und verwendet dann denselben Algorithmus, um seinen eigenen MAC zu berechnen. Wenn die beiden MACs gleich sind, beweist dies, dass die Daten nicht gleich sind manipuliert wurde.

Zu diesem Zeitpunkt wurde der gesamte Prozess eingeführt.

Das obige ist der detaillierte Inhalt vonWie gewährleistet HTTPS die Websicherheit? (Codebeispiel). Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!