TLS Schlüsselaustausch und Sitzungsschlüssel 1.3
Version vom 22. Januar 2026, 17:01 Uhr von Thomas.will (Diskussion | Beiträge) (→Server Handshake Nachrichten (TLS 1.3))
Client Hello
- Supported Versions
- gibt an, welche TLS-Versionen der Client unterstützt
- bei TLS 1.3 praktisch nur noch TLS 1.3
- keine klassische Versionsverhandlung mehr wie bei TLS 1.2
- Supported Groups
- Liste unterstützter (EC)DHE-Gruppen
- z. B. x25519, secp256r1
- Gruppen definieren alle kryptographischen Parameter fest
- keine Aushandlung von p oder g
- Key Share
- enthält den ephemeren DH/ECDH-Public-Key des Clients
- Private Key verbleibt ausschließlich beim Client
- Grundlage für die Berechnung des Shared Secret
- ermöglicht den 1-RTT-Handshake
- Client Random
- 32 Byte Zufallswert
- fließt in die Schlüsselableitung ein
- erhöht die Entropie des Handshakes
- (weitere Extensions, z. B. SNI, ALPN)
- SNI: gibt den gewünschten Ziel-Hostnamen an
- ALPN: verhandelt das Anwendungsprotokoll (z. B. HTTP/2)
- Extensions sind funktional, nicht kryptographisch zwingend
- werden im ClientHello unverschlüsselt übertragen
Server Hello
- Selected Version
- Server bestätigt die zu verwendende TLS-Version
- in diesem Fall TLS 1.3
- keine weitere Versionsverhandlung mehr
- Key Share
- enthält den ephemeren DH/ECDH-Public-Key des Servers
- gleiche Gruppe wie vom Client ausgewählt
- ermöglicht beiden Seiten die Berechnung des Shared Secret
- Private Key verbleibt ausschließlich beim Server
- Server Random
- 32 Byte Zufallswert des Servers
- fließt in die Schlüsselableitung ein
- ergänzt den Client Random zur Entropieerzeugung
Handshake Secret
- Handshake Secret berechnet
- Client und Server berechnen das gemeinsame Shared Secret
- basiert auf dem ephemeren (EC)DH-Key-Exchange
- beide Seiten nutzen:
- eigenen Private Key
- fremden Public Key
- Ergebnis ist auf beiden Seiten identisch
- aus DH Key Exchange
- verwendet ausschließlich ephemere Schlüssel
- gewährleistet Perfect Forward Secrecy
- kein Zugriff möglich ohne Private Keys
- Verschlüsselung aktiv ab jetzt
- aus dem Handshake Secret werden Handshake Traffic Keys abgeleitet
- ab der nächsten TLS-Nachricht wird verschlüsselt kommuniziert
Server Handshake Nachrichten (TLS 1.3)
- EncryptedExtensions
- erste verschlüsselte TLS-Nachricht des Servers
- wird mit den Handshake Traffic Keys verschlüsselt
- enthält die vom Server akzeptierten Extensions
- z. B. ALPN, weitere verbindungsrelevante Parameter
- enthält keine Zertifikate und keine Signaturen
- Certificate
- Übertragung der Server-Zertifikatskette
- vollständig verschlüsselt
- Zertifikat enthält:
- den öffentlichen Schlüssel des Servers
- Identitätsinformationen
- die Signatur der ausstellenden CA
- Client nutzt das Zertifikat zur Authentizitätsprüfung
- CertificateVerify
- Server signiert den bisherigen Handshake-Transcript
- Signatur erfolgt mit dem privaten Schlüssel des Servers
- der zugehörige öffentliche Schlüssel befindet sich im Zertifikat
- beweist die Kontrolle über den Private Key
- schützt vor Man-in-the-Middle-Angriffen
- Finished
- verschlüsselte Prüfsumme über den gesamten bisherigen Handshake
- berechnet mit dem Handshake Traffic Key
- bestätigt die Integrität aller vorherigen Handshake-Nachrichten
- Abschluss der Server-Seite des TLS-1.3-Handshakes
Client prüft Server
- Zertifikatsprüfung
- Client prüft die Server-Zertifikatskette
- Signatur der Zertifikate wird mit dem Public Key der CA verifiziert
- Vertrauenskette endet bei einer bekannten Root-CA
- Gültigkeitszeitraum und Zertifikatsattribute werden geprüft
- Ergebnis: der öffentliche Schlüssel des Servers ist vertrauenswürdig
- CertificateVerify Prüfung
- Client verifiziert die CertificateVerify-Signatur
- verwendet den öffentlichen Schlüssel aus dem Server-Zertifikat
- überprüft die Signatur über den bisherigen Handshake-Transcript
- stellt sicher, dass der Server den zugehörigen Private Key besitzt
- Ergebnis: der Server kontrolliert den privaten Schlüssel zum Zertifikat
- Aus dem Shared Secret und den Hello-Daten werden über HKDF die Schlüsselmaterialien Early Secret, Handshake Secret und Master Secret abgeleitet.
- Auf Basis des Master Secret werden die symmetrischen Schlüssel für die verschlüsselte Handshake-Phase und die Application-Data-Phase erzeugt.
- Nach dem Austausch der Finished-Nachrichten ist die gesamte Verbindung verschlüsselt.
