Was ist ein SSL/TLS-Handshake?
Ein SSL/TLS-Handshake ist eine Verhandlung zwischen zwei Parteien in einem Netzwerk – z. B. einem Browser und einem Webserver – um die Einzelheiten ihrer Verbindung festzulegen. Dabei wird festgelegt, welche Version von SSL/TLS in der Sitzung verwendet wird, welche Cipher-Suite die Kommunikation verschlüsselt, der Server (und manchmal auch der Client) verifiziert und festgestellt, dass eine sichere Verbindung besteht, bevor Daten übertragen werden.
Dies alles geschieht zum Glück im Hintergrund – jedes Mal, wenn Sie Ihren Browser auf eine sichere Website leiten, findet eine komplexe Interaktion statt, um sicherzustellen, dass Ihre Daten sicher sind.
Das ist die einfache Version. Sie werden feststellen, dass sich ein Dutzend Beschreibungen mehr oder weniger an dieses Format halten, sich aber im Detail auf Dutzende verschiedene Arten unterscheiden – manchmal auf verwirrende Weise. Lassen Sie uns ein Diagramm aufstellen, das ein grobes Modell der Funktionsweise eines TLS-Handshakes zeigt, ja?
JETZT BESTELLEN
Obligatorische SSL/TLS Handshake-Grafik
Alle SSL/TLS-bezogenen Sites haben ihre eigene Version eines Handshake-Diagramms – hier ist unsere! (Zum Vergrößern anklicken.)
Lassen Sie uns einige Unklarheiten beseitigen, wenn wir können
Eine gewisse Verwirrung darüber, wie SSL/TLS-Handshakes funktionieren, ist darauf zurückzuführen, dass der Handshake nur das Vorspiel zur eigentlichen, gesicherten Sitzung ist. Versuchen wir, einige allgemeine Punkte anzusprechen:
Asymmetrische vs. symmetrische Verschlüsselung
Der Handshake selbst verwendet asymmetrische Verschlüsselung – es werden zwei separate Schlüssel verwendet, ein öffentlicher und ein privater. Da asymmetrische Verschlüsselungssysteme einen viel höheren Overhead haben, sind sie nicht geeignet, um in der realen Welt Sicherheit zu bieten. Daher wird der öffentliche Schlüssel nur für die Verschlüsselung und der private Schlüssel nur für die Entschlüsselung während des Handshakes verwendet, was es den beiden Parteien ermöglicht, einen neu erstellten „gemeinsamen Schlüssel“ vertraulich einzurichten und auszutauschen. Die Sitzung selbst verwendet diesen einzigen gemeinsamen Schlüssel, um eine symmetrische Verschlüsselung durchzuführen, und das ist es, was eine sichere Verbindung in der Praxis möglich macht (der Overhead ist weitaus geringer). Die vollständige und korrekte Antwort auf die Frage „Ist die SSL/TLS-Verschlüsselung asymmetrisch oder symmetrisch?“ lautet also: „Erst das eine, dann das andere.“
Was ist eine „Cipher Suite“?
Der Handshake selbst besteht aus mehreren Phasen, die jeweils nach unterschiedlichen Regeln ablaufen. Die Einzelheiten können hier nachgelesen werden, aber der Kern ist, dass die Parteien statt einer Reihe von separaten Verhandlungen (darüber, welche Schlüssel zu verwenden sind, wie der Handshake selbst zu verschlüsseln ist, wie der Handshake zu authentifizieren ist usw.) vereinbaren können, eine „Chiffriersuite“ zu verwenden – eine bereits vorhandene Auswahl oder einen Satz von vereinbarten Komponenten. (Denken Sie daran, dass asymmetrische Verschlüsselung zeit- und ressourcenaufwändig ist – die Verwendung einer Cipher Suite als Abkürzung beschleunigt den Handshake selbst). Die TLS-Spezifikationen lassen eine ganze Reihe von Cipher-Suites zu, und Client und Server haben fast immer Zugang zu einer, die sie beide verwenden können.
Basic vs. Mutually-authenticated Handshake
Ein weiterer verwirrender Punkt ist, dass das oben beschriebene Basismodell dem Client erlaubt, den Server zu verifizieren, und die große Mehrheit der durch TLS gesicherten Sitzungen erfordert nur dies. Einige Cipher Suites erfordern jedoch, dass der Client auch ein Zertifikat und einen öffentlichen Schlüssel zur gegenseitigen Authentifizierung beider Parteien sendet. In einigen Fällen (z. B. wenn zwei Banken eine sichere Verbindung für Geldüberweisungen aushandeln) besteht die Chiffriersuite jedoch darauf, und die zusätzliche Sicherheit wird als lohnend erachtet.
Die verschiedenen Sitzungen haben unterschiedliche Sicherheitsparameter
Jeder neue Handshake erzeugt eine neue Sitzung, und die Einstellungen, die in einer Sitzung verwendet werden, können sich je nach gewählter Chiffriersuite drastisch von einer anderen unterscheiden. Dies ist einer der Gründe, warum es so viele verschiedene Iterationen dieses verflixten Handshake-Diagramms gibt, und warum wir hier einen ziemlich breiten Überblick geben. Sie sollten auch wissen, dass Sitzungen Parameter setzen können, die nicht genau das sind, was Sie erwarten. Je nach Chiffriersuite können einige Schritte hinzukommen (z. B. die Anforderung der zweiseitigen Authentifizierung) oder fehlen. Es gibt sogar Cipher Suites, die eine Sitzung ohne jegliche Verschlüsselung aushandeln. (Ja, wir wissen, dass eine HTTPS-Verbindung über Port 443, die beschließt, Daten unverschlüsselt zu senden, auch für uns keinen Sinn ergibt. SSL.com empfiehlt Ihnen dringend, dies nicht zu tun – seien Sie sich nur bewusst, dass es im Bereich des Möglichen liegt.)