TLS-Handshake.

Der TLS-Handshake verhandelt Protokollversion, Cipher Suite, Serveridentität und Sitzungsschlüssel, bevor Anwendungsdaten gesendet werden. In TLS 1.2 (RFC 5246) benötigt der Handshake zwei Round Trips und verwendet ClientHello, ServerHello, Certificate, ServerKeyExchange sowie ein Finished-Paar, das das ausgehandelte Transkript bestätigt. TLS 1.3 (RFC 8446, 2018) reduziert dies auf einen Round Trip, verschlüsselt alles nach ServerHello, entfernt veraltete Verfahren (RC4, CBC-Modi ohne AEAD, statischer RSA-Schlüsselaustausch, Kompression) und unterstützt 0-RTT-Resumption — schnell, aber anfällig für Replay, weshalb sie nur idempotente Anfragen tragen sollte.

Beide modernen Versionen schreiben ephemeres (EC)DHE für Forward Secrecy vor und authentifizieren den Server über ein X.509-Zertifikat, das entlang einer Vertrauenskette validiert wird. Der Transkript-Hash und der Finished-MAC des Handshakes sind das, was historisch Downgrade- und Renegotiation-Angriffe gebrochen hat: POODLE (2014) zwang Opfer auf das CBC-Padding von SSL 3.0 herab, FREAK und Logjam (2015) erzwangen Export-Grade-RSA/DH, und BEAST nutzte die CBC-IVs von TLS 1.0 aus. Der Downgrade-Schutz-Sentinel im Server-Random von TLS 1.3 signalisiert nun Manipulationen. Weitere betrieblich relevante Fehlerquellen sind schwache oder veraltete Cipher Suites, abgelaufene oder fehlerhaft ausgestellte Zertifikate, fehlendes OCSP-Stapling sowie SNI-/Zertifikats-Diskrepanzen auf gemeinsam genutzter Infrastruktur.

sequenceDiagram
  participant C as Client
  participant S as Server
  C->>S: ClientHello (Versionen, Cipher Suites, Key Share)
  S->>C: ServerHello (gewählte Suite, Key Share)
  S->>C: Certificate + CertificateVerify
  S->>C: Finished
  Note over C,S: Beide leiten symmetrische Schlüssel via (EC)DHE ab
  C->>S: Finished
  C->>S: Verschlüsselte Anwendungsdaten