Cipher Suite.

Eine Cipher Suite legt das Bündel von Algorithmen fest, mit dem ein sicheres Protokoll eine Sitzung schützt. In TLS 1.2 (RFC 5246) wählt eine Suite wie TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 ECDHE für den Schlüsseltausch, RSA zur Authentifizierung, AES-128-GCM zur Verschlüsselung und SHA-256 für die PRF. TLS 1.3 (RFC 8446) vereinfacht das Modell, indem Schlüsseltausch und Signaturen getrennt vom AEAD ausgehandelt werden: Es bleiben nur fünf Suites (z. B. TLS_AES_128_GCM_SHA256, TLS_CHACHA20_POLY1305_SHA256), und jede bietet Forward Secrecy.

Warum veraltete Suites gefährlich sind. Schwache Suites haben ein Jahrzehnt praktischer Angriffe ermöglicht. RC4 wurde durch die RFC 7465 formell in TLS verboten, nachdem Verzerrungen in seinem Schlüsselstrom die Wiederherstellung von Klartext erlaubten. 3DES und andere Blockchiffren mit 64-Bit-Blöcken sind für den Geburtstagsangriff Sweet32 (CVE-2016-2183) anfällig, der nach rund 32 GB Datenverkehr unter einem Schlüssel Klartext wiederherstellt. Kryptographie in Exportqualität ermöglichte FREAK (CVE-2015-0204) und Logjam, die Verbindungen auf knackbares 512-Bit-RSA und -Diffie-Hellman herabstuften. Anonyme Suites (aDH/aECDH) verzichten vollständig auf Authentifizierung und laden zu aktivem Abfangen ein.

Härtung. Deaktivieren Sie RC4, 3DES, Export- und anonyme Suites sowie den Schlüsseltausch mit statischem RSA; bevorzugen Sie AEAD-Suites mit ECDHE (oder die TLS-1.3-Standardwerte). Werkzeuge wie Qualys SSL Labs, testssl.sh und Konfigurationsprofile von Mozilla, NIST SP 800-52r2 und dem deutschen BSI kodifizieren sichere Standardwerte.

flowchart TD
  A[Client Hello:<br/>angebotene Cipher Suites] --> B[Server wählt eine Suite]
  B --> C[Schlüsseltausch<br/>ECDHE / RSA]
  C --> D[Authentifizierung<br/>Zertifikatssignatur]
  D --> E[Verschlüsselung<br/>AES-GCM / ChaCha20]
  E --> F[Integrität<br/>AEAD-Tag / HMAC]
  F --> G[Sichere Sitzung]