TLS/SSL: HTTPS Handshake Schritt für Schritt
Jedes Mal, wenn du eine HTTPS-URL aufrufst, läuft in Millisekunden ein komplexes kryptografisches Protokoll ab: der TLS-Handshake. Er koordiniert in wenigen Nachrichten, was für sichere Kommunikation nötig ist: beide Seiten einigen sich auf Algorithmen, der Server authentifiziert sich mit einem Zertifikat, beide Seiten berechnen unabhängig denselben geheimen Session-Key – und erst dann beginnt die eigentliche verschlüsselte Kommunikation. TLS ist der praktische Zusammenlauf aller Kryptografie-Konzepte dieses Kurses.
TLS (Transport Layer Security) ist der Nachfolger von SSL, das heute als unsicher gilt. Der Name „SSL" ist jedoch so eingebürgert, dass er im Alltag noch häufig verwendet wird – auch wenn seit Jahren technisch immer TLS gemeint ist. Die aktuelle Version TLS 1.3 (RFC 8446, 2018) ist schneller und sicherer als alle Vorgänger: Sie benötigt nur einen Roundtrip für den Handshake statt zwei, erzwingt immer Perfect Forward Secrecy und hat allen kryptografischen „Ballast" aus älteren Versionen entfernt.
1) TLS-Versionen: Entwicklung und Status
2) Der TLS 1.3 Handshake – Schritt für Schritt
Der TLS 1.3 Handshake ist bewusst schlank gehalten: Wo TLS 1.2 noch zwei Roundtrips benötigte, kommt TLS 1.3 mit einem aus. Der Browser sendet bereits im ersten ClientHello seinen Diffie-Hellman-Key-Share mit, so dass der Server sofort mit der Schlüsselberechnung beginnen kann. Die Animation zeigt alle Nachrichten – von ClientHello bis zur ersten verschlüsselten Application Data.
3) Cipher Suites: die Algorithmus-Kombination
Eine Cipher Suite ist eine Kombination von vier Algorithmen, die zusammen eine TLS-Verbindung absichern. Jede Suite definiert, wie Schlüssel ausgetauscht werden, wie der Server sich authentifiziert, wie Daten verschlüsselt werden und wie Integrität gesichert wird. In TLS 1.3 wurden alle schwachen Algorithmen entfernt – es gibt nur noch fünf erlaubte Cipher Suites, alle mit AEAD (Authenticated Encryption with Associated Data), was Verschlüsselung und Integritätsschutz kombiniert.
| Element | Zweck | TLS 1.3 Beispiel |
|---|---|---|
| Schlüsselaustausch | Session-Key sicher vereinbaren | ECDHE (X25519 oder P-256) – ephemer, PFS garantiert |
| Authentifizierung | Server beweist Identität | ECDSA (Elliptic Curve) oder RSA-PSS |
| Verschlüsselung | Nutzdaten schützen | AES-256-GCM oder ChaCha20-Poly1305 |
| Integrität | Manipulation erkennen | SHA-384 (im GCM-Tag integriert – AEAD) |
| HSTS | Browser erzwingt HTTPS | Strict-Transport-Security: max-age=31536000 |
4) Was TLS schützt – und was nicht
TLS verschlüsselt den Inhalt der Kommunikation zwischen Browser und Webserver. Was es nicht schützt: Die IP-Adresse des Servers ist weiterhin sichtbar (DNS-Anfragen sind unverschlüsselt, außer bei DoH/DoT). Der Hostname kann durch SNI (Server Name Indication) im ClientHello sichtbar sein, obwohl TLS 1.3 mit ESNI/ECH daran arbeitet. TLS schützt nur die Übertragung – was der Server danach mit den Daten macht, liegt außerhalb. Wer echte Ende-zu-Ende-Verschlüsselung braucht, bei der nicht einmal der Server mitlesen kann, braucht Ende-zu-Ende-Verschlüsselung.
Zusammenfassung
TLS 1.3 ist der aktuelle Standard – schneller (1-RTT), immer PFS, nur AEAD-Cipher-Suites. Handshake: ClientHello mit ECDH-Share → ServerHello + Zertifikat + Signatur → Browser prüft CA-Kette → beide berechnen Session-Key via ECDHE → verschlüsselter Kanal. ECDHE sichert Perfect Forward Secrecy: aufgezeichneter Verkehr bleibt dauerhaft privat. HSTS verhindert SSL-Stripping. TLS verbindet alle Kursthemen: asymmetrisch für Schlüsselaustausch, Zertifikat für Authentizität, symmetrisch für Daten. Weiterführend: Ende-zu-Ende-Verschlüsselung.