TLS Schlüsselaustausch und Sitzungsschlüssel 1.3

Aus Xinux Wiki
Zur Navigation springen Zur Suche springen

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


  • 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.