HTTPS (Hypertext Transfer Protocol over Secure Socket Layer, Hypertext Transfer Protocol basierend auf Secure Socket Layer) ist ein auf Sicherheit ausgerichteter HTTP-Kanal. Vereinfacht gesagt handelt es sich um eine sichere Version von HTTP. Das heißt, die SSL-Schicht wird zu HTTP hinzugefügt. Die Sicherheitsgrundlage von HTTPS ist SSL. Die Identität des Servers wird durch das SSL-Zertifikat überprüft und die Kommunikation zwischen dem Browser und dem Server wird verschlüsselt. Die verwendete Portnummer ist 443.
SSL und TLS
SSL: SSL (Secure Socket Layer) ist ein sicheres Übertragungsprotokoll, das von Netscape hauptsächlich für das Web entwickelt wurde. Dieses Protokoll wird im WEB häufig verwendet. Die Zertifikatauthentifizierung stellt sicher, dass die Kommunikationsdaten zwischen dem Client und dem Website-Server verschlüsselt und sicher sind.
Das SSL-Protokoll liegt zwischen dem TCP/IP-Protokoll und verschiedenen Protokollen der Anwendungsschicht und bietet Sicherheitsunterstützung für die Datenkommunikation. Das SSL-Protokoll kann in zwei Schichten unterteilt werden: SSL Record Protocol: Es basiert auf einem zuverlässigen Übertragungsprotokoll (z. B. TCP) und bietet Unterstützung für grundlegende Funktionen wie Datenkapselung, Komprimierung und Verschlüsselung für High-Level-Protokolle. SSL-Handshake-Protokoll: Es basiert auf dem SSL-Aufzeichnungsprotokoll und wird von den kommunizierenden Parteien verwendet, um Identitäten zu authentifizieren, Verschlüsselungsalgorithmen auszuhandeln und Verschlüsselungsschlüssel auszutauschen, bevor die eigentliche Datenübertragung beginnt.
TLS: TLS (Transport Layer Security, Transport Layer Security Protocol) wird verwendet, um Vertraulichkeit und Datenintegrität zwischen zwei Anwendungen sicherzustellen.
Als SSL zur Version 3 weiterentwickelt wurde, hatte es sich als sehr gutes sicheres Kommunikationsprotokoll erwiesen, daher benannte die Internet Engineering Group IETF es 1999 in TLS (Transport Layer Security) um, standardisierte es offiziell und die Versionsnummer wurde von 1.0 umbenannt. Zählen , also ist TLS1.0 eigentlich SSLv3.1. TLS 1.0 ist ein neues Protokoll, das von der IETF (Internet Engineering Task Force, Internet Engineering Task Force) entwickelt wurde. Es basiert auf der SSL 3.0-Protokollspezifikation und ist eine Folgeversion von SSL 3.0. Es kann als SSL 3.1 verstanden werden (kann sein). einfach verstanden als unterschiedliche Namen für dasselbe Ding in unterschiedlichen Stadien). Das Protokoll besteht aus zwei Schichten: TLS Record und TLS Handshake. Die untere Schicht ist das TLS-Record-Protokoll, das auf einem zuverlässigen Transportprotokoll (z. B. TCP) aufbaut. Das Hauptziel von TLS besteht darin, SSL sicherer zu machen und die Spezifikation des Protokolls präziser und vollständiger zu gestalten.
TLS hat drei Versionen entwickelt, nämlich 1.1 im Jahr 2006, 1.2 im Jahr 2008 und 1.3 im Jahr 2018. Jede neue Version folgt genau der Entwicklung der Kryptographie und dem aktuellen Status des Internets, verbessert kontinuierlich Sicherheit und Leistung und hat sich zu einem maßgeblichen Standard im Bereich der Informationssicherheit entwickelt.
Das derzeit am weitesten verbreitete TLS ist 1.2 und frühere Protokolle (TLS1.1/1.0, SSLv3/v2) galten als unsicher.
Warum HTTPS verwenden?
Das HTTPS-Protokoll dient hauptsächlich dazu, die Sicherheitsprobleme des HTTP-Protokolls zu lösen. Die Verwendung des HTTP-Protokolls für die Übertragung birgt die folgenden Risiken:
(1) Abhörrisiko, beispielsweise kann der Kommunikationsinhalt über die Kommunikationsverbindung abgerufen werden, wodurch der Benutzer gestohlen wird Konto.
(2) Manipulationsgefahr, wie z. B. das erzwungene Einfügen von Spam-Werbung, was zu einer visuellen Beeinträchtigung führt.
(3) Das Risiko von Identitätsdiebstahl, z. B. das Vorgeben der Identität einer anderen Person, um Einkäufe zu tätigen, führt dazu, dass Benutzer Geld verlieren.
HTTPS-Prinzip
HTTPS ergänzt SSL/TSL auf der Anwendungs- und Netzwerkebene. HTTP-Anfrage/-Antwort kann im Allgemeinen in sechs Schritte unterteilt werden: (1) Herstellen einer TCP-Verbindung; (2) Senden einer HTTP-Anfrage; (3) Der Server verarbeitet die Anfrage; (4) Gibt eine HTTP-Antwort zurück; (5) Gibt die frei TCP-Verbindung; (6) Der Browser analysiert die zurückgegebenen Ressourcen und Daten. Allerdings fügt HTTPS nach Abschluss des TCP-Verbindungsaufbaus einen SSL-Verbindungsaufbauprozess hinzu. Nach dem Aufbau einer sicheren Verbindung werden HTTP-Anfragen und andere Folgeangelegenheiten gesendet. Als nächstes konzentrieren wir uns auf den Prozess des Verbindungsaufbaus über SSL (hier TLS 1.2).
(1) Nachdem die TCP-Verbindung hergestellt wurde, sendet der Browser zunächst eine „Client Hello“-Nachricht, mit der der Server „begrüßt“ werden soll. Es enthält die Client-Versionsnummer, unterstützte Verschlüsselungssammlungen und einen Zufallszahlen-Klartext (Client Random) für die nachfolgende Generierung von Sitzungsschlüsseln .
(2) Nachdem der Server „Client Hello“ empfangen hat, gibt er eine „Server Hello“-Nachricht zurück. Überprüfen Sie die Versionsnummer, geben Sie eine Zufallszahl (Server Random) im Klartext ein und wählen Sie dann eine Verschlüsselungssuite aus der vom Client bereitgestellten Verschlüsselungssuite-Liste als Verschlüsselungssuite aus, die für diese Kommunikation verwendet wird (z. B. den ECDHE-Algorithmus). Gleichzeitig sendet der Server zum Nachweis seiner Identität auch das Zertifikat (Serverzertifikat) an den Client. Da der Server eine Verschlüsselungssuite ausgewählt hat, sendet er nach dem Zertifikat eine „Server Key Exchange“-Nachricht, die den öffentlichen Schlüssel (Serverparameter) zur Implementierung des Schlüsselaustauschalgorithmus sowie seine eigene Signaturauthentifizierung mit privatem Schlüssel enthält.
Darauf folgt die Meldung „Server Hello Done“, was bedeutet, dass die Begrüßung abgeschlossen ist. Damit ist der erste Nachrichten-Roundtrip (zwei TCP-Pakete) abgeschlossen und das Ergebnis ist, dass Client und Server drei Informationen im Klartext gemeinsam nutzen: Client Random, Server Random und Server Params.
(3) Nachdem der Browser das Zertifikat des Servers erhalten hat, beginnt er mit der Bestätigung der Authentizität des Zertifikats und verwendet den öffentlichen Schlüssel des Zertifikats, um die Signatur zu überprüfen. Nachdem die Identität des Servers bestätigt wurde, generiert der Browser einen öffentlichen Schlüssel (Client-Parameter) basierend auf der ausgewählten Verschlüsselungssuite und sendet ihn dann mithilfe der „Client Key Exchange“-Nachricht an den Server. Jetzt verfügen Browser und Server über die beiden Parameter des Schlüsselaustauschalgorithmus (Client-Parameter, Server-Parameter) und verwenden dann den Cipher-Suite-Algorithmus, um den „Pre-Master“ zu berechnen. Jetzt haben Browser und Server drei Zufallszahlen: Client Random, Server Random und Pre-Master. Wenn Sie diese drei als Rohmaterialien verwenden, können Sie den Hauptschlüssel generieren, der zum Verschlüsseln der Sitzung verwendet wird und „Master Secret“ genannt wird. Und weil der Hacker den „Pre-Master“ nicht bekommen kann, kann er auch nicht an den Master-Schlüssel kommen.
Warum brauchen wir drei Zufallszahlen: Client Random, Server Random und Pre-Master? Dies liegt hauptsächlich daran, dass das TLS-Protokoll der Zuverlässigkeit der Pseudozufallszahlen des Browsers oder Servers nicht vertraut. Um sicherzustellen, dass es wirklich „völlig zufällig“ und „unvorhersehbar“ ist, werden drei unzuverlässige Zufallszahlen gemischt, also „zufällig“. Das Niveau ist höher und die Sicherheit ist garantierter.
Mit dem Hauptschlüssel und dem daraus abgeleiteten Sitzungsgeheimnis ist der Handshake fast beendet. Der Browser sendet eine „Change Cipher Spec“-Nachricht und dann eine „Fertig“-Nachricht, um alle zuvor gesendeten Daten zu verarbeiten, zu verschlüsseln und vom Server überprüfen zu lassen.
(4) Nach Erhalt der Verifizierungsanforderung des Browsers führt der Server die gleichen Schritte aus und sendet die Meldungen „Change Cipher Spec“ bzw. „Fertig“.
(5) Nach Abschluss der oben genannten Vorgänge wird die TSL-Verbindung hergestellt und der nächste Schritt besteht darin, HTTP-Anforderungen und -Antworten verschlüsselt zu senden.
Warum Zertifikate verwenden?
Einfach ausgedrückt kann die Methode „Zertifikat + digitale Signatur“ sicherstellen, dass der Inhalt des Zertifikats nicht manipuliert wird, und „Man-in-the-Middle-Angriffe“ verhindert werden. Dies entspricht der Anweisung an den Browser, die Identität des Servers zu überprüfen , Einwegauthentifizierung.
Einwegauthentifizierung und bidirektionale Authentifizierung
Einwegauthentifizierung bedeutet, dass der Client den Server authentifizieren muss.
Die Prinzipien der bidirektionalen Authentifizierung und der einseitigen Authentifizierung sind im Grunde dieselben. Der Hauptunterschied besteht darin, dass zusätzlich zur Authentifizierung des Servers durch den Client auch der Server den Client authentifizieren muss. In welchen Szenarien müssen wir den Client verifizieren? Bei einigen Bankdienstleistungen verlangt die Bank beispielsweise, dass der Kunde das von ihm ausgestellte USB-Schutzschild in den Computer einsteckt oder eine Steuerung installiert. Dies ähnelt dem Konzept des Kundenzertifikats. Personen ohne dieses Zertifikat können die bereitgestellten Dienste nicht nutzen von der Bank.
Muss ich jedes Mal, wenn ich eine HTTPS-Anfrage stelle, einen Handshake auf der SSL/TLS-Ebene durchführen, um Schlüssel zu übertragen?
Es ist sehr zeitaufwändig, den Schlüsselübertragungsprozess für jede Anfrage zu durchlaufen. Wie erreicht man also nur eine Übertragung? Der Server verwaltet für jeden Browser eine Sitzungs-ID und übergibt diese während der TLS-Handshake-Phase an den Browser. Nachdem der Browser den Schlüssel generiert und an den Server übergeben hat, speichert der Server den Schlüssel unter der entsprechenden Sitzungs-ID. Danach speichert der Server den Schlüssel unter der entsprechenden Sitzungs-ID. Der Browser trägt bei jeder Anfrage die Sitzungs-ID, und der Server findet den entsprechenden Schlüssel basierend auf der Sitzungs-ID und führt Entschlüsselungs- und Verschlüsselungsvorgänge durch, sodass der Schlüssel nicht jedes Mal neu erstellt und übertragen werden muss.
Verwendet HTTPS symmetrische oder asymmetrische Verschlüsselung?
Um diese Frage zu beantworten, müssen wir die Prinzipien von HTTPS überprüfen. Siehe oben für HTTPS-Prinzipien.
Nachdem Sie das Prinzip von HTTPS eingeführt haben, können Sie wissen, dass HTTPS asymmetrische Verschlüsselung verwendet, um einen symmetrischen Schlüssel zu übertragen, sodass sowohl der Server als auch der Browser ihn kennen können. Beide Parteien verwenden dann diesen symmetrischen Schlüssel, um die gesendeten und empfangenen Daten zu ver- und entschlüsseln. Da der Übertragungsschlüssel K eine asymmetrische Verschlüsselung verwendet, ist er schwieriger zu knacken und sicherer. Die spezifischen Übertragungsdaten nutzen eine symmetrische Verschlüsselung, um die Übertragung zu beschleunigen. Beste aus beiden Welten.
Wie Cloud-Dienste HTTPS implementieren
Für Cloud-Dienste ist es nicht notwendig, HTTPS in jedem Microservice zu implementieren. Es gibt auch viele Artikel im Internet über die Implementierung von HTTPS für Spring Boot, was irreführend ist. Für Cloud-Dienste muss es nur am Diensteingang implementiert werden. Es gibt zwei gängige Implementierungsszenarien: eines ist statisches ressourcenorientiertes CDN und das andere ist serviceorientiertes LB. Natürlich können auch andere Situationen wie Firewalls einbezogen werden. Weitere Informationen finden Sie in diesen beiden WIKIs: Ein Artikel hilft Ihnen, die HTTPS-Konfiguration in Alibaba Cloud und die vollständige HTTPS-Lösung von Tencent Cloud zu verstehen .
Entwickler und Architekten müssen lediglich die Prinzipien von HTTPS verstehen. Wenn sie HTTPS implementieren müssen, implementieren sie die HTTPS-Konfiguration für die entsprechenden Komponenten gemäß dem vorhandenen Design. Diese Konfiguration basiert im Allgemeinen auf der Cloud-Plattform.
Nachteile von HTTPS
Das HTTPS-Protokoll weist die folgenden Mängel auf:
(1) Das HTTPS-Protokoll verfügt über mehrere Handshakes, was die Ladezeit der Seite um fast 50 % erhöht.
(2) Das Zwischenspeichern von HTTPS-Verbindungen ist nicht so effizient wie HTTP und erhöht den Datenaufwand und den Stromverbrauch.
(3) Die Beantragung eines SSL-Zertifikats kostet Geld, und je leistungsfähiger das Zertifikat ist, desto höher sind die Kosten.
(4) Die an SSL beteiligten Sicherheitsalgorithmen verbrauchen CPU-Ressourcen und eine große Menge Serverressourcen.
Der Unterschied zwischen HTTP und HTTPS
HTTP ist ein Hypertext-Übertragungsprotokoll und Informationen werden im Klartext übertragen, was Sicherheitsrisiken birgt. HTTPS behebt die Unsicherheitsmängel von HTTP und fügt das SSL/TLS-Sicherheitsprotokoll zwischen den TCP- und HTTP-Netzwerkschichten hinzu, sodass Nachrichten verschlüsselt und übertragen werden können.
Der Aufbau einer HTTP-Verbindung ist relativ einfach und die HTTP-Nachrichtenübertragung kann nach dem TCP-Drei-Wege-Handshake durchgeführt werden. Nach dem Drei-Wege-Handshake von TCP muss HTTPS noch den SSL/TLS-Handshake-Prozess durchführen, bevor es in die verschlüsselte Nachrichtenübertragung eintreten kann.
Die Portnummer von HTTP ist 80 und die Portnummer von HTTPS ist 443.
Das HTTPS-Protokoll erfordert die Beantragung eines digitalen Zertifikats bei einer CA (Zertifizierungsstelle), um sicherzustellen, dass die Identität des Servers vertrauenswürdig ist.
Referenz
https://blog.csdn.net/hguisu/article/details/8680808 HTTPS-Implementierungsprinzip
https://zhuanlan.zhihu.com/p/466239718 Interview-Grundlagen: 62 häufig gestellte Fragen in Computernetzwerken
https://zhuanlan .zhihu.com/p/27395037 Trockeninformationen zur HTTPS-Serie (1): Detaillierte Erläuterung der HTTPS-Prinzipien
https://www.zhihu.com/tardis/zm/art/72616216 Wie versteht man die HTTP- und HTTPS-Protokolle in zehn Minuten?
https://www.rfc-editor.org/rfc/rfc8446 TLS 1.3
https://developer.mozilla.org/zh-CN/docs/Web/Security/Transport_Layer_SecurityTransport Layer Securityhttps
://www.cnblogs.com /huansky /p/13977181.html HTTPS in einfachen Worten (ausführliche Version)
https://zhuanlan.zhihu.com/p/43789231 Verstehen Sie das Verschlüsselungsprinzip von HTTPS gründlich
https://zhuanlan.zhihu.com/p/96494976 Wissen Sie, Verwendet HTTPS symmetrische oder asymmetrische Verschlüsselung?
https://www.jianshu.com/p/918d9f517749 Symmetrische Verschlüsselung und asymmetrische Verschlüsselung in https
https://zhuanlan.zhihu.com/p/162082184 Symmetrisch oder asymmetrisch – was wird in https verwendet?
https://cloud.tencent.com/document/product/400/6813Tencent Cloud implementiert eine vollständige HTTPS-Lösung
https://help.aliyun.com/practice_detail/444367 Dieser Artikel hilft Ihnen, die HTTPS-Konfiguration in Alibaba Cloud zu verstehen