TLS Vortrag Wiki: Unterschied zwischen den Versionen

Aus Xinux Wiki
Zur Navigation springen Zur Suche springen
Keine Bearbeitungszusammenfassung
 
(6 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt)
Zeile 91: Zeile 91:
{{#drawio:Autenzitaetstest}}
{{#drawio:Autenzitaetstest}}


=Zertfikatscheck=
==Zertfikatscheck==
{{#drawio:Zertfikatscheck}}
{{#drawio:Zertfikatscheck}}
=TLS 1.3 Handshake=
==Client Hello==
{{#drawio:tls-1.3-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
=TLS 1.2 Handshake=
* 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
==RSA==
* enthält den ephemeren DH/ECDH-Public-Key des Clients
{{#drawio:tls-1.2-rsa-1}}
* Private Key verbleibt ausschließlich beim Client
;ClientHello / ServerHello
* Grundlage für die spätere Berechnung des Shared Secret
* Client und Server handeln Cipher Suite aus
* ermöglicht den 1-RTT-Handshake
* Beide tauschen Zufallswerte (Random-C, Random-S) aus


;Client Random
;Certificate-S
* 32 Byte Zufallswert
* Server schickt sein Zertifikat
* fließt in die Schlüsselableitung ein
* Client prüft Zertifikat (Signatur, FQDN, notBefore/notAfter)
* erhöht die Entropie des Handshakes


;(weitere Extensions, z. B. SNI, ALPN)
{{#drawio:tls-1.2-rsa-2}}
* SNI: gibt den gewünschten Ziel-Hostnamen an
;Pre-Master-Secret (PMS)
* ALPN: listet die vom Client unterstützten Anwendungsprotokolle (z. B. HTTP/2, HTTP/1.1)
* Client generiert PMS zufällig und verschlüsselt es mit PubK-S
* Extensions sind funktional, nicht kryptographisch zwingend
* Nur der Server kann es mit PrivK-S entschlüsseln → beweist Besitz des privaten Schlüssels
* werden im ClientHello unverschlüsselt übertragen
* Session Key = f(Random-C, Random-S, PMS) — beide Seiten berechnen ihn unabhängig


==Server Hello==
;Nachteil
;Selected Version
* Kein Forward Secrecy — wer später PrivK-S erhält kann alle aufgezeichneten Sessions entschlüsseln
* Server bestätigt die zu verwendende TLS-Version
* in diesem Fall TLS 1.3
* keine weitere Versionsverhandlung mehr


;Key Share
==Diffie-Hellman==
* enthält den ephemeren DH/ECDH-Public-Key des Servers
{{#drawio:tls-1.2-dh-1}}
* verwendet dieselbe Gruppe wie vom Client ausgewählt
;Certificate-S + DH-Parameter
* ermöglicht beiden Seiten die Berechnung des Shared Secret
* Server schickt Zertifikat und öffentliche DH-Parameter, signiert mit PrivK-S
* Private Key verbleibt ausschließlich beim Server
* Client prüft Signatur mit PubK-S → DH-Parameter kommen wirklich vom Server


;Server Random
{{#drawio:tls-1.2-dh-2}}
* 32 Byte Zufallswert des Servers
;Pre-Master-Secret (PMS)
* fließt in die Schlüsselableitung ein
* Client schickt seinen öffentlichen DH-Parameter
* ergänzt den Client Random zur Entropieerzeugung
* Beide Seiten berechnen PMS unabhängig per DH — wird nie übertragen
* Session Key = f(Random-C, Random-S, PMS)


;Vorteil gegenüber RSA
* Forward Secrecy — ephemere DH-Parameter werden nach dem Handshake verworfen
* Aufgezeichnete Sessions können später nicht entschlüsselt werden


==Handshake Secret==
=TLS 1.3 Handshake=
;Shared Secret
{{#drawio:tls-1.3-client-hello}}
* wird nach Empfang des ServerHello lokal berechnet
==Client Hello==
* basiert auf ephemerem (EC)DH
* TLS 1.3 wird angeboten, ephemerer Public Key wird mitgeschickt
* beide Seiten nutzen:
* Private Key bleibt beim Client
** eigenen Private Key
** fremden Public Key
* Ergebnis ist auf beiden Seiten identisch
* wird niemals übertragen


;Handshake Secret
==Server Hello==
* wird aus dem Shared Secret per HKDF abgeleitet
* Server bestätigt TLS 1.3, schickt eigenen ephemeren Public Key
** HKDF steht für HMAC-based Key Derivation Function
* Beide Seiten können jetzt das Shared Secret berechnen
** 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


==Handshake Secret==
* Shared Secret wird lokal per (EC)DH berechnet — wird nie übertragen
* Per HKDF werden daraus die Handshake Traffic Keys abgeleitet
* Ab EncryptedExtensions ist alles verschlüsselt


==Server Handshake Nachrichten (TLS 1.3)==
==Server Handshake Nachrichten (TLS 1.3)==
{{#drawio:tls-1.3-2}}
{{#drawio:tls-1.3-2}}
;EncryptedExtensions
;EncryptedExtensions
* erste verschlüsselte TLS-Nachricht des Servers
* Erste verschlüsselte Nachricht des Servers
* wird mit den Handshake Traffic Keys verschlüsselt
* Enthält z. B. ALPN (ausgewähltes Anwendungsprotokoll)
* 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
;Certificate
* Übertragung der Server-Zertifikatskette
* Server schickt sein Zertifikat — vollständig verschlüsselt
* vollständig verschlüsselt
* Enthält den öffentlichen Schlüssel und die CA-Signatur
* 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
;CertificateVerify
* Server signiert den bisherigen Handshake-Transcript
* Server signiert den bisherigen Handshake-Transcript mit PrivK-S
* Signatur erfolgt mit dem privaten Schlüssel des Servers
* Beweist dass er den zugehörigen Private Key besitzt
* 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
;Finished
* verschlüsselte Prüfsumme über den gesamten bisherigen Handshake
* Hash über den gesamten Handshake-Transcript
* berechnet mit dem Handshake Traffic Key
* Client prüft Zertifikat, Signatur und Hash
* bestätigt die Integrität aller vorherigen Handshake-Nachrichten
* Client schickt eigenen Finished-Hash zurück
* Abschluss der Server-Seite des TLS-1.3-Handshakes
* Bestätigt dass beide Seiten denselben Handshake gesehen haben
 
==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==
;Application Traffic Keys
* Sitzungsschlüssel werden nach erfolgreichem Finished aktiviert
* werden nach erfolgreichem Client Finished aktiviert
* Verschlüsselte Kommunikation beginnt
* werden aus den Application Traffic Secrets abgeleitet
=TLS 1.3 – Neuerungen=
* entsprechen dem umgangssprachlichen Sitzungsschlüssel
* Kein RSA-Schlüsselaustausch mehr
* existieren ausschließlich lokal auf Client und Server
* Nur noch (EC)DHE → Forward Secrecy immer gegeben
* Reduzierter Handshake: nur '''1 Round Trip'''
* Veraltete Algorithmen (RC4, DES, SHA-1 etc.) entfernt
* Zertifikat und CertificateVerify werden verschlüsselt übertragen


=TLS 1.2 vs. TLS 1.3=
{| class="wikitable"
! Merkmal !! TLS 1.2 RSA !! TLS 1.2 DHE !! TLS 1.3
|-
| Round Trips || 2 || 2 || 1
|-
| Forward Secrecy || ✗ || ✓ || ✓
|-
| PMS-Übertragung || verschlüsselt || nie || nie
|-
| Authentifizierung || Zertifikat || Zert. + Signatur || Zert. + Signatur
|-
| Empfohlen || ✗ || eingeschränkt || ✓
|}


==TLS 1.3 Verbindung erfolgreich==
=Zusammenfassung=
* 1-RTT-Handshake abgeschlossen
* TLS nutzt PKI, Zertifikate und asymmetrische Authentifizierung
* Server ist kryptographisch authentifiziert
* TLS 1.2 RSA: einfach zu verstehen, aber kein Forward Secrecy
* Client ist über den Handshake implizit bestätigt
* TLS 1.2 DHE: Forward Secrecy durch Diffie-Hellman
* Application Traffic Keys sind aktiv
* TLS 1.3: moderner, schneller, sicherer – nur noch DHE
* geschützte Anwendungsdaten können übertragen werden

Aktuelle Version vom 3. Juni 2026, 19:03 Uhr

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
TLS CA PrivK

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.
TLS CA Cert

CA: TLS Zertifizierungstelle

  • Die wichtigsten Komponenten der CA
TLS Authorithy

Der Server

Server: TLS PrivKey Server

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

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
Signing Request

Server: TLS Signing Request wird zurück gesendet

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

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.
TLS Zertifizierung

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
server-zertifikat

CA: Zertifikat wird zum Server geschickt

  • Der Server bekommt das Zertifikat zugestellt.
server-zertifikat-server

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.
PrivKey-S-Zertifikat-S-zu-Service

Authenzitätstest

Client: Hat das Zertifikat der Zertifizierungsstelle eingebaut

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

Client:Bekommt das Zertifikat des Servers

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

Client: Überprüft ob das Zertifikat authentisch ist

Autenzitaetstest

Zertfikatscheck

Zertfikatscheck

TLS 1.2 Handshake

RSA

tls-1.2-rsa-1
ClientHello / ServerHello
  • Client und Server handeln Cipher Suite aus
  • Beide tauschen Zufallswerte (Random-C, Random-S) aus
Certificate-S
  • Server schickt sein Zertifikat
  • Client prüft Zertifikat (Signatur, FQDN, notBefore/notAfter)
tls-1.2-rsa-2
Pre-Master-Secret (PMS)
  • Client generiert PMS zufällig und verschlüsselt es mit PubK-S
  • Nur der Server kann es mit PrivK-S entschlüsseln → beweist Besitz des privaten Schlüssels
  • Session Key = f(Random-C, Random-S, PMS) — beide Seiten berechnen ihn unabhängig
Nachteil
  • Kein Forward Secrecy — wer später PrivK-S erhält kann alle aufgezeichneten Sessions entschlüsseln

Diffie-Hellman

tls-1.2-dh-1
Certificate-S + DH-Parameter
  • Server schickt Zertifikat und öffentliche DH-Parameter, signiert mit PrivK-S
  • Client prüft Signatur mit PubK-S → DH-Parameter kommen wirklich vom Server
tls-1.2-dh-2
Pre-Master-Secret (PMS)
  • Client schickt seinen öffentlichen DH-Parameter
  • Beide Seiten berechnen PMS unabhängig per DH — wird nie übertragen
  • Session Key = f(Random-C, Random-S, PMS)
Vorteil gegenüber RSA
  • Forward Secrecy — ephemere DH-Parameter werden nach dem Handshake verworfen
  • Aufgezeichnete Sessions können später nicht entschlüsselt werden

TLS 1.3 Handshake

tls-1.3-client-hello

Client Hello

  • TLS 1.3 wird angeboten, ephemerer Public Key wird mitgeschickt
  • Private Key bleibt beim Client

Server Hello

  • Server bestätigt TLS 1.3, schickt eigenen ephemeren Public Key
  • Beide Seiten können jetzt das Shared Secret berechnen

Handshake Secret

  • Shared Secret wird lokal per (EC)DH berechnet — wird nie übertragen
  • Per HKDF werden daraus die Handshake Traffic Keys abgeleitet
  • Ab EncryptedExtensions ist alles verschlüsselt

Server Handshake Nachrichten (TLS 1.3)

tls-1.3-2
EncryptedExtensions
  • Erste verschlüsselte Nachricht des Servers
  • Enthält z. B. ALPN (ausgewähltes Anwendungsprotokoll)
Certificate
  • Server schickt sein Zertifikat — vollständig verschlüsselt
  • Enthält den öffentlichen Schlüssel und die CA-Signatur
CertificateVerify
  • Server signiert den bisherigen Handshake-Transcript mit PrivK-S
  • Beweist dass er den zugehörigen Private Key besitzt
Finished
  • Hash über den gesamten Handshake-Transcript
  • Client prüft Zertifikat, Signatur und Hash
  • Client schickt eigenen Finished-Hash zurück
  • Bestätigt dass beide Seiten denselben Handshake gesehen haben

Application Traffic Keys

  • Sitzungsschlüssel werden nach erfolgreichem Finished aktiviert
  • Verschlüsselte Kommunikation beginnt

TLS 1.3 – Neuerungen

  • Kein RSA-Schlüsselaustausch mehr
  • Nur noch (EC)DHE → Forward Secrecy immer gegeben
  • Reduzierter Handshake: nur 1 Round Trip
  • Veraltete Algorithmen (RC4, DES, SHA-1 etc.) entfernt
  • Zertifikat und CertificateVerify werden verschlüsselt übertragen

TLS 1.2 vs. TLS 1.3

Merkmal TLS 1.2 RSA TLS 1.2 DHE TLS 1.3
Round Trips 2 2 1
Forward Secrecy ✗ ✓ ✓
PMS-Übertragung verschlüsselt nie nie
Authentifizierung Zertifikat Zert. + Signatur Zert. + Signatur
Empfohlen ✗ eingeschränkt ✓

Zusammenfassung

  • TLS nutzt PKI, Zertifikate und asymmetrische Authentifizierung
  • TLS 1.2 RSA: einfach zu verstehen, aber kein Forward Secrecy
  • TLS 1.2 DHE: Forward Secrecy durch Diffie-Hellman
  • TLS 1.3: moderner, schneller, sicherer – nur noch DHE