TLS Handshake

Wenn du curl -v https://google.com machst, siehst du:

1. Client Hello ("Ich kann TLS 1.2 und 1.3").
2. Server Hello ("Wir nehmen TLS 1.3").
3. Certificate ("Hier ist mein Ausweis").
4. Server Key Exchange. Wenn es fehlschlägt: SSL_ERROR_NO_CYPHER_OVERLAP (Wir sprechen keine gemeinsame Sprache) oder CERT_DATE_INVALID (Ausweis abgelaufen).

1. Diffie-Hellman Key Exchange (DH)

Wie, tauscht man einen Schlüssel aus, wenn alle zuhören (Key Exchange)? Das DH-Verfahren ist Mathe-Magie. A und B mischen ihre Farben (Private Key) mit einer gemeinsamen Farbe (Public). Sie tauschen die Mischung aus. Dann mischen sie ihre eigene Farbe nochmal dazu. Am Ende haben beide dieselbe Farbe ("Shared Secret"), aber ein Lauscher, der nur die Mischungen gesehen hat, kann die Endfarbe nicht errechnen (Diskreter Logarithmus Problem). Das ermöglicht Perfect Forward Secrecy (PFS). Selbst wenn der Server-Key später geklaut wird, kann man alte Gespräche nicht entschlüsseln.

2. SNI (Server Name Indication)

Ein Server hostet 100 Webseiten (Apache Vhosts). Der Client sagt "Hallo Server" (TCP IP). Welches Zertifikat soll der Server zeigen? Das von shop.com oder blog.com? Früher (ohne SNI) brauchte jede HTTPS-Seite eine eigene IP. Mit SNI sendet der Client im Client Hello (unverschlüsselt!) den Hostnamen: "Ich will zu shop.com". Der Server kann das richtige Zertifikat wählen. Nachteil: Ein Lauscher sieht, welche Seite du besuchst (Domain), auch wenn er den Inhalt nicht lesen kann. (Lösung: ECH - Encrypted Client Hello).

3. TLS 1.2 vs 1.3

TLS 1.3 (2018) ist viel schneller. Es braucht nur 1 Round Trip (1-RTT) statt 2. Es hat unsichere Algorithmen (RSA Key Exchange, MD5) entfernt. Es verschlüsselt mehr vom Handshake (sogar das Zertifikat selbst). Admins sollten TLS 1.0 und 1.1 deaktivieren (Deprecated/Unsicher).

0-RTT: Die Vor- und Nachteile (Replay Attacks)

TLS 1.3 brüstet sich massiv mit 0-RTT Session Resumption (Zero Round Trip Time). Wenn der Client-Browser den Server schon von gestern kennt, hat er ein Ticket (Pre-Shared Key, PSK). Beim ersten Request ballert er direkt ClientHello inklusive dem verschlüsselten HTTP Payload (GET /) in einem Schwung durch. Extrem schnell. Aber: 0-RTT-Daten unterliegen radikalen Replay Attacks. Wenn ein Hacker dieses initiale Paket aufzeichnet und dem Server eine Millisekunde später erneut unterschiebt, führt der Server es nochmal aus ("Kaufe Aktie XYZ"). Deswegen verbietet RFC 8446 für 0-RTT alle non-idempotenten ("verändernden") Aktionen (POST/PUT/DELETE) oder Server-APIs müssen strikte Nonce-Tracker einbauen, um Replays proaktiv abzufangen.

ALPN (Application-Layer Protocol Negotiation)

Bevor Server HTTP/2 einführten, hatten sie ein Problem: "Woher weiß der Client, dass ich nach dem TLS Handshake HTTP/1.1 oder das neue binäre HTTP/2 sprechen will?" Extra Ports wollte keiner (TCP 443 bleibt). Die Lösung ist der ALPN-Block direkt auf TLS-Ebene! Der Browser fügt seinem ClientHello unverschlüsselt ein Array von Strings bei: h2, http/1.1. Der Server wählt seinen präferierten Top-Kandidaten aus (h2) und packt dies in sein ServerHello Zertifikat-Return-Paket mit rein. TLS verhandelt also nicht mehr nur Verschlüsselung, sondern diktiert der Application Layer direkt, mit welchem App-Protokoll der Data-Stream im Backend gestartet werden soll.

Elliptic Curve Cryptography (ECC vs RSA)

Die Zertifikate im Handshake waren jahrzehntelang RSA basiert (Faktorisierung von Primzahlen, RSA-2048). Diese Signaturblöcke waren massiv groß (KB). Das bremst Mobile-Verbindungen künstlich ab. Das moderne Web ist zu Elliptic Curves (Hyperbel-Mathematik) migriert (Algorithmen wie Curve25519 oder ECSDA). Ein ECDSA Schlüssel mit 256-Bit Länge ist faktisch genauso krypto-sicher wie ein kolossaler RSA-3072 Schlüssel. Die Zertifikate fallen in ihrer Byte-Größe massiv zusammen, Handshake-CPU-Berechnungen von Kurvenpunkten sind für Mobilprozessoren stark optimiert (weniger Batterie-Verbrauch am Endgerät).