TLS Vortrag Wiki: Unterschied zwischen den Versionen

Aus Xinux Wiki
Zur Navigation springen Zur Suche springen
 
(37 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt)
Zeile 24: Zeile 24:
 
*Kostenlose Certs z. B. bei Let’s Encrypt
 
*Kostenlose Certs z. B. bei Let’s Encrypt
 
==CA: Der private Schlüssel==
 
==CA: Der private Schlüssel==
 +
*Der private Schlüssel der CA muss zwingend geheim gehalten werden.
 +
*Er wird nur zum signieren gebraucht
 
{{#drawio:TLS CA PrivK}}
 
{{#drawio:TLS CA PrivK}}
 +
 
==CA: Das Zertifikat==
 
==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.
 
{{#drawio:TLS CA Cert}}
 
{{#drawio:TLS CA Cert}}
  
 
==CA: TLS Zertifizierungstelle==
 
==CA: TLS Zertifizierungstelle==
 +
*Die wichtigsten Komponenten der CA
 
{{#drawio:TLS Authorithy}}
 
{{#drawio:TLS Authorithy}}
 +
 
=Der Server=
 
=Der Server=
 
==Server: TLS PrivKey Server==
 
==Server: TLS PrivKey Server==
 +
*Auf dem Server wird ein privater Schlüssel erstellt.
 +
*Geheimhaltung ist wichtig.
 
{{#drawio:PrivK-Server}}
 
{{#drawio:PrivK-Server}}
 +
 
==Server: TLS Signing Request==
 
==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
 
{{#drawio:Signing Request}}
 
{{#drawio:Signing Request}}
−
==Server: TLS Signing Request==
+
 
−
{{#drawio:Signing Request-Server}}
+
==Server: TLS Signing Request wird zurück gesendet==
 +
*Der Request wird zur Zertifizierungsstelle geschickt.
 +
*Geheimhaltung ist nicht notwendig.
 +
 
 
=CA: Die Signierung=
 
=CA: Die Signierung=
 
==CA: Signierung des Requests==
 
==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.
 
{{#drawio:TLS Zertifizierung}}
 
{{#drawio:TLS Zertifizierung}}
 +
 
==CA: Bauen des Zertifikats==
 
==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
 
{{#drawio:server-zertifikat}}
 
{{#drawio:server-zertifikat}}
 +
 
==CA: Zertifikat wird zum Server geschickt==
 
==CA: Zertifikat wird zum Server geschickt==
 +
*Der Server bekommt das Zertifikat zugestellt.
 
{{#drawio:server-zertifikat-server}}
 
{{#drawio:server-zertifikat-server}}
 +
 
=Server: PrivKey-S und Zertifikat-S wird dem Service zu geordnet=
 
=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.
 
{{#drawio:PrivKey-S-Zertifikat-S-zu-Service}}
 
{{#drawio:PrivKey-S-Zertifikat-S-zu-Service}}
  
 
=Authenzitätstest=
 
=Authenzitätstest=
 
==Client: Hat das Zertifikat der Zertifizierungsstelle eingebaut==
 
==Client: Hat das Zertifikat der Zertifizierungsstelle eingebaut==
 +
*Jedes Gerät im Internet das TLS kann hat das Zertifikat der Zertifizierungstelle eingebaut.
 +
{{#drawio:TLS CA Cert}}
  
 +
==Client:Bekommt das Zertifikat des Servers==
 +
*Beim TLS Handshake bekommt der Client das Zertifikat des Servers geschickt.
 +
{{#drawio:server-zertifikat}}
  
 +
==Client: Überprüft ob das Zertifikat authentisch ist==
 
{{#drawio:Autenzitaetstest}}
 
{{#drawio:Autenzitaetstest}}
  
−
=Zertfikatscheck=
+
==Zertfikatscheck==
 
{{#drawio:Zertfikatscheck}}
 
{{#drawio:Zertfikatscheck}}
 +
 +
=TLS 1.2 Handshake=
 +
 +
==RSA==
 +
{{#drawio: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)
 +
 +
{{#drawio: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==
 +
{{#drawio: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
 +
 +
{{#drawio: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=
 +
{{#drawio: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)==
 +
{{#drawio: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=
 +
{| 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 || ✓
 +
|}
 +
 +
=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

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

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.

CA: TLS Zertifizierungstelle

  • Die wichtigsten Komponenten der CA

Der Server

Server: TLS PrivKey Server

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

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

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.

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

CA: Zertifikat wird zum Server geschickt

  • Der Server bekommt das Zertifikat zugestellt.

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.

Authenzitätstest

Client: Hat das Zertifikat der Zertifizierungsstelle eingebaut

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

Client:Bekommt das Zertifikat des Servers

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

Client: Überprüft ob das Zertifikat authentisch ist

Zertfikatscheck

TLS 1.2 Handshake

RSA

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)
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

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

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)

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
Abgerufen von „http://xinux.net/index.php?title=TLS_Vortrag_Wiki&oldid=70665“