Was ist ein TLS-Handshake?

Ein TLS-Handshake ist der Aushandlungsprozess, den ein Client und ein Server vor dem Austausch verschlüsselter Daten durchführen. Dabei einigen sie sich auf eine TLS-Version und eine Cipher Suite, überprüfen das Serverzertifikat und legen gemeinsame Sitzungsschlüssel fest.

Ein TLS-Handshake ist die Abfolge von Nachrichten, die Client und Server austauschen, um eine sichere Verbindung herzustellen. Dabei werden die TLS-Version und die Verschlüsselungssuite ausgehandelt, der Server (und optional der Client) mithilfe eines X.509-Zertifikats authentifiziert und gemeinsame Sitzungsschlüssel abgeleitet – alles bevor Anwendungsdaten gesendet werden.

Wichtige Erkenntnisse

• TLS 1.3, definiert in RFC 8446, reduzierte den Handshake von zwei Roundtrips in TLS 1.2 auf einen einzigen Roundtrip und halbierte damit die Latenz beim Verbindungsaufbau annähernd.
• Die Hauptaufgabe des Handshakes ist dreifach: Einigung auf kryptografische Parameter, Authentifizierung des Servers über sein Zertifikat und Ableitung von Sitzungsschlüsseln durch einen Schlüsselaustausch, meist ECDHE.
• Mutual TLS (mTLS) erweitert den Standard-Handshake, indem es auch vom Client die Vorlage eines Zertifikats verlangt, um beide Seiten der Verbindung zu authentifizieren.
• Mit TLS 1.3 wurde die Unterstützung für den statischen RSA-Schlüsselaustausch und ältere Verschlüsselungsverfahren entfernt, wodurch Forward Secrecy (mittels ephemerem Diffie-Hellman) obligatorisch statt optional wurde.
• Ein Handshake schlägt sofort fehl, wenn das Serverzertifikat abgelaufen ist, vom Client nicht als vertrauenswürdig eingestuft wird oder nicht mit dem angeforderten Domänennamen übereinstimmt (SNI-Mismatch).

Was geschieht während eines TLS 1.3-Handshakes, Schritt für Schritt?

1. ClientHello: Der Client sendet die von ihm unterstützten TLS-Versionen und Verschlüsselungssammlungen sowie einen Zufallswert und einen vorläufigen Schlüsselaustausch.
2. ServerHello: Der Server wählt einen TLS-Version und wählt eine Verschlüsselungssuite aus der Liste des Clients aus und sendet seinen eigenen Schlüsselanteil.
3. Zertifikat: Der Server sendet seine X.509-Zertifikatskette, damit der Client seine Identität anhand einer vertrauenswürdigen Zertifizierungsstelle überprüfen kann.
4. CertificateVerify: Der Server beweist, dass er den zu seinem Zertifikat passenden privaten Schlüssel besitzt, indem er das bisherige Handshake-Protokoll signiert.
5. Fertig: Beide Seiten berechnen die Sitzungsschlüssel aus den ausgetauschten Schlüsselanteilen und bestätigen den Handshake mit einem MAC über das Protokoll.
6. Anwendungsdaten: Verschlüsselte Daten fließen nun unter Verwendung der ausgehandelten Sitzungsschlüssel, und zwar alles innerhalb eines einzigen Roundtrips von der ersten Nachricht des Clients an.

Worin unterscheidet sich TLS 1.3 von TLS 1.2?

Aspekt	TLS 1.2	TLS 1.3
Hin- und Rückreisen zum vollständigen Handschlag	2	1 (0 bei Wiederaufnahme der Sitzung)
Statischer RSA-Schlüsselaustausch	Unterstützt	Entfernt
Vorwärtsgeheimnis	Optional	Obligatorisch (ephemeres Diffie-Hellman)
Verhandlung der Verschlüsselungssuite	Umfassend, beinhaltet auch schwächere Verschlüsselungsverfahren	Beschränkt auf eine kleine, moderne Menge (z. B. AES-GCM, ChaCha20)

Was ist ein TLS-Handshake-Fehler und wodurch wird er verursacht?

Ein fehlgeschlagener Handshake bedeutet, dass Client und Server sich nicht auf die Parameter einigen konnten oder die Identität des jeweils anderen nicht bestätigen konnten, sodass keine sichere Sitzung hergestellt werden konnte.

• Zertifikat abgelaufen oder noch nicht gültig: Der Client lehnt ein Zertifikat ab, das außerhalb seines Gültigkeitszeitraums liegt.
• Nicht vertrauenswürdiger Aussteller: Die Zertifikatskette führt zu einem CA nicht im Truststore des Clients vorhanden.
• Hostname-Konflikt: Der alternative Subjektname des Zertifikats stimmt nicht mit der Domäne überein, die der Client über SNI (Server Name Indication) angefordert hat.
• Verschlüsselungssuite Konflikt: Client und Server verwenden keine gemeinsame, gegenseitig unterstützte Verschlüsselungssuite.

Wie verändert Mutual TLS den Handshake?

Mutual TLS (mTLS) fügt eine CertificateRequest-Nachricht vom Server und ein passendes Certificate- und CertificateVerify-Paar vom Client hinzu, sodass sich beide Seiten mit einem X.509-Zertifikat authentifizieren, anstatt nur der Server. Dies ist üblich in API-zu-API-, Service-Mesh- und Zero-Trust- Architekturen, in denen beide Endpunkte ihre Identität vor dem Datenaustausch nachweisen müssen.

Wie Verschlüsselungsberatung hilft

Wie Verschlüsselungsberatung hilft: CertSecure Manager stellt die für jeden Handshake benötigten TLS-Server- und Clientzertifikate aus und automatisiert deren Erneuerung. So wird verhindert, dass abgelaufene oder falsch konfigurierte Zertifikate zu Verbindungsabbrüchen führen. Die Lösung basiert auf ISO/IEC 27001:2022- und SOC 2-zertifizierten Verfahren.

Häufig gestellte Fragen

Wie lange dauert ein TLS-Handshake?

Bei TLS 1.3 wird ein vollständiger Handshake zwischen Client und Server in einem einzigen Roundtrip abgeschlossen, und eine fortgesetzte Sitzung kann ohne weitere Roundtrips hergestellt werden. TLS 1.2 benötigte zwei Roundtrips, wodurch TLS 1.3 eine deutlich schnellere Verbindungsherstellung ermöglicht.

Worin besteht der Unterschied zwischen einem TLS-Handshake und einem SSL-Handshake?

SSL ist der veraltete Vorgänger von TLS; die letzte SSL-Version, SSL 3.0, wurde aufgrund von Sicherheitslücken offiziell als veraltet eingestuft. Der Handshake-Prozess ist im Prinzip derselbe, aber „TLS-Handshake“ ist die technisch korrekte Bezeichnung für jede moderne sichere Verbindung.

Warum schlägt ein TLS-Handshake aufgrund eines Zertifikatfehlers fehl?

Ein Handshake schlägt aufgrund eines Zertifikatfehlers fehl, wenn das Serverzertifikat abgelaufen ist, von einer Zertifizierungsstelle ausgestellt wurde, der der Client nicht vertraut, oder nicht mit dem angeforderten Domänennamen übereinstimmt. Der Client verweigert die Fortsetzung des Vorgangs, bis er die Identität des Servers verifizieren kann.

Was ist Server Name Indication (SNI) und warum ist es beim Handshake wichtig?

SNI ermöglicht es einem Client, während des ClientHello den Hostnamen anzugeben, zu dem er sich verbindet, bevor der Server das passende Zertifikat auswählt. Dadurch kann eine IP-Adresse mehrere TLS-gesicherte Domains hosten, jede mit ihrem eigenen Zertifikat.

Sorgen Sie für einen reibungslosen Ablauf jedes TLS-Handshakes

Gehen Sie den nächsten Schritt: CertSecure Manager automatisiert die Ausstellung, Verlängerung und Bereitstellung von Zertifikaten, sodass Ihre TLS-Handshakes niemals aufgrund eines abgelaufenen oder falsch konfigurierten Zertifikats fehlschlagen. Sehen Sie CertSecure Manager in Aktion.