TLS Schlüsselaustausch und Sitzungsschlüssel 1.3: Unterschied zwischen den Versionen

Aus Xinux Wiki
Zur Navigation springen Zur Suche springen
Zeile 52: Zeile 52:
 
* aus dem Handshake Secret werden Handshake Traffic Keys abgeleitet
 
* aus dem Handshake Secret werden Handshake Traffic Keys abgeleitet
 
* ab der nächsten TLS-Nachricht wird verschlüsselt kommuniziert
 
* 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
  
  

Version vom 22. Januar 2026, 16:57 Uhr

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.