TLS Vortrag Wiki: Unterschied zwischen den Versionen
Zur Navigation springen
Zur Suche springen
| Zeile 95: | Zeile 95: | ||
=TLS 1.2 Handshake= | =TLS 1.2 Handshake= | ||
| + | |||
==RSA== | ==RSA== | ||
{{#drawio:tls-1.2-rsa-1}} | {{#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}} | {{#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== | ==Diffie-Hellman== | ||
{{#drawio:tls-1.2-dh-1}} | {{#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}} | {{#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= | =TLS 1.3 Handshake= | ||
Version vom 3. Juni 2026, 18:24 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
















