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

Aus Xinux Wiki
Zur Navigation springen Zur Suche springen
Zeile 91: Zeile 91:
 
* stellt sicher, dass der Server den zugehörigen Private Key besitzt
 
* stellt sicher, dass der Server den zugehörigen Private Key besitzt
 
* Ergebnis: der Server kontrolliert den privaten Schlüssel zum Zertifikat
 
* Ergebnis: der Server kontrolliert den privaten Schlüssel zum Zertifikat
 
+
==Client Finished==
 
+
;Finished
 
+
* Client berechnet die Finished-Prüfsumme
*Aus dem '''Shared Secret''' und den Hello-Daten werden über HKDF die Schlüsselmaterialien '''Early Secret''', '''Handshake Secret''' und '''Master Secret''' abgeleitet.
+
* basiert auf dem bisherigen Handshake-Transcript
*Auf Basis des '''Master Secret''' werden die symmetrischen Schlüssel für die verschlüsselte Handshake-Phase und die Application-Data-Phase erzeugt.
+
* wird mit dem Handshake Traffic Key verschlüsselt
*Nach dem Austausch der Finished-Nachrichten ist die gesamte Verbindung verschlüsselt.
+
* bestätigt die Integrität des gesamten Handshakes
 +
* signalisiert dem Server den erfolgreichen Abschluss
 +
==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
 
{{#drawio:tls-1.3}}
 
{{#drawio:tls-1.3}}

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

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

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