Dokumentation
Rechnernetze und Rechnernetzsicherheit
TLS Protokoll

TLS Protokoll

Teil 1: Thematischer Überblick

Was ist TLS?

TLS (Transport Layer Security) ist ein Sicherheitsprotokoll, das zwischen Application Layer und Transport Layer arbeitet. Es kombiniert verschiedene kryptographische Verfahren, um drei zentrale Sicherheitsziele zu erreichen:

  • Vertraulichkeit
    • Niemand kann mitlesen
  • Authentizität
    • Es wird mit dem richtigen Partner kommuniziert
  • Integrität
    • Daten wurden nicht manipuliert

Architektur

TLS im Netzwerk-Stack 

┌─────────────────────────┐
│   Application Layer     │  HTTP, SMTP, etc.
└─────────────────────────┘
┌─────────────────────────┐
│   TLS Layer             │  Sicherheitsschicht
└─────────────────────────┘
┌─────────────────────────┐
│   Transport Layer (TCP) │
└─────────────────────────┘

TLS Nachrichtentypen

Handshake

  • Verbindungsaufbau und Schlüsselaustausch
  • Enthält: Zertifikate, ServerKeyExchange, ClientKeyExchange
  • Wird am Ende signiert für Integrität

Alert

  • Fehlermeldungen und Warnungen während der Verbindung

Change Cipher Spec (CCS)

  • Signalisiert: “Ab jetzt läuft alles verschlüsselt”

Application Data

  • Die eigentlichen Nutzdaten (z.B. HTTP-Requests)

Record Layer

Der Record Layer ist vergleichbar mit einem Briefumschlag:

  • Nimmt verschiedene Nachrichtentypen entgegen
  • Verpackt sie in standardisierte Records
  • Verschlüsselt die Daten
  • Versendet sie über TCP
╔═════════════════════════════════════════╗
║         Application Layer               ║
║              HTTP                       ║
╚═════════════════════════════════════════╝
                  │
                  ↓
╔═════════════════════════════════════════╗
║           TLS Layer                     ║
║  ┌──────────┬───────┬──────┬──────┐     ║
║  │Handshake │ Alert │ CCS  │ App  │     ║
║  └──────────┴───────┴──────┴──────┘     ║
║ ─────────────────────────────────────── ║
║           Record Layer                  ║
║      (Verpackung & Verschlüsselung)     ║
╚═════════════════════════════════════════╝
                  │
                  ↓
╔═════════════════════════════════════════╗
║        Transport Layer                  ║
║              TCP                        ║
╚═════════════════════════════════════════╝

Authentifizierung

Zwei Arten der Server-Authentifizierung

Implizite Authentifizierung (RSA Key Exchange)

  • Client verschlüsselt Pre-Master-Secret mit Server’s Public Key
  • Nur der echte Server kann mit seinem Private Key entschlüsseln
  • Wenn die Verbindung funktioniert → Server muss authentisch sein
  • ⚠️ Veraltet, kein Perfect Forward Secrecy

Explizite Authentifizierung (ECDHE + RSA)

  • Server signiert seine DH-Parameter mit seinem privaten RSA-Schlüssel
  • Client verifiziert die Signatur mit dem Public Key aus dem Zertifikat
  • Klare Trennung zwischen Verschlüsselung und Authentifizierung
  • ✅ Modern, mit Perfect Forward Secrecy

Warum ECDHE alleine nicht reicht

Problem:

  • ECDHE ermöglicht effizienten Schlüsselaustausch
  • Aber: Jeder könnte DH-Parameter senden (Man-in-the-Middle!)
  • Keine Garantie, dass die Parameter vom echten Server kommen

RSA Signatur schließt die Lücke:

  • Server signiert seine ECDHE-Parameter mit privatem Schlüssel
  • Nur der echte Zertifikatsinhaber kann diese Signatur erstellen
  • Client verifiziert gegen vertrauenswürdiges Zertifikat

Ergebnis: Effizienter Schlüsselaustausch + vertrauenswürdige Identitätwürdiges Zertifikat

Authentizität garantiert

Client-Authentifizierung (optional)

Für sensible Anwendungen (Online-Banking, VPN):

  • Server fordert Client-Zertifikat an
  • Client sendet Zertifikat und signiert Handshake-Verlauf
  • Beide Seiten sind authentifiziert

Verschlüsselung

Zwei-Phasen-Prinzip

Warum nicht durchgehend asymmetrisch?

  • Asymmetrische Verschlüsselung (RSA, ECDHE) ist langsam
  • Symmetrische Verschlüsselung (AES) ist schnell

Lösung:

  • Phase 1 (Handshake): Asymmetrisch - sicherer Schlüsselaustausch
  • Phase 2 (Daten): Symmetrisch - schnelle Verschlüsselung großer Datenmengen

Cipher Suites

Eine Cipher Suite ist das “Verschlüsselungspaket” für eine TLS-Verbindung.

Aufbau: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

  1. TLS - Protokoll
  2. ECDHE - Schlüsselaustausch (Ephemeral Diffie-Hellman)
  3. RSA - Authentifizierung (Server signiert)
  4. AES_256_GCM - Verschlüsselung (256-Bit AES im GCM-Modus)
  5. SHA384 - MAC-Algorithmus für Integrität

Betriebsmodi

CBC (Cipher Block Chaining) - Veraltet

  • ❌ Anfällig für Padding Oracle Angriffe
  • ❌ Separater MAC-Schritt nötig

GCM (Galois/Counter Mode) - Modern

  • ✅ AEAD - kombiniert Verschlüsselung + MAC
  • ✅ Schneller und sicherer
  • ✅ Parallele Verarbeitung möglich

Integrität

HMAC (Hash-based Message Authentication Code)

HMAC stellt sicher, dass Daten nicht manipuliert wurden und vom echten Partner kommen.

Berechnung:

HMAC = Hash(Secret-Key + Nachricht + Sequence-Number)

Ablauf:

  1. Sender berechnet HMAC über verschlüsselte Nachricht
  2. Sender sendet: Verschlüsselte Nachricht + HMAC
  3. Empfänger berechnet eigenen HMAC
  4. Vergleich: HMAC == HMAC’ ?
    • ✅ Gleich → Integrität bestätigt
    • ❌ Unterschiedlich → Manipulation erkannt

Schutz vor Replay-Angriffen

Das Problem:

  • Angreifer zeichnet Nachricht auf (z.B. “Überweise 100€”)
  • Sendet sie später erneut → zweite Überweisung!

Die Lösung: Sequence Numbers

  • Client und Server zählen alle Records mit
  • Sequence Numbers werden implizit geführt (nicht übertragen)
  • Bei HMAC-Berechnung wird Sequence Number einbezogen
  • Wiederholte Nachrichten haben falschen HMAC

Perfect Forward Secrecy (PFS)

Das Problem ohne PFS

Szenario mit RSA Key Exchange:

  1. Heute: Angreifer zeichnet verschlüsselten Traffic auf
  2. 2028: Server wird gehackt, Private Key gestohlen
  3. Resultat: Angreifer entschlüsselt alle aufgezeichneten Sessions

Warum?

  • Pre-Master-Secret wurde mit Server’s Public Key verschlüsselt
  • Mit gestohlenem Private Key: Pre-Master-Secret entschlüsselbar
  • Daraus: Alle Session Keys ableitbar
  • Gesamter Traffic wird nachträglich lesbar

Die Lösung: Ephemeral Keys

ECDHE (Ephemeral Diffie-Hellman):

  • Für jede Session werden neue, temporäre DH-Schlüssel generiert
  • Diese Schlüssel werden nach der Session verworfen
  • Pre-Master-Secret wird niemals verschlüsselt übertragen
  • Beide Seiten berechnen es unabhängig aus DH-Parametern

Nach Kompromittierung:

  • ✅ Alte Sessions bleiben sicher (Schlüssel existieren nicht mehr)
  • ❌ Zukünftige Sessions gefährdet (Angreifer kann sich als Server ausgeben)

Welche Verfahren bieten PFS?

VerfahrenPFSEmpfehlung
ECDHE✅ JaVerwenden
DHE✅ JaVerwenden
RSA Key Exchange❌ NeinVermeiden
Static (EC)DH❌ NeinVermeiden

Teil 2: Der TLS-Handshake

Überblick

Der Handshake läuft in zwei Phasen ab:

Phase 1: Handshake (unverschlüsselt)

  • Verbindungsaufbau
  • Authentifizierung
  • Schlüsselaustausch
  • Session Key Ableitung

Phase 2: Datenübertragung (verschlüsselt)

  • Verschlüsselte Kommunikation mit AES
  • Integritätsschutz mit HMAC

RSA Handshake (veraltet)

Ablauf 

Client                                Server
  |                                      |
  |------- ClientHello ---------------->|
  |        (Cipher Suites)               |
  |                                      |
  |<------ ServerHello ------------------|
  |        (Gewählte Cipher Suite)       |
  |                                      |
  |<------ Certificate ------------------|
  |        (Server's Public Key)         |
  |                                      |
  |<------ ServerHelloDone --------------|
  |                                      |
  |------- ClientKeyExchange ----------->|
  |        (Encrypted Pre-Master-Secret) |
  |                                      |
  |------- ChangeCipherSpec ------------>|
  |------- Finished -------------------->|
  |        (Verschlüsselt)               |
  |                                      |
  |<------ ChangeCipherSpec -------------|
  |<------ Finished ---------------------|
  |        (Verschlüsselt)               |
  |                                      |
  |====== Application Data =============>|
  |<===== Application Data ==============|

Detaillierter Ablauf

1. ClientHello

  • Client sendet unterstützte TLS-Versionen
  • Client sendet Liste unterstützter Cipher Suites
  • Client sendet Zufallszahl (Client Random)

2. ServerHello

  • Server wählt TLS-Version
  • Server wählt Cipher Suite (z.B. TLS_RSA_WITH_AES_128_CBC_SHA)
  • Server sendet Zufallszahl (Server Random)

3. Certificate

  • Server sendet sein Zertifikat
  • Enthält Server’s öffentlichen RSA-Schlüssel
  • Client verifiziert Zertifikat gegen vertrauenswürdige CAs

4. ClientKeyExchange

  • Client generiert Pre-Master-Secret (zufällige 48 Bytes)
  • Client verschlüsselt Pre-Master-Secret mit Server’s Public Key
  • Nur Server kann mit seinem Private Key entschlüsseln
  • → Implizite Authentifizierung: Wenn’s funktioniert, ist der Server echt

5. Session Key Ableitung

  • Beide Seiten berechnen:
    • Master-Secret = PRF(Pre-Master-Secret, Client Random, Server Random)
    • Aus Master-Secret werden abgeleitet:
      • Client Encryption Key
      • Server Encryption Key
      • Client MAC Key
      • Server MAC Key

6. ChangeCipherSpec + Finished

  • Beide Seiten signalisieren: “Ab jetzt verschlüsselt”
  • Finished-Nachricht ist verschlüsselt und authentifiziert
  • Bestätigt, dass beide funktionsfähige Schlüssel haben

Nachteile des RSA Handshakes

  • ❌ Kein Perfect Forward Secrecy

  • Pre-Master-Secret wird verschlüsselt übertragen

  • Bei späterer Kompromittierung: Alle Sessions entschlüsselbar

  • ❌ Server nicht explizit authentifiziert

  • Nur implizit durch erfolgreiche Entschlüsselung

  • Keine separate Signatur

  • ❌ Langsam

  • RSA-Operationen sind rechenintensiv

ECDHE Handshake (modern)

Ablauf 

Client                                Server
  |                                      |
  |------- ClientHello ---------------->|
  |        (Cipher Suites, Client Random)|
  |                                      |
  |<------ ServerHello ------------------|
  |        (Cipher Suite, Server Random) |
  |                                      |
  |<------ Certificate ------------------|
  |        (Server's RSA Public Key)     |
  |                                      |
  |<------ ServerKeyExchange ------------|
  |        (ECDHE Params + RSA Signature)|
  |                                      |
  |<------ ServerHelloDone --------------|
  |                                      |
  |------- ClientKeyExchange ----------->|
  |        (Client's ECDHE Params)       |
  |                                      |
  |------- ChangeCipherSpec ------------>|
  |------- Finished -------------------->|
  |                                      |
  |<------ ChangeCipherSpec -------------|
  |<------ Finished ---------------------|
  |                                      |
  |====== Application Data =============>|
  |<===== Application Data ==============|

Detaillierter Ablauf

1. ClientHello

  • Client sendet unterstützte TLS-Versionen
  • Client sendet Cipher Suites (z.B. TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384)
  • Client sendet Client Random

2. ServerHello

  • Server wählt ECDHE-basierte Cipher Suite
  • Server sendet Server Random

3. Certificate

  • Server sendet Zertifikat mit RSA Public Key
  • Dieser Key wird nicht für Verschlüsselung genutzt
  • Nur für Signatur zur Authentifizierung

4. ServerKeyExchange (der Unterschied!)

  • Server generiert temporäre ECDH-Schlüsselpaar
  • Server sendet:
    • ECDHE Public Key (temporär)
    • Elliptic Curve Parameter
    • RSA-Signatur über diese Parameter
  • Client verifiziert Signatur mit Server’s RSA Public Key
  • → Explizite Authentifizierung: Server beweist Besitz des Private Keys

5. ClientKeyExchange

  • Client generiert eigenes temporäres ECDH-Schlüsselpaar
  • Client sendet eigenen ECDHE Public Key
  • Keine Verschlüsselung des Pre-Master-Secrets!

6. Pre-Master-Secret Berechnung

  • Beide Seiten berechnen unabhängig voneinander:
    • Pre-Master-Secret = ECDH(Client Private, Server Public)
    • Pre-Master-Secret = ECDH(Server Private, Client Public)
    • Beide Ergebnisse sind identisch (Diffie-Hellman Magie!)
  • Pre-Master-Secret wurde niemals übertragen

7. Session Key Ableitung

  • Wie bei RSA: Ableitung aus Pre-Master-Secret + Randoms
  • Client und Server haben separate Keys
  • Temporäre ECDH-Keys werden verworfen

8. ChangeCipherSpec + Finished

  • Verschlüsselte Bestätigung
  • Handshake abgeschlossen

Vorteile des ECDHE Handshakes

  • ✅ Perfect Forward Secrecy

  • Temporäre Keys pro Session

  • Alte Sessions bleiben sicher bei Kompromittierung

  • ✅ Explizite Authentifizierung

  • Server signiert DH-Parameter

  • Klare Trennung: Verschlüsselung vs. Authentifizierung

  • ✅ Effizienter

  • Elliptic Curves sind schneller als RSA

  • Kleinere Schlüssel bei gleicher Sicherheit

Vergleich: RSA vs. ECDHE

AspektRSA Key ExchangeECDHE
SchlüsselaustauschPre-Master-Secret verschlüsselt übertragenPre-Master-Secret gemeinsam berechnet
AuthentifizierungImplizit (durch Entschlüsselung)Explizit (durch Signatur)
Perfect Forward Secrecy❌ Nein✅ Ja
GeschwindigkeitLangsamer (RSA-Operationen)Schneller (EC-Operationen)
SchlüsselpersistenzStatischer Server-SchlüsselTemporäre Session-Schlüssel
KompromittierungAlle Sessions entschlüsselbarNur zukünftige Sessions gefährdet
Status⚠️ Veraltet✅ Modern, empfohlen

Phase 2: Verschlüsselte Datenübertragung

Nach erfolgreichem Handshake:

1. Verschlüsselung

  • Daten werden mit AES verschlüsselt
  • Symmetrischer Schlüssel aus Session Keys

2. HMAC Berechnung 

HMAC = Hash(MAC-Key + Encrypted-Data + Sequence-Number)

3. Versand

  • Record Layer verpackt: Encrypted Data + HMAC
  • Versand über TCP

4. Empfang

  • HMAC-Prüfung → Integrität verifiziert
  • Entschlüsselung → Daten lesbar

Praktische Sicherheitstipps

Protokollversion

Verwenden:

  • TLS 1.3 (schnellster Handshake, nur sichere Cipher Suites)
  • TLS 1.2 (weit verbreitet, solide)

Vermeiden:

  • SSLv2, SSLv3 - POODLE, DROWN Schwachstellen
  • TLS 1.0, TLS 1.1 - Deprecated

Cipher Suite Empfehlungen

Moderne Konfiguration:

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256

Kriterien:

  1. Schlüsselaustausch: ECDHE (für PFS)
  2. Verschlüsselung: AES-GCM oder ChaCha20 (AEAD)
  3. Minimum: 128-Bit Verschlüsselung
  4. MAC: SHA256 oder höher

Nicht verwenden:

TLS_RSA_WITH_AES_128_CBC_SHA
  • Kein PFS, CBC anfällig, schwacher MAC

Zertifikatsverwaltung

  • Regelmäßige Erneuerung (jährlich)
  • Starke Private Keys (RSA 2048-Bit oder ECDSA 256-Bit)
  • Vertrauenswürdige Certificate Authorities
  • Certificate Transparency überwachen

Zusammenfassung

TLS schützt durch drei Kernmechanismen:

  1. Verschlüsselung - AES für Vertraulichkeit
  2. Authentifizierung - Zertifikate + Signaturen für Identität
  3. Integrität - HMAC + Sequence Numbers gegen Manipulation

Best Practice:

  • Immer ECDHE-basierte Cipher Suites
  • GCM-Modus für AEAD
  • TLS 1.2 oder 1.3
  • Regelmäßige Zertifikatserneuerung