TLS Vortrag Wiki

Einleitung

• Dieser Vortrag vermittelt die technische Funktionsweise von TLS
• Er erklärt die Rolle der PKI
• Analysiert Unterschiede zwischen klassischen und modernen Handshakes.

Authentifizierung mit TLS

• Public Key Infrastruktur
• Zertifikatsbasierte Authentifizierung
• Schlüsselbasierte Authentifizierung
• Am Ende steht die verschlüsselte Übertragung

Public Key Infrastruktur

Wichtige Rolle der PKI

• PKI ermöglicht sichere Verschlüsselung und digitale Signaturen für E-Mails, HTTPS, VPNs und mehr

Grundprinzip

• PKI nutzt Schlüsselpaare zur sicheren Datenübertragung und Identitätsüberprüfung

Zertifikatsbasierte Authentifizierung

• Nutzt Zertifikat, das von einer CA signiert ist
• Client überprüft die Signatur der CA
• Signatur authentifiziert das Zertifikat

Die CA

Erstellen einer CA

• Nur im lokalen Umfeld nötig
• Meist wird eine öffentliche CA verwendet
• Öffentliche CAs sind im OS als vertrauenswürdig eingebaut
• Kostenlose Certs z. B. bei Let’s Encrypt

CA: Der private Schlüssel

• Der private Schlüssel der CA muss zwingend geheim gehalten werden.
• Er wird nur zum signieren gebraucht

[Bearbeiten]

CA: Das Zertifikat

• Das Zertifikat der CA ist bei offiziellen CA überall in den Betriebssystemen eingebaut
• Überall bedeutet nicht nur PCs, Laptops, Server.
• Sondern auch IOT Geräte alle Art.

[Bearbeiten]

CA: TLS Zertifizierungstelle

• Die wichtigsten Komponenten der CA

[Bearbeiten]

Der Server

Server: TLS PrivKey Server

• Auf dem Server wird ein privater Schlüssel erstellt.
• Geheimhaltung ist wichtig.

[Bearbeiten]

Server: TLS Signing Request

• Es wird ein Öffentlicher Schlüssel erstellt
• Es wird diesem ein Distinguish Name zu geordnet.
• Beide Komponenten ergeben den Certificate Signing Request

[Bearbeiten]

Server: TLS Signing Request wird zurück gesendet

• Der Request wird zur Zertifizierungsstelle geschickt.
• Geheimhaltung ist nicht notwendig.

[Bearbeiten]

CA: Die Signierung

CA: Signierung des Requests

• Es wird ein Hash über den öffentlichen Schlüssel und den Distinguish Name des Servers, sowie dem Ablaufdatum gebildet.
• Dieser wird mit dem geheimen Schlüssel der Zertifizierungsstelle verschlüsselt.
• Diesen Vorgang nennt man Signierung.

[Bearbeiten]

CA: Bauen des Zertifikats

Das Zertifikat wird nun gebaut

• Öffentlicher Schlüssel des Servers
• Signature des Servers
• Distinguish Name des Server
• Distinguish Name der Zertifizierungsstelle
• Ablaufdatum
• Seriennummer

[Bearbeiten]

CA: Zertifikat wird zum Server geschickt

• Der Server bekommt das Zertifikat zugestellt.

[Bearbeiten]

Server: PrivKey-S und Zertifikat-S wird dem Service zu geordnet

• Das Zertifikat und der private Schlüssel werden nun einem oder mehreren Diensten zugeordnet.

[Bearbeiten]

Authenzitätstest

Client: Hat das Zertifikat der Zertifizierungsstelle eingebaut

• Jedes Gerät im Internet das TLS kann hat das Zertifikat der Zertifizierungstelle eingebaut.

[Bearbeiten]

Client:Bekommt das Zertifikat des Servers

• Beim TLS Handshake bekommt der Client das Zertifikat des Servers geschickt.

[Bearbeiten]

Client: Überprüft ob das Zertifikat authentisch ist

[Bearbeiten]

Zertfikatscheck

[Bearbeiten]

TLS 1.3 Handshake

Client Hello

[Bearbeiten]

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)

[Bearbeiten]

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

[Bearbeiten]

TLS 1.3 Handshake

Client Hello

[Bearbeiten]

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

[Bearbeiten]

TLS 1.3 Handshake

Client Hello

[Bearbeiten]

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

[Bearbeiten]