Zum Hauptinhalt springen

Anhang F. Sicherheitsanalyse (Security Analysis)

Dieser Anhang bietet eine Sicherheitsanalyse des TLS 1.2-Protokolls.

F.1. Handshake-Protokoll (Handshake Protocol)​

F.1.1. Authentifizierung und Schlüsselaustausch (Authentication and Key Exchange)​

Die Kernsicherheitsziele des TLS-Handshake-Protokolls sind:

  1. Authentifizierung: Identität der kommunizierenden Peers überprüfen
  2. Schlüsselvereinbarung: Sicher ein gemeinsames Geheimnis etablieren
  3. Integrität: Sicherstellen, dass Handshake-Nachrichten nicht manipuliert wurden

F.1.1.1. Anonymer Schlüsselaustausch (Anonymous Key Exchange)​

Anonymer Schlüsselaustausch wird NICHT empfohlen!

Anonyme Diffie-Hellman (DH_anon) Cipher Suites bieten keine Authentifizierung:

  • Anfällig für Man-in-the-Middle-Angriffe
  • Nur in spezifischen kontrollierten Umgebungen verwenden
  • Produktionsumgebungen sollten die Verwendung vermeiden

Sicherheitsrisiko:

Client <---> Angreifer <---> Server
         |         |
         Zwei separate DH-Austausche
         Client denkt, er kommuniziert mit Server
         Server denkt, er kommuniziert mit Client
         Beide kommunizieren tatsächlich mit dem Angreifer

F.1.1.2. RSA-Schlüsselaustausch und Authentifizierung (RSA Key Exchange and Authentication)​

RSA-Schlüsselaustausch bietet:

  • Server-Authentifizierung (über Zertifikat)
  • Optionale Client-Authentifizierung
  • Vertrauliche Übertragung des Pre-Master-Secrets

Sicherheitsmerkmale:

  • Serverzertifikat von vertrauenswürdiger CA signiert
  • Client überprüft Zertifikatskette
  • Pre-Master-Secret mit Server-Public-Key verschlüsselt
  • Nur Server-Private-Key-Inhaber kann entschlüsseln

Einschränkungen:

  • Bietet keine Forward Secrecy
  • Wenn Server-Private-Key kompromittiert wird, können vergangene Sitzungen entschlüsselt werden

F.1.1.3. Diffie-Hellman-Schlüsselaustausch mit Authentifizierung (Diffie-Hellman Key Exchange with Authentication)​

DHE (Ephemeral Diffie-Hellman) bietet:

  • Server-Authentifizierung
  • Forward Secrecy
  • Stärkere Sicherheitsgarantien

Sicherheitsvorteile:

  1. Forward Secrecy:

    • Jede Sitzung verwendet neue ephemerale Schlüsselpaare
    • Selbst wenn Langzeitschlüssel kompromittiert werden, bleiben vergangene Sitzungen sicher

  2. Authentifizierung:

    • DH-Parameter mit Server-Private-Key signiert
    • Client überprüft Signatur

Empfohlen: DHE- und ECDHE-Cipher-Suites (Elliptic Curve DHE) sind die empfohlene Wahl für moderne TLS-Bereitstellungen.

F.1.2. Versions-Rollback-Angriffe (Version Rollback Attacks)​

TLS verwendet mehrere Verteidigungsebenen, um Versions-Rollback zu verhindern:

  1. Version in ClientHello und ServerHello:

    • Gibt ausgehandelte Version explizit an
    • Finished-Nachricht enthält Hash dieser Werte

  2. Finished-Nachricht:

    • Enthält MAC aller Handshake-Nachrichten
    • Jede Änderung führt zum Fehlschlagen der Überprüfung

  3. TLS_FALLBACK_SCSV (RFC 7507):

    • Zusätzlicher Signalisierungsmechanismus
    • Verhindert Downgrade-Angriffe

F.1.3. Erkennung von Angriffen auf das Handshake-Protokoll (Detecting Attacks Against the Handshake Protocol)​

TLS bietet folgende Mechanismen zur Angriffserkennung:

  1. Nachrichtenintegrität:

    • Finished-Nachricht überprüft gesamten Handshake
    • PRF gewährleistet kryptographische Stärke

  2. Zertifikatsüberprüfung:

    • Vollständige Zertifikatskettenüberprüfung
    • Hostname-Prüfung
    • Widerrufsprüfung

  3. Timing-Angriffschutz:

    • Konstant-Zeit-Operationen
    • Einheitliche Fehlerbehandlung

F.1.4. Sitzungswiederaufnahme (Resuming Sessions)​

Sicherheitsüberlegungen zur Sitzungswiederaufnahme:

Sicherheitsmerkmale:

  • Verwendet Master-Secret wieder
  • Reduziert Rechenaufwand
  • Neue Zufallszahlen gewährleisten Schlüsseleinzigartigkeit

Potenzielle Risiken:

  • Sichere Speicherung von Sitzungstickets
  • Schutz von Ticket-Verschlüsselungsschlüsseln
  • Angemessene Timeout-Einstellungen

Empfehlungen:

  • Sitzungslebensdauer begrenzen
  • Ticket-Verschlüsselungsschlüssel regelmäßig rotieren
  • Sitzungswiderrufsmechanismus implementieren

F.2. Schutz von Anwendungsdaten (Protecting Application Data)​

F.2.1. Datenvertraulichkeit​

TLS bietet:

  • Starke Verschlüsselungsalgorithmen (AES usw.)
  • Einzigartiges Schlüsselmaterial pro Datensatz
  • Integritätsschutz (MAC oder AEAD)

F.2.2. Datenintegrität​

Jeder TLS-Datensatz enthält:

  • MAC (für traditionelle Cipher Suites)
  • Authentifizierungs-Tag (für AEAD-Cipher-Suites)
  • Sequenznummer (verhindert Wiederholung)

F.3. Explizite IVs (Explicit IVs)​

TLS 1.2 verwendet explizite IVs, um den BEAST-Angriff in TLS 1.0 zu adressieren:

TLS 1.0-Problem:

  • Verwendete vorherigen Chiffretextblock als IV für nächsten Datensatz
  • Vorhersehbare IV ermöglicht Chosen-Plaintext-Angriffe

TLS 1.2-Lösung:

  • Jeder Datensatz enthält zufällig generierte explizite IV
  • IV ist nicht mehr vorhersehbar
  • Mindert BEAST-Angriff

F.4. Sicherheit von zusammengesetzten Verschlüsselungsmodi (Security of Composite Cipher Modes)​

F.4.1. CBC-Modus​

Bekannte Probleme:

  • Padding-Oracle-Angriffe
  • Lucky 13 Timing-Angriff
  • BEAST-Angriff (TLS 1.0)

Gegenmaßnahmen:

  • TLS 1.2 verwendet explizite IVs
  • Konstant-Zeit-Padding-Validierung
  • Einheitliche Fehlermeldungen

F.4.2. AEAD-Modus​

Vorteile:

  • Bietet gleichzeitig Vertraulichkeit und Authentifizierung
  • Nicht von Padding-Oracle-Angriffen betroffen
  • Einfachere Implementierung
  • Bessere Leistung

Empfohlen: Moderne Bereitstellungen sollten AEAD-Cipher-Suites (GCM, CCM, ChaCha20-Poly1305) priorisieren.

F.5. Denial of Service​

TLS-Handshakes sind relativ teuer und können für DoS-Angriffe verwendet werden.

F.5.1. Angriffsvektoren​

  • Große Anzahl von Handshake-Anfragen
  • Ressourcenerschöpfung (CPU, Speicher)
  • Zertifikatsüberprüfungsaufwand

F.5.2. Mitigationsstrategien​

Serverseitig:

  • Ratenbegrenzung
  • Client-Rätsel
  • Sitzungswiederaufnahmepriorität
  • Ressourcenlimits

Netzwerkschicht:

  • SYN-Cookies
  • Verbindungslimits
  • Firewall-Regeln

F.6. Abschließende Hinweise (Final Notes)​

F.6.1. Bekannte Einschränkungen​

TLS 1.2 kann nicht verhindern:

  • Endpunkt-Kompromittierung
  • Zertifizierungsstellen-Kompromittierung
  • Schwache Passwortauswahl
  • Social-Engineering-Angriffe

F.6.2. Best Practices​

  1. Aktuell bleiben:

    • Sicherheitsankündigungen überwachen
    • Implementierungen zeitnah aktualisieren
    • Schwache Algorithmen deaktivieren

  2. Konfigurationsverwaltung:

    • Starke Cipher Suites verwenden
    • Alle Sicherheitsfunktionen aktivieren
    • Konfiguration regelmäßig prüfen

  3. Überwachung und Reaktion:

    • Sicherheitsereignisse protokollieren
    • Auf anomale Muster überwachen
    • Incident-Response-Plan vorbereiten

F.6.3. Migration zu TLS 1.3​

TLS 1.3 (RFC 8446) bietet:

  • Optimierteren Handshake
  • Stärkere Sicherheitsgarantien
  • Entfernung schwacher Algorithmen
  • Verbesserte Leistung

Empfehlung: Neue Bereitstellungen sollten die Verwendung von TLS 1.3 in Betracht ziehen, während die Abwärtskompatibilität mit TLS 1.2 beibehalten wird.

Hinweis: Für vollständige Sicherheitsanalyse und detaillierte Diskussion siehe den vollständigen Text von RFC 5246 Anhang F. Siehe auch RFC 7457 (zusammenfassende bekannte Angriffe gegen TLS und DTLS) für die neuesten Sicherheitsüberlegungen.

Letztes Update am