Wie SSL/TLS funktioniert: Der TLS-Handshake erklärt

Jedes Mal, wenn Sie eine HTTPS-Website besuchen, führen Ihr Browser und der Server einen TLS-Handshake durch — einen schnellen Austausch, der den Server authentifiziert, Verschlüsselungsparameter vereinbart und einen gemeinsamen geheimen Schlüssel ableitet. Dies geschieht in 1–2 Netzwerk-Roundtrips (50–200 ms), bevor irgendein Seiteninhalt geladen wird.

Der TLS 1.3 Handshake (aktueller Standard)

TLS 1.3 schließt den Handshake in einem einzigen Roundtrip (1-RTT) ab:

Schritt 1 — Client Hello Ihr Browser sendet: unterstützte TLS-Versionen, unterstützte Cipher Suites, eine Zufallszahl und Key-Share-Parameter (für den Diffie-Hellman-Schlüsselaustausch).

Schritt 2 — Server Hello + Certificate + Finished Der Server antwortet mit: gewählter Cipher Suite, seinem Zertifikat (als Identitätsnachweis), seinem Key Share und einer „Finished”-Nachricht. In TLS 1.3 ist das Zertifikat verschlüsselt — passive Beobachter können nicht sehen, mit welcher Website Sie sich verbinden.

Schritt 3 — Client Finished Der Browser überprüft das Zertifikat anhand seiner vertrauenswürdigen CA-Liste, berechnet den gemeinsamen Sitzungsschlüssel aus dem Diffie-Hellman-Austausch und sendet seine „Finished”-Nachricht. Verschlüsselte Anwendungsdaten können nun fließen.

Gesamt: 1 Roundtrip. Wiederaufgenommene Verbindungen (bei denen der Client zuvor bereits verbunden war) können 0-RTT verwenden — verschlüsselte Daten werden bereits mit der allerersten Nachricht gesendet.

TLS 1.2 Handshake (noch weit verbreitet)

TLS 1.2 erfordert 2 Roundtrips:

1. Client Hello → unterstützte Versionen, Cipher, Zufallszahl
2. Server Hello → gewählter Cipher, Zertifikat, Server Key Exchange
3. Client Key Exchange → Pre-Master Secret (verschlüsselt mit dem öffentlichen Schlüssel des Servers oder über Diffie-Hellman)
4. Change Cipher Spec + Finished (beide Seiten)

TLS 1.2 unterstützt mehr Cipher Suites — einschließlich einiger schwacher. Die richtige Konfiguration ist hier wichtiger als bei TLS 1.3.

Was innerhalb der verschlüsselten Verbindung passiert

Nach dem Handshake werden alle Daten mit dem ausgehandelten Sitzungsschlüssel unter Verwendung einer symmetrischen Verschlüsselung (typischerweise AES-256-GCM oder ChaCha20-Poly1305) verschlüsselt:

• Vertraulichkeit — Daten sind verschlüsselt; nur die beiden Endpunkte können sie lesen
• Integrität — jede Nachricht enthält einen MAC (Message Authentication Code); jede Manipulation wird erkannt
• Authentifizierung — das Zertifikat des Servers beweist seine Identität (und optional die des Clients)

Jede HTTP-Anfrage und -Antwort — Header, Body, Cookies, URLs — wird über diesen verschlüsselten Kanal übertragen.

Forward Secrecy

Modernes TLS verwendet einen ephemeren Diffie-Hellman-Schlüsselaustausch, was bedeutet, dass jede Verbindung einen einzigartigen Sitzungsschlüssel erzeugt. Selbst wenn der private Schlüssel des Servers später kompromittiert wird, können vergangene Kommunikationen nicht entschlüsselt werden.

TLS 1.3 macht Forward Secrecy verpflichtend. TLS 1.2 unterstützt es, erlaubt aber auch RSA-Schlüsselaustausch (der keine Forward Secrecy bietet). Deshalb wird TLS 1.3 bevorzugt.

Die Rolle des Zertifikats

Der TLS-Handshake setzt voraus, dass der Server ein gültiges SSL/TLS-Zertifikat besitzt. Das Zertifikat liefert:

1. Den öffentlichen Schlüssel des Servers — wird beim Schlüsselaustausch verwendet
2. Domainnamen — der Browser prüft, ob diese mit der URL übereinstimmen
3. CA-Signatur — beweist, dass eine vertrauenswürdige Zertifizierungsstelle für dieses Zertifikat bürgt
4. Gültigkeitsdaten — der Browser lehnt abgelaufene Zertifikate ab

Ohne ein gültiges Zertifikat schlägt der Handshake fehl und der Browser zeigt eine Sicherheitswarnung an. Kostenloses Zertifikat holen →

Leistung

Auf moderner Hardware ist der CPU-Aufwand für die Verschlüsselung vernachlässigbar — AES-NI-Instruktionen erledigen dies in Hardware. Die Hauptkosten sind die zusätzlichen Roundtrip(s), die TLS 1.3 minimiert.

Was auf der Leitung sichtbar ist

Ohne HTTPS (HTTP)

Ein Beobachter im Netzwerk sieht alles:

GET /login HTTP/1.1
Host: example.com
Cookie: session=abc123

username=admin&password=secret123

Benutzernamen, Passwörter, Cookies, Seiteninhalt — alles im Klartext.

Mit HTTPS (TLS)

Derselbe Beobachter sieht:

[TLS handshake — server certificate visible in TLS 1.2, encrypted in TLS 1.3]
[Encrypted application data — indistinguishable from random bytes]
[Encrypted application data]
[Encrypted application data]

Er kann die Ziel-IP-Adresse und den SNI-Hostnamen sehen (in TLS 1.2 — verschlüsselt in TLS 1.3 mit ECH). Er kann den URL-Pfad, die Header, den Body oder die Cookies nicht sehen.

Wie das Zertifikat hineinpasst

Der TLS-Handshake setzt voraus, dass der Server ein gültiges SSL/TLS-Zertifikat besitzt:

1. Den öffentlichen Schlüssel des Servers — wird beim Schlüsselaustausch verwendet
2. Domainnamen — der Browser prüft, ob diese mit der URL übereinstimmen
3. CA-Signatur — beweist, dass eine vertrauenswürdige Zertifizierungsstelle für dieses Zertifikat bürgt
4. Gültigkeitsdaten — der Browser lehnt abgelaufene Zertifikate ab

Ohne ein gültiges Zertifikat schlägt der Handshake fehl und der Browser zeigt eine Sicherheitswarnung an. Kostenloses Zertifikat holen →

Gängige TLS Cipher Suites in 2026

TLS 1.3 (nur 5 Cipher Suites — alle sicher)

TLS_AES_256_GCM_SHA384       ← Am häufigsten
TLS_AES_128_GCM_SHA256       ← Weit verbreitet
TLS_CHACHA20_POLY1305_SHA256 ← Optimal für Mobile/ARM
TLS_AES_128_CCM_SHA256       ← IoT/Embedded
TLS_AES_128_CCM_8_SHA256     ← IoT/Embedded (kurzer Tag)

TLS 1.2 (nur AEAD-Suites verwenden)

ECDHE-ECDSA-AES256-GCM-SHA384  ← Beste Wahl mit ECC-Zertifikat
ECDHE-RSA-AES256-GCM-SHA384    ← Beste Wahl mit RSA-Zertifikat
ECDHE-ECDSA-CHACHA20-POLY1305  ← Für Mobilgeräte optimiert

Vermeiden Sie Non-AEAD-Suites (CBC-Modus) in TLS 1.2 — sie waren anfällig für Angriffe wie BEAST und Lucky13.

Häufig gestellte Fragen

Verlangsamt HTTPS meine Website?

Der TLS-Handshake fügt bei der ersten Verbindung einen Roundtrip (TLS 1.3) oder zwei (TLS 1.2) hinzu. Sitzungswiederaufnahme eliminiert dies für wiederkehrende Besucher. Da HTTPS HTTP/2 ermöglicht (Multiplexing, Header-Komprimierung), sind HTTPS-Seiten insgesamt oft schneller.

Was ist eine Cipher Suite?

Eine Cipher Suite ist eine Kombination von Algorithmen, die für Schlüsselaustausch, Verschlüsselung und Nachrichtenauthentifizierung verwendet werden. Beispiel: TLS_AES_256_GCM_SHA384 bedeutet TLS mit AES-256-GCM-Verschlüsselung und SHA-384 für die Nachrichtenintegrität. TLS 1.3 hat nur 5 Cipher Suites — alle sicher. TLS 1.2 hat 37, von denen einige schwach sind.

Kann jemand HTTPS-Verkehr nachträglich entschlüsseln?

Nicht mit Forward Secrecy (ephemerer Schlüsselaustausch). Jede Sitzung verwendet einen einzigartigen Schlüssel, der aus dem Diffie-Hellman-Austausch abgeleitet wird. Selbst wenn der langfristige private Schlüssel des Servers kompromittiert wird, können vergangene Sitzungsschlüssel nicht wiederhergestellt werden. TLS 1.3 erzwingt dies; TLS 1.2 unterstützt es bei korrekter Konfiguration.

Welche Rolle spielt GetHTTPS dabei?

GetHTTPS generiert das Zertifikat, das den TLS-Handshake erst möglich macht. Das Zertifikat enthält den öffentlichen Schlüssel, den der Server beim Schlüsselaustausch verwendet. GetHTTPS erstellt dieses Schlüsselpaar in Ihrem Browser mit der Web Crypto API und verbindet sich direkt mit der ACME-API von Let’s Encrypt, um es signieren zu lassen. Wie GetHTTPS funktioniert →