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

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