Zum Hauptinhalt springen

11. Sicherheitsüberlegungen (Security Considerations)

Die Sicherheit des TLS-Protokolls basiert auf folgenden Annahmen:

11.1. Kryptografische Stärke (Cryptographic Strength)​

Die Sicherheit von TLS hängt grundlegend von der Stärke der verwendeten kryptografischen Primitive ab. Implementierer sollten:

  • Starke Verschlüsselungssuiten verwenden
  • Algorithmen mit bekannten Schwächen vermeiden (wie DES, RC4, MD5)
  • Kryptografische Bibliotheken regelmäßig aktualisieren, um bekannte Schwachstellen zu beheben

11.2. Zufallszahlengenerierung (Random Number Generation)​

Die Sicherheit des TLS-Protokolls hängt stark von kryptografisch starker Zufallszahlengenerierung ab. Implementierungen MÜSSEN (MUST):

  • Kryptografisch sichere Pseudozufallszahlengeneratoren (CSPRNG) verwenden
  • Sicherstellen, dass der Zufallszahlengenerator über ausreichende Entropiequellen verfügt
  • Den Zufallszahlengenerator regelmäßig neu initialisieren

11.3. Zertifikatsvalidierung (Certificate Validation)​

Eine ordnungsgemäße Zertifikatsvalidierung ist entscheidend zur Verhinderung von Man-in-the-Middle-Angriffen:

  • Die Integrität der Zertifikatskette überprüfen
  • Den Widerrufsstatus des Zertifikats prüfen (CRL oder OCSP)
  • Die Übereinstimmung des Hostnamens überprüfen
  • Die Gültigkeitsdauer des Zertifikats prüfen

11.4. Versions-Rollback-Angriffe (Version Rollback Attacks)​

Implementierungen MÜSSEN (MUST) Versions-Rollback-Angriffe verhindern. TLS verwendet Versionsnummern in ClientHello und ServerHello sowie verify_data in der Finished-Nachricht, um Versions-Rollback-Versuche zu erkennen.

11.5. Bekannte Angriffe (Known Attacks)​

Implementierungen sollten sich der folgenden bekannten Angriffe bewusst sein:

  • BEAST (Browser Exploit Against SSL/TLS): Angriff gegen TLS 1.0 CBC-Modus. TLS 1.2 mildert dies mit expliziten IVs ab.
  • CRIME (Compression Ratio Info-leak Made Easy): Angriff, der TLS-Kompression ausnutzt. Es wird empfohlen, TLS-Kompression zu deaktivieren.
  • Lucky 13: Timing-Angriff gegen CBC-Modus-Padding. Implementierungen sollten konstant-zeitliche Vergleiche verwenden.
  • POODLE: Angriff gegen SSL 3.0. SSL 3.0 sollte deaktiviert werden.
  • Bleichenbacher-Angriff: Angriff gegen RSA PKCS#1 v1.5 Padding. TLS 1.2 enthält Schutzmaßnahmen dagegen.

11.6. Neuverhandlung (Renegotiation)​

Neuverhandlung kann Sicherheitsrisiken einführen. RFC 5246 definiert die sichere Neuverhandlungserweiterung, um diese Probleme zu beheben. Implementierungen sollten:

  • RFC 5746 (TLS-Neuverhandlungsindikationserweiterung) implementieren
  • Neuverhandlungsanfragen sorgfältig behandeln
  • Erwägen, Neuverhandlung während sensibler Operationen abzulehnen

11.7. Denial of Service​

TLS-Handshakes sind relativ teuer (insbesondere Public-Key-Operationen). Server sollten:

  • Ratenbegrenzung implementieren
  • Erwägen, Sitzungswiederaufnahme zu verwenden, um die Anzahl vollständiger Handshakes zu reduzieren
  • Anomale Muster überwachen und erkennen

11.8. Implementierungssicherheit (Implementation Security)​

Über die Sicherheitsüberlegungen auf Protokollebene hinaus sollten Implementierungen auch:

  • Pufferüberläufe verhindern
  • Sensible Daten (Schlüssel, Klartext) sicher löschen
  • Konstant-zeitliche Vergleiche verwenden, um Timing-Angriffe zu verhindern
  • Fehlerbedingungen ordnungsgemäß behandeln

Hinweis: Für eine vollständige Sicherheitsanalyse siehe Abschnitt 11 und Anhang F von RFC 5246.

Letztes Update am