Was passiert bei einem TLS-Handshake? | SSL-Handshake

Was ist ein TLS-Handshake?

TLS ist ein Verschlüsselungs- und Authentifizierungsprotokoll, das zur Sicherung der Internetkommunikation entwickelt wurde. Ein TLS-Handshake ist der Prozess, der eine Kommunikationssitzung mit TLS-Verschlüsselung startet. Während eines TLS-Handshakes tauschen die beiden kommunizierenden Seiten Nachrichten aus, um sich gegenseitig zu bestätigen, sich gegenseitig zu verifizieren, die von ihnen verwendeten kryptographische Algorithmen festzulegen und Sitzungsschlüssel zu vereinbaren. TLS-Handshakes sind ein grundlegender Bestandteil der Funktionsweise von HTTPS.

TLS- vs. SSL-Handshakes

SSL oder Secure Sockets Layer war das ursprüngliche Sicherheitsprotokoll, das für HTTP entwickelt wurde. SSL wurde vor einiger Zeit durch TLS bzw. Transport Layer Security ersetzt. SSL-Handshakes heißen jetzt TLS-Handshakes, auch wenn der Begriff „SSL“ immer noch weit verbreitet ist.

Wann findet ein TLS-Handshake statt?

Ein TLS-Handshake erfolgt immer dann, wenn ein Nutzer per HTTPS eine Website ansteuert und der Browser beginnt, Abfragen an den Ursprungsserver zu senden. Zu einem TLS-Handshake kommt es auch bei sonstigem Informationsaustausch per HTTPS, etwa bei API-Aufrufen und DNS-Abfragen über HTTPS.

TLS-Handshakes finden statt, nachdem eine TCP-Verbindung über einen TCP-Handshake geöffnet wurde.

Was passiert während eines TLS-Handshakes?

Während eines TLS-Handshakes werden Client und Server gemeinsam:

• Bestimmen, welche TLS-Version (TLS 1.0, 1.2, 1.3 usw.) verwendet werden soll
• Entscheiden, welche Cipher Suites (siehe weiter unten) verwendet werden sollen
• Die Identität des Servers über seinen öffentlichen Schlüssel und die digitale Signatur der SSL-Zertifizierungsstelle authentifizieren
• Sitzungsschlüssel generieren, um nach Abschluss des Handshakes eine symmetrische Verschlüsselung einzusetzen

In welchen Schritten läuft ein TLS-Handshake ab?

Bei TLS-Handshakes handelt es sich um eine Reihe von Datagrammen oder Nachrichten, die von einem Client und einem Server ausgetauscht werden. Ein TLS-Handshake umfasst mehrere Etappen, da Client und Server Informationen austauschen müssen, um den Handshake abzuschließen und weitere Kommunikation ermöglichen zu können.

Die genauen Schritte innerhalb eines TLS-Handshakes hängen von der Art des verwendeten Schlüsselaustausch-Algorithmus und den von beiden Seiten unterstützten Cipher Suites ab. Der RSA-Schlüsselaustauschalgorithmus wurde in TLS-Versionen vor 1.3 verwendet. Heute gilt er als nicht sicher. Der Austausch läuft ungefähr folgendermaßen ab:

1. Die „Client Hello“-Nachricht: Der Client leitet den Handshake ein, indem er eine „Hello“-Nachricht an den Server sendet. Die Nachricht zeigt an, welche TLS-Version und welche Cipher Suites der Client unterstützt. Außerdem enthält sie eine Folge von zufälligen Bytes, die als „Client Random“ bezeichnet werden.
2. Die „Server Hello“-Nachricht: Als Antwort auf die „Client Hello“-Nachricht sendet der Server eine Nachricht, die das SSL-Zertifikat des Servers, die vom Server ausgewählte Verschlüsselungssuite und die „Server Random“ (eine vom Server generierte zufällige Byte-Zeichenfolge) enthält.
3. Authentifizierung: Der Client überprüft das SSL-Zertifikat des Servers bei der Zertifizierungsstelle, die es ausgestellt hat. Dieser Vorgang bestätigt, dass der Server der ist, der er vorgibt zu sein, und dass der Client mit dem tatsächlichen Eigentümer der Domain interagiert.
4. Das Premaster Secret: Der Client sendet eine weitere zufällige Folge von Bytes, das „Premaster Secret“. Das Premaster Secret wird mit dem öffentlichen Schlüssel verschlüsselt und kann vom Server nur mit dem privaten Schlüssel entschlüsselt werden. (Der Client erhält den öffentlichen Schlüssel vom SSL-Zertifikat des Servers.)
5. Privater Schlüssel wird verwendet: Der Server entschlüsselt das Premaster Secret.
6. Sitzungsschlüssel werden erstellt: Sowohl Client als auch Server generieren Sitzungsschlüssel aus dem Client Random, dem Server Random und dem Premaster Secret. Sie sollten zu den gleichen Ergebnissen kommen.
7. Client ist bereit: Der Client sendet eine „Fertig“-Nachricht, die mit einem Sitzungsschlüssel verschlüsselt ist.
8. Server ist bereit: Der Server sendet eine „Fertig“-Nachricht, die mit einem Sitzungsschlüssel verschlüsselt ist.
9. Sichere symmetrische Verschlüsselung erfolgreich: Der Handshake ist abgeschlossen und die Kommunikation wird mit den Sitzungsschlüsseln fortgesetzt.

Alle TLS-Handshakes verwenden eine asymmetrische Kryptographie (öffentlicher und privater Schlüssel), aber nicht alle nutzen den privaten Schlüssel beim Generieren von Sitzungsschlüsseln. Zum Beispiel läuft ein kurzlebiger Diffie-Hellman-Handshake wie folgt ab:

1. Client-Hallo: Der Client sendet eine Client-Hallo-Nachricht mit der Protokollversion, dem Client-Random und einer Liste von Cipher Suites.
2. Server Hello: Der Server antwortet mit seinem SSL-Zertifikat, seiner ausgewählten Cipher Suite und dem Server Random. Im Gegensatz zum oben beschriebenen RSA-Handshake enthält die Nachricht des Servers in diesem Fall auch Folgendes (Schritt 3):
3. Die digitale Signatur des Servers: Der Server berechnet eine digitale Signatur aller Nachrichten bis zu diesem Punkt.
4. Digitale Signatur bestätigt: Der Client verifiziert die digitale Signatur des Servers und bestätigt damit, dass der Server derjenige ist, der er vorgibt zu sein.
5. Client-DH-Parameter: Der Client sendet seinen DH-Parameter an den Server.
6. Client und Server berechnen Premaster Secret: Anstatt dass der Client das Premaster Secret generiert und wie bei einem RSA-Handshake an den Server sendet, verwenden Client und Server die von ihnen ausgetauschten DH-Parameter, um ein passendes Premaster Secret separat zu berechnen.
7. Sitzungsschlüssel werden erstellt: Nun berechnen Client und Server genau wie bei einem RSA-Handshake Sitzungsschlüssel aus dem Premaster Secret, dem Client Random und dem Server Random.
8. Client ist bereit: Wie bei einem RSA-Handshake.
9. Server ist bereit
10. Erfolgreiche sichere symmetrische Verschlüsselung

*DH-Parameter: DH steht für Diffie Hellman. Der Diffie-Hellman-Algorithmus verwendet Exponentialrechnungen, um zum gleichen Premaster Secret zu gelangen. Der Server und der Client stellen jeweils einen Parameter für die Berechnung bereit. In Kombination ergeben sie auf jeder Seite eine andere Berechnung mit gleichen Ergebnissen.

Weitere Informationen dazu, wie sich kurzlebige Diffie-Hellman-Handshakes und anderen Arten von Handshakes unterscheiden und wie sie „Forward Secrecy“ gewährleisten, finden Sie unter Was ist Keyless SSL?

Was ist bei einem Handshake in TLS 1.3 anders?

TLS 1.3 unterstützt weder RSA noch andere Cipher Suites und Parameter, die für Angriffe anfällig sind. Außerdem wird der TLS-Handshake verkürzt, wodurch ein TLS 1.3-Handshake sowohl schneller als auch sicherer wird.

Die grundlegenden Schritte eines TLS 1.3-Handshakes lauten:

• Client-Hallo: Der Client sendet eine Client-Hallo-Nachricht mit der Protokollversion, dem Client-Random und einer Liste von Cipher Suites. Da die Unterstützung für unsichere Cipher Suites aus TLS 1.3 entfernt wurde, sinkt die Anzahl der möglichen Cipher Suites beträchtlich. Das Client-Hello enthält auch die Parameter, die für die Berechnung des Premaster-Secrets verwendet werden. Im Wesentlichen geht der Client davon aus, dass er die bevorzugte Schlüsselaustauschmethode des Servers kennt (aufgrund der vereinfachten Liste der Cipher Suites tut er das wahrscheinlich). Dadurch wird die Gesamtlänge des Handshakes verkürzt – einer der wichtigsten Unterschiede zwischen TLS 1.3-Handshakes und TLS 1.0, 1.1 und 1.2-Handshakes.
• Server generiert Master-Secret: Zu diesem Zeitpunkt hat der Server den Client-Random sowie die Parameter und Cipher Suites des Clients erhalten. Er verfügt bereits über den Server-Random, da er diesen selbst generieren kann. Daher kann der Server das Master-Secret erstellen.
• Server-Hallo und „Finished“: Die Server-Hallo-Nachricht enthält das Zertifikat des Servers, die digitale Signatur, den Server-Random und die gewählte Cipher-Suite. Da er bereits über das Master-Secret verfügt, sendet er außerdem eine „Finished“-Nachricht.
• Letzte Schritte und „Finished“ des Clients: Der Client verifiziert die Signatur und das Zertifikat, generiert das Master-Secret und sendet die Nachricht „Finished“.
• Erfolgreiche sichere symmetrische Verschlüsselung

0-RTT-Modus für die Wiederaufnahme der Sitzung

TLS 1.3 unterstützt auch eine noch schnellere Version des TLS-Handshakes, die keine Roundtrips oder Hin- und Her-Kommunikation zwischen Client und Server erfordert. Wenn der Client und der Server schon einmal miteinander verbunden waren (z. B. wenn der Nutzer die Website schon einmal besucht hat), können beide ein weiteres gemeinsames Geheimnis aus der ersten Sitzung ableiten, das sogenannte „Resumption-Main-Secret“. Der Server sendet dem Client während dieser ersten Sitzung auch ein so genanntes Sitzungsticket. Der Client kann dieses gemeinsame Geheimnis verwenden, um mit der ersten Nachricht der nächsten Sitzung zusammen mit dem Sitzungsticket verschlüsselte Daten an den Server zu senden. Und TLS wird zwischen Client und Server wieder aufgenommen.

Was ist eine Cipher Suite?

Eine Chiffriersuite ist ein Satz von Algorithmen, die für den Aufbau einer sicheren Kommunikationsverbindung verwendet werden. Es gibt eine Reihe gängiger Chiffriersuiten und ein wesentlicher Teil des TLS-Handshakes besteht darin, zu vereinbaren, welche Chiffriersuite für diesen Handshake verwendet werden soll.

Weitere Informationen zu TLS/SSL finden Sie unter Wie funktioniert SSL?