Handshake Protocol

Kurz: Das TLS-Teilprotokoll, das den Verbindungsaufbau regelt: Aushandeln der Cipher Suite, Austausch der Zertifikate und Vereinbarung des Sitzungsschlüssels.

Genauer: Ablauf vereinfacht: Der Client schickt eine “ClientHello”-Nachricht mit unterstützten Cipher Suites und TLS-Versionen. Der Server antwortet mit “ServerHello” (gewählte Cipher Suite), seinem Zertifikat und ggf. weiteren Parametern. Anschließend wird über asymmetrische Kryptografie ein gemeinsamer Sitzungsschlüssel etabliert. Erst danach signalisieren beide Seiten über das Change Cipher Spec Protocol, dass ab jetzt verschlüsselt kommuniziert wird.

Im Detail

Der vollständige Handshake-Ablauf in TLS 1.3 (vereinfacht, moderner und schneller als TLS 1.2):

Client                                              Server
  |-- ClientHello (unterstützte Cipher Suites,
  |    vorab geschätzter Schlüsselaustausch) ------->|
  |<---- ServerHello (gewählte Cipher Suite,
  |       eigener Schlüsselanteil) ------------------|
  |<---- EncryptedExtensions, Zertifikat -------------|
  |<---- CertificateVerify (Server signiert
  |       den bisherigen Handshake-Verlauf) ----------|
  |<---- Finished -------------------------------------|
  |-- Finished ---------------------------------------->|
  |== ab hier: verschlüsselte Application Data ========|

Der größte Unterschied zu TLS 1.2: TLS 1.3 braucht nur noch einen einzigen Roundtrip (1-RTT) statt zwei, weil Client und Server ihre Schlüsselaustausch-Parameter bereits in ClientHello/ServerHello mitschicken, statt sie in separaten Nachrichten nachzuverhandeln — das spart eine komplette Netzwerk-Umlaufzeit und macht Verbindungsaufbauten spürbar schneller. Zusätzlich unterstützt TLS 1.3 “0-RTT” für wiederkehrende Verbindungen zu einem bereits bekannten Server: Der Client kann bereits mit der allerersten Nachricht verschlüsselte Daten mitschicken, allerdings mit dem Nachteil, dass diese ersten Daten anfällig für sogenannte Replay-Angriffe sind (ein Angreifer könnte die erste Nachricht aufzeichnen und erneut abspielen).

CertificateVerify ist der entscheidende Authentizitätsnachweis: Der Server signiert damit kryptografisch den gesamten bisherigen Handshake-Verlauf mit seinem privaten Schlüssel — der Client kann diese Signatur mit dem öffentlichen Schlüssel aus dem Server-Zertifikat prüfen und ist damit sicher, wirklich mit dem Inhaber des privaten Schlüssels zu sprechen, nicht mit einem Man-in-the-Middle.

Der Weg von TLS 1.2 zu TLS 1.3

TLS 1.2 (2008) benötigte für einen vollständigen Handshake noch zwei komplette Netzwerk-Roundtrips: Zunächst tauschten Client und Server ihre unterstützten Cipher Suites aus, ERST danach folgte in einem zweiten Roundtrip der eigentliche Schlüsselaustausch. TLS 1.3 (2018) verkürzte das drastisch, indem der Client bereits im allerersten ClientHello seine “beste Vermutung” für den Schlüsselaustausch mitschickt (typischerweise für die vom Server erfahrungsgemäß unterstützten Parameter) — trifft die Vermutung zu, reicht ein einziger Roundtrip. Bei falscher Vermutung fällt das Protokoll auf einen zusätzlichen HelloRetryRequest zurück, was praktisch aber selten vorkommt, da die gängigen Parameter-Kombinationen inzwischen weitgehend standardisiert sind.

Forward Secrecy als verpflichtender Bestandteil

Ein wichtiger Sicherheitsfortschritt in TLS 1.3: Perfect Forward Secrecy (über ephemere Diffie-Hellman-Schlüssel, siehe Cipher Suite) ist nicht mehr optional, sondern für JEDE Verbindung verpflichtend. Das bedeutet: Selbst wenn ein Angreifer irgendwann später den privaten Langzeitschlüssel eines Servers erbeutet, kann er damit keine in der Vergangenheit mitgeschnittenen, verschlüsselten Verbindungen nachträglich entschlüsseln — jede Sitzung nutzte einen eigenen, danach verworfenen temporären Schlüssel. Diese Eigenschaft gewann besonders nach den Snowden-Enthüllungen 2013 an Bedeutung, als bekannt wurde, dass Geheimdienste systematisch verschlüsselten Internetverkehr aufzeichneten, in der Hoffnung, ihn später mit erbeuteten Schlüsseln entschlüsseln zu können.

Session Resumption: schnellere Wiederverbindung

Für wiederkehrende Verbindungen zu einem bereits bekannten Server unterstützt TLS 1.3 “Session Resumption” über sogenannte Pre-Shared Keys (PSK): Statt den kompletten Handshake erneut durchzuführen, nutzt der Client einen vom vorherigen Besuch abgeleiteten Schlüssel, um die Verbindung deutlich schneller (teils mit nur einer einzigen Nachricht, siehe 0-RTT beim Application Data Protocol) wiederherzustellen — spürbar relevant für die Ladezeit von Websites, die häufig erneut besucht werden.

Häufige Handshake-Fehlerquellen in der Praxis

Typische Ursachen für gescheiterte Handshakes: Ein abgelaufenes oder für den falschen Hostnamen ausgestelltes Zertifikat, eine fehlende gemeinsame Cipher Suite (z. B. wenn ein alter Client nur veraltete, vom Server absichtlich nicht mehr angebotene Verfahren unterstützt), oder eine falsch konfigurierte Server-Uhrzeit (Zertifikatsgültigkeit wird zeitbasiert geprüft — eine stark abweichende Systemzeit kann gültige Zertifikate fälschlich als abgelaufen erscheinen lassen).

Siehe auch: Handshake, TLS Record Protocol, Change Cipher Spec Protocol