Wenn Sie jemals eine HTTPS-URL über einen Browser aufgerufen haben, haben Sie den SSL-Handshake erlebt. Auch wenn Sie es vielleicht nicht bemerken, bauen der Browser und die Website eine HTTPS-Verbindung mit einem einseitigen SSL-Handshake auf.
Der Hauptzweck eines SSL-Handshakes besteht darin, die Vertraulichkeit und Datenintegrität der Kommunikation zwischen einem Server und einem Client zu gewährleisten. Während des Handshakes tauschen Server und Client wichtige Informationen aus, die für den Aufbau einer sicheren Verbindung erforderlich sind.
Es gibt zwei Arten von SSL-Handshakes, die als One-Way-SSL und Two-Way-SSL (Mutual SSL) bezeichnet werden. Der Unterschied zwischen diesen beiden besteht darin, dass bei einseitigem SSL nur der Client die Identität des Servers validiert, während bei zweiseitigem SSL sowohl der Server als auch der Client die Identität des jeweils anderen validieren. Wenn wir auf einer HTTPS-Website surfen, wird normalerweise einseitiges SSL verwendet, bei dem nur unser Browser (Client) die Identität der Website (Server) überprüft. Zwei-Wege-SSL wird meist in der Server-zu-Server-Kommunikation verwendet, bei der beide Parteien die Identität des jeweils anderen überprüfen müssen.
Während eines SSL-Handshakes folgen der Server und der Client den folgenden Schritten.
1. Client Hello
Der Client sendet die Informationen, die der Server benötigt, um eine HTTPS-Verbindung zu starten.
In dem obigen Protokoll können wir sehen, dass der Client Hello mit TLS v1.2. Damit teilt der Client dem Server mit, dass er die TLS-Versionen 1.2 und darunter unterstützt. Die Liste der vom Client unterstützten Chiffren ist ebenfalls aus dem obigen Protokoll ersichtlich. Aus dieser Liste wählt der Server eine von ihm unterstützte Cipher Suite aus. Wenn die Liste Chiffriersuiten enthält, die der Server nicht kennt, unterstützt oder verwenden möchte, ignoriert der Server diese Chiffrierungen. Wenn keine unterstützten Cipher Suites gefunden werden, sendet der Server eine Fehlermeldung und schließt die Verbindung.
2. Server Hello
Der Server antwortet mit der Konfiguration, die er aus dem Client Hello ausgewählt hat, zusammen mit seinen Informationen, um mit dem Handshake fortzufahren. Server Hello“ sieht wie folgt aus:
Der Server wählt die TLS-Version aus, je nachdem, welche niedriger ist als die vom Client in der Client Hello“-Nachricht vorgeschlagene und die höchste vom Server unterstützte. Der Server sendet auch die Cipher-Suite zurück, die er aus der vom Client vorgelegten Liste der Cipher ausgewählt hat.
Zusammen mit der Server-Hallo-Nachricht sendet der Server auch das Zertifikat des Servers mit der Zertifikatskette. Die Zertifikatskette wird mit den Zertifikaten im Vertrauensspeicher des Clients abgeglichen.
3. Server Key Exchange Message
Diese Nachricht wird vom Server an den Client gesendet und enthält die erforderlichen Angaben, damit der Client das Pre-Master Secret generieren kann. Diese Nachricht wird nicht gesendet, wenn der RSA-Schlüsselaustauschalgorithmus (mehr dazu später) oder andere Schlüsselaustauschalgorithmen verwendet werden, die keine Informationen vom Server zur Erzeugung eines Pre-Master-Geheimnisses erfordern.
Beim Elliptic Curve Diffie Hellman(ECDH)-Schlüsselaustausch werden die folgenden Angaben zum öffentlichen ECDH-Schlüssel des Servers an den Client gesendet.
4. Zertifikatsanforderung
Hier unterscheidet sich Einweg-SSL von Zweiweg-SSL. Bei einseitigem SSL wird die Authentizität des Clients nicht überprüft. Daher entfällt dieser Schritt bei einseitigem SSL-Handshake.
In diesem Schritt sendet der Server eine Zertifikatsanforderung vom Client mit dem Zertifikatstyp, den Zertifikatsignaturalgorithmen und den vom Server unterstützten Zertifizierungsstellen. Es kann Situationen geben, in denen die Liste der Zertifizierungsstellen leer sein kann. In solchen Fällen kann der Client wählen, ob er das Client-Zertifikat senden oder nicht senden möchte (abhängig von der Client-Implementierung)
Schließlich sendet der Server die Nachricht Server Hello Done, die das Ende von Server Hello anzeigt. Nach dem Senden dieser Nachricht wartet der Server auf eine Antwort des Clients.
5. Client-Zertifikat
Der Client legt dem Server seine Zertifikatskette vor. Das Zertifikat muss für den ausgehandelten Schlüsselaustauschalgorithmus der Cipher-Suite und alle ausgehandelten Erweiterungen geeignet sein.
6. Client Key Exchange Message
Diese Nachricht muss vom Client im Anschluss an die Client Certificate Message gesendet werden. Wenn das Client-Zertifikat nicht vorgelegt wird (bei einseitigem SSL), sollte die Client-Schlüsselaustauschnachricht gesendet werden, nachdem der Client die ServerHelloDone-Nachricht erhalten hat.
Wie wir alle wissen, werden die zwischen dem Server und dem Client in einer HTTPS-Verbindung übertragenen Daten verschlüsselt. Zu diesem Zweck wird die symmetrische Verschlüsselung verwendet, da der Rechenaufwand wesentlich geringer ist als bei der asymmetrischen Verschlüsselung. Um die symmetrische Verschlüsselung zu verwenden, muss es einen gemeinsamen Schlüssel zwischen den beiden Enden geben. Der Zweck dieser Nachricht ist es, diesen gemeinsamen Schlüssel zwischen dem Client und dem Server zu generieren, ohne ihn einem Außenstehenden preiszugeben.
Es gibt zwei Client-Schlüsselaustauschmethoden, die in der TLS v1.2 Spezifikation beschrieben sind. Es sind RSA und Diffie-Hellman.
Wird RSA als Schlüsselaustauschalgorithmus verwendet, generiert der Client ein 48-Byte großes Pre-Master-Geheimnis. Der Client verschlüsselt das Pre-Master-Secret mit dem öffentlichen Schlüssel des Zertifikats und sendet es an den Server. Nur der Server verfügt über den entsprechenden privaten Schlüssel, um das vom Client erzeugte Pre-Master-Geheimnis zu entschlüsseln und zu erhalten.
Wenn Diffie-Hellman verwendet wird, werden die Diffie-Hellman-Parameter übertragen, damit sowohl der Client als auch der Server dasselbe Pre-Master-Geheimnis erzeugen können.
Danach erzeugen beide Seiten ein Master-Geheimnis unter Verwendung des Pre-Master-Geheimnisses, und das Master-Geheimnis wird zur Erzeugung des symmetrischen Schlüssels für die Verschlüsselung der Sitzungsdaten verwendet
7. Beendet
Nach erfolgreicher Authentifizierung und Generierung der Pre-Master-Secrets/Master-Secrets wird sowohl vom Client als auch vom Server eine Change-Cipher-Spec-Nachricht gesendet, die anzeigt, dass der Rest der Kommunikation verschlüsselt wird.
Die Finished-Nachricht folgt unmittelbar auf die Change-Cipher-Spec-Nachricht. Dies ist die erste Nachricht, die mit den ausgehandelten Algorithmen verschlüsselt wird. Anwendungsdaten werden erst dann übertragen, wenn beide Parteien die Fertigmeldung senden und den Inhalt der Meldung verifizieren.
https://tools.ietf.org/html/rfc5246
https://docs.microsoft.com/en-us/windows/desktop/secauthn/cipher-suites-in-schannel
https://www.websecurity.symantec.com/security-topics/what-is-ssl-tls-https
https://docs.apigee.com/api-platform/system-administration/keystores-and-truststores
https://wiki.openssl.org/index.php/Elliptic_Curve_Diffie_Hellman
https://www.globalsign.com/en/ssl-information-center/what-are-certification-authorities-trust-hierarchies/
https://www.geeksforgeeks.org/rsa-algorithm-cryptography/
https://www.acunetix.com/blog/articles/establishing-tls-ssl-connection-part-5/