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

Aus Xinux Wiki
Zur Navigation springen Zur Suche springen
 
(8 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt)
Zeile 1: Zeile 1:
−
*Der Client sendet im ClientHello seinen Zufallswert sowie eine frische ECDHE-Schlüsselkomponente ('''Client Hello Key Share''').
+
==Client Hello==
−
*Der Server antwortet im ServerHello mit seinem eigenen Zufallswert und seiner ECDHE-Schlüsselkomponente ('''Server Hello Key Share''').
+
;Supported Versions
−
*Client und Server berechnen aus ihren ECDHE-Schlüsselpaaren ein gemeinsames Geheimnis ('''Shared Secret''').
+
* gibt an, welche TLS-Versionen der Client unterstützt
−
*Aus dem '''Shared Secret''' und den Hello-Daten werden über HKDF die Schlüsselmaterialien '''Early Secret''', '''Handshake Secret''' und '''Master Secret''' abgeleitet.
+
* bei TLS 1.3 wird hier explizit TLS 1.3 angeboten
−
*Auf Basis des '''Master Secret''' werden die symmetrischen Schlüssel für die verschlüsselte Handshake-Phase und die Application-Data-Phase erzeugt.
+
* keine klassische Versionsverhandlung mehr wie bei TLS 1.2 (legacy_version ist nur noch ein Platzhalter)
−
*Nach dem Austausch der Finished-Nachrichten ist die gesamte Verbindung verschlüsselt.
+
 
 +
;Supported Groups
 +
* Liste unterstützter (EC)DHE-Gruppen
 +
* z. B. x25519, secp256r1
 +
* Gruppen definieren alle kryptographischen Parameter vollständig
 +
* keine Aushandlung einzelner Parameter wie 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: listet die vom Client unterstützten Anwendungsprotokolle (z. B. HTTP/2, HTTP/1.1)
 +
* 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
 +
* verwendet dieselbe 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
 +
* sind ab EncryptedExtensions 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 und weitere verbindungsrelevante Parameter
 +
** ALPN: welches Anwendungsprotokoll der Server ausgewählt hat (z. B. h2 oder http/1.1)
 +
 
 +
;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
 +
 
 +
 
 +
==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
 +
* Server ist kryptographisch authentifiziert
 +
* Client ist über den Handshake implizit bestätigt
 +
* Application Traffic Keys sind aktiv
 +
* geschützte Anwendungsdaten können übertragen werden
 +
 
 +
 
 
{{#drawio:tls-1.3}}
 
{{#drawio:tls-1.3}}

Aktuelle Version vom 3. Februar 2026, 12:02 Uhr

Client Hello

Supported Versions
  • gibt an, welche TLS-Versionen der Client unterstützt
  • bei TLS 1.3 wird hier explizit TLS 1.3 angeboten
  • keine klassische Versionsverhandlung mehr wie bei TLS 1.2 (legacy_version ist nur noch ein Platzhalter)
Supported Groups
  • Liste unterstützter (EC)DHE-Gruppen
  • z. B. x25519, secp256r1
  • Gruppen definieren alle kryptographischen Parameter vollständig
  • keine Aushandlung einzelner Parameter wie 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: listet die vom Client unterstützten Anwendungsprotokolle (z. B. HTTP/2, HTTP/1.1)
  • 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
  • verwendet dieselbe 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
  • sind ab EncryptedExtensions 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 und weitere verbindungsrelevante Parameter
    • ALPN: welches Anwendungsprotokoll der Server ausgewählt hat (z. B. h2 oder http/1.1)
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


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
  • Server ist kryptographisch authentifiziert
  • Client ist über den Handshake implizit bestätigt
  • Application Traffic Keys sind aktiv
  • geschützte Anwendungsdaten können übertragen werden


Abgerufen von „http://wiki.ixheim.de/index.php?title=TLS_Schlüsselaustausch_und_Sitzungsschlüssel_1.3&oldid=66548“