TLS Vortrag Wiki: Unterschied zwischen den Versionen
Zur Navigation springen
Zur Suche springen
| (3 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt) | |||
| Zeile 91: | Zeile 91: | ||
{{#drawio:Autenzitaetstest}} | {{#drawio:Autenzitaetstest}} | ||
| − | =Zertfikatscheck= | + | ==Zertfikatscheck== |
{{#drawio:Zertfikatscheck}} | {{#drawio:Zertfikatscheck}} | ||
=TLS 1.2 Handshake= | =TLS 1.2 Handshake= | ||
| + | |||
| + | ==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== | ||
{{#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= | ||
| Zeile 138: | Zeile 169: | ||
* Sitzungsschlüssel werden nach erfolgreichem Finished aktiviert | * Sitzungsschlüssel werden nach erfolgreichem Finished aktiviert | ||
* Verschlüsselte Kommunikation beginnt | * 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
















