<style> .reveal .slides { background: url(https://hedgedoc.xinux.net/uploads/xinux-weiss.png) no-repeat; background-position: right 10px bottom 10px; background-size: 80px; } .reveal ul li { font-size: 20px !important; line-height: 1.4 !important; margin-bottom: 6px !important; } .reveal .slides section { text-align: left; padding: 10px 30px !important; } .reveal h2 { font-size: 1.3em !important; } .reveal h3 { font-size: 1.1em !important; } </style> <h2 style="font-size: 1.4em; color: #fff;">TLS – Authentifizierung und Verschlüsselung im Internet</h2> <h3 style="font-size: 1.0em; font-weight: normal; color: #ccc;">Grundlagen, Public Key Infrastruktur, TLS 1.2 und TLS 1.3</h3> <p style="font-size: 1.0em; color: #fff;"><strong>Thomas Will – Xinux GmbH</strong></p> <p style="margin-top: 30px; font-size: 0.8em; color: #aaa;"> Dieser Vortrag vermittelt die technische Funktionsweise von TLS, erklärt die Rolle der PKI und analysiert Unterschiede zwischen klassischen und modernen Handshakes. </p> --- <h3 style="font-size: 1.1em;">Authentifizierung mit TLS</h3> - Public Key Infrastruktur - Zertifikatsbasierte Authentifizierung - Schlüsselbasierte Authentifizierung - Am Ende steht die verschlüsselte Übertragung --- <h3 style="font-size: 1.1em;">Public Key Infrastruktur</h3> **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 --- <h3 style="font-size: 1.1em;">Zertifikatsbasierte Authentifizierung</h3> - Nutzt Zertifikat, das von einer CA signiert ist - Client überprüft die Signatur der CA - Signatur authentifiziert das Zertifikat --- <h3 style="font-size: 1.1em;">Die CA – Erstellen einer CA</h3> - 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 --- <h3 style="font-size: 1.1em;">CA: Der private Schlüssel</h3> - Der private Schlüssel der CA muss zwingend geheim gehalten werden - Er wird nur zum Signieren gebraucht  --- <h3 style="font-size: 1.1em;">CA: Das Zertifikat</h3> - Das Zertifikat der CA ist bei offiziellen CAs überall in den Betriebssystemen eingebaut - Überall bedeutet nicht nur PCs, Laptops, Server - Sondern auch IoT-Geräte aller Art  --- <h3 style="font-size: 1.1em;">CA: TLS Zertifizierungsstelle</h3> - Die wichtigsten Komponenten der CA  --- <h3 style="font-size: 1.1em;">Der Server: TLS PrivKey</h3> - Auf dem Server wird ein privater Schlüssel erstellt - Geheimhaltung ist wichtig  <!-- 📌 DRAWIO: PrivK-Server --> --- <h3 style="font-size: 1.1em;">Server: TLS Signing Request</h3> - Es wird ein öffentlicher Schlüssel erstellt - Es wird diesem ein Distinguished Name zugeordnet - Beide Komponenten ergeben den Certificate Signing Request - Der Request wird zur Zertifizierungsstelle geschickt — Geheimhaltung nicht notwendig  --- <h3 style="font-size: 1.1em;">CA: Signierung des Requests</h3> - Hash über PubK-S + DN-S + Ablaufdatum wird gebildet - Dieser wird mit PrivK-CA verschlüsselt - Diesen Vorgang nennt man Signierung <!-- 📌 DRAWIO: TLS Zertifizierung -->  --- <h3 style="font-size: 1.1em;">CA: Bauen des Zertifikats</h3> Das Zertifikat enthält: - Öffentlicher Schlüssel des Servers (PubK-S) - Signature-S - DN-S und DN-CA - Ablaufdatum - Seriennummer <!-- 📌 DRAWIO: server-zertifikat -->  --- <h3 style="font-size: 1.1em;">CA: Zertifikat wird zum Server geschickt</h3> - Der Server bekommt das Zertifikat zurück. <!-- 📌 DRAWIO: PrivKey-S-Zertifikat-S-zu-Service -->  --- <h3 style="font-size: 1.1em;">Server: PrivKey-S und Zertifikat-S dem Service zuordnen</h3> - Das Zertifikat und der private Schlüssel werden einem oder mehreren Diensten zugeordnet  --- <h3 style="font-size: 1.1em;">Client: Hat das Zertifikat der Zertifizierungsstelle eingebaut</h3> - Jedes Gerät im Internet das TLS kann, hat das Zertifikat der Zertifizierungsstelle eingebaut <!-- 📌 DRAWIO: TLS CA Cert -->  --- <h3 style="font-size: 1.1em;">Client: Bekommt das Zertifikat des Servers</h3> - Beim TLS Handshake bekommt der Client das Zertifikat des Servers geschickt <!-- 📌 DRAWIO: server-zertifikat -->  --- <h3 style="font-size: 1.1em;">Client: Überprüft ob das Zertifikat authentisch ist</h3> <!-- 📌 DRAWIO: Autenzitaetstest -->  --- <h3 style="font-size: 1.1em;">Zertifikatscheck</h3> <!-- 📌 DRAWIO: Zertfikatscheck -->  --- <h3 style="font-size: 1.1em;">Zertifikatscheck</h3> <!-- 📌 DRAWIO: Zertfikatscheck --> --- <h3 style="font-size: 1.1em;">TLS 1.2 RSA – Handshake (1/2)</h3> <!-- 📌 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) --- <h3 style="font-size: 1.1em;">TLS 1.2 RSA – Handshake (2/2)</h3>  **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) **Nachteil** - Kein Forward Secrecy — wer später PrivK-S erhält kann alle aufgezeichneten Sessions entschlüsseln --- <h3 style="font-size: 1.1em;">TLS 1.2 DHE – Handshake (1/2)</h3>  **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 --- <h3 style="font-size: 1.1em;">TLS 1.2 DHE – Handshake (2/2)</h3>  **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 --- <h3 style="font-size: 1.1em;">TLS 1.3 – Client Hello / Server Hello / Handshake Secret</h3>  - TLS 1.3 wird angeboten, ephemerer Public Key wird mitgeschickt - Server bestätigt TLS 1.3, schickt eigenen ephemeren Public Key - Shared Secret wird lokal per (EC)DH berechnet — wird nie übertragen - Per HKDF werden Handshake Traffic Keys abgeleitet → ab jetzt alles verschlüsselt --- <h3 style="font-size: 1.1em;">TLS 1.3 – Server Handshake Nachrichten</h3>  - **EncryptedExtensions**: erste verschlüsselte Nachricht, enthält z. B. ALPN - **Certificate**: Zertifikat verschlüsselt übertragen - **CertificateVerify**: Server signiert Handshake-Transcript mit PrivK-S - **Finished**: Hash über Handshake-Transcript — Client prüft und schickt eigenen Hash zurück - Application Traffic Keys aktiv ✓ --- <h3 style="font-size: 1.1em;">TLS 1.3 – Neuerungen</h3> - 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 --- <h3 style="font-size: 1.1em;">TLS 1.2 vs. TLS 1.3</h3> <small> | 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 | ✓ | </small> --- <h3 style="font-size: 1.1em;">Zusammenfassung</h3> - 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