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

Aus Xinux Wiki
Zur Navigation springen Zur Suche springen
Zeile 23: Zeile 23:
 
* Extensions sind funktional, nicht kryptographisch zwingend
 
* Extensions sind funktional, nicht kryptographisch zwingend
 
* werden im ClientHello unverschlüsselt übertragen
 
* 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
 +
 +
  
  
−
*Der Server antwortet im ServerHello mit seinem eigenen Zufallswert und seiner ECDHE-Schlüsselkomponente ('''Server Hello Key Share''').
 
−
*Client und Server berechnen aus ihren ECDHE-Schlüsselpaaren ein gemeinsames Geheimnis ('''Shared Secret''').
 
 
*Aus dem '''Shared Secret''' und den Hello-Daten werden über HKDF die Schlüsselmaterialien '''Early Secret''', '''Handshake Secret''' und '''Master Secret''' abgeleitet.
 
*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.
 
*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.
 
*Nach dem Austausch der Finished-Nachrichten ist die gesamte Verbindung verschlüsselt.
 
{{#drawio:tls-1.3}}
 
{{#drawio:tls-1.3}}

Version vom 22. Januar 2026, 16:52 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



  • 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.
Abgerufen von „http://wiki.ixheim.de/index.php?title=TLS_Schlüsselaustausch_und_Sitzungsschlüssel_1.3&oldid=66303“