TLS Schlüsselaustausch und Sitzungsschlüssel 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 spätere 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

Shared Secret

• wird nach Empfang des ServerHello lokal berechnet
• basiert auf ephemerem (EC)DH
• beide Seiten nutzen:
  • eigenen Private Key
  • fremden Public Key
• Ergebnis ist auf beiden Seiten identisch
• wird niemals übertragen

Handshake Secret

• wird aus dem Shared Secret per HKDF abgeleitet
  • HKDF steht für HMAC-based Key Derivation Function.
  • HKDF ist ein standardisiertes Verfahren zur Schlüsselableitung.
• stellt einen internen kryptographischen Zustand dar
• dient als Basis für die Handshake-Verschlüsselung

Handshake Traffic Keys

• werden aus dem Handshake Secret abgeleitet
• werden niemals übertragen
• ab der nächsten TLS-Nachricht aktiv

Verschlüsselung aktiv ab jetzt

• alle folgenden Handshake-Nachrichten sind verschlüsselt
• geschützt mit den Handshake Traffic Keys

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,SNI weitere verbindungsrelevante Parameter
  • ALPN: Welches Anwendungsprotokoll hat der Server ausgewählt hat (z. B. h2 oder http/1.1).
  • SNI: Bestätigt welcher Hostname bzw. welches Zertifikat für diese TLS-Verbindung verwendet wird.

Certificate

• Übertragung der Server-Zertifikatskette
• vollständig verschü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

Client Finished

Finished

• Client berechnet die Finished-Prüfsumme
• basiert auf dem bisherigen Handshake-Transcript
• wird mit dem Handshake Traffic Key verschlüsselt
• bestätigt die Integrität des gesamten Handshakes
• signalisiert dem Server den erfolgreichen Abschluss

Application Traffic Keys

Application Traffic Keys

• werden nach erfolgreichem Client Finished aktiviert
• werden aus den Application Traffic Secrets abgeleitet
• entsprechen dem umgangssprachlichen Sitzungsschlüssel
• existieren ausschließlich lokal auf Client und Server

TLS 1.3 Verbindung erfolgreich

• 1-RTT-Handshake abgeschlossen
• Client und Server haben sich gegenseitig authentifiziert
• Application Traffic Keys sind aktiv
• geschützte Anwendungsdaten können übertragen werden

[Bearbeiten]