Cipher Suite
Kurz: Eine festgelegte Kombination aus Algorithmen (Schlüsselaustausch, Verschlüsselung, Hash-Funktion), die eine TLS-Verbindung für ihre gesamte Dauer verwendet.
Genauer: Eine Cipher Suite wie TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 legt fest: welches Verfahren für den Schlüsselaustausch genutzt wird (ECDHE), welcher Algorithmus für die Authentifizierung (RSA), welcher symmetrische Algorithmus für die eigentliche Verschlüsselung (AES-256-GCM) und welche Hash-Funktion für Integritätsprüfungen (SHA-384). Im Handshake schlägt der Client eine Liste unterstützter Cipher Suites vor, der Server wählt eine davon aus.
Im Detail
Der Name einer Cipher Suite kodiert alle vier Algorithmen in einer festen Reihenfolge:
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
| | | | |
| | | | +-- Hash-Funktion für Integrität (SHA-384)
| | | +------------ Verschlüsselung + Modus (AES-256 im GCM-Modus)
| | +---------------------- Authentifizierung/Signatur (RSA-Zertifikat)
| +----------------------------- Schlüsselaustausch (ECDHE = elliptische Kurven, Diffie-Hellman, ephemeral)
+----------------------------------- Protokoll (TLS)
Das “E” in ECDHE steht für “ephemeral” (vergänglich) — bei jeder neuen Verbindung wird ein frisches, temporäres Schlüsselpaar erzeugt, das nach der Sitzung verworfen wird. Das ist der Kern von Perfect Forward Secrecy: Selbst wenn ein Angreifer später den privaten Langzeit-Schlüssel des Servers stiehlt, kann er damit keine in der Vergangenheit aufgezeichneten Verbindungen nachträglich entschlüsseln, weil die eigentlichen Sitzungsschlüssel nie langfristig gespeichert wurden.
Der Aushandlungsprozess im Handshake läuft so ab: Der Client schickt in seinem ClientHello eine priorisierte Liste aller Cipher Suites, die er unterstützt. Der Server geht diese Liste durch und wählt die erste aus, die er selbst ebenfalls unterstützt (oder lehnt die Verbindung ab, wenn keine Übereinstimmung existiert). Veraltete, unsichere Cipher Suites (z. B. solche mit RC4 oder ohne Forward Secrecy) werden von modernen Servern absichtlich gar nicht mehr angeboten, um Downgrade-Angriffe zu verhindern, bei denen ein Angreifer versucht, die Verbindung zur Nutzung eines schwächeren Algorithmus zu zwingen.
Vereinfachte Benennung in TLS 1.3
TLS 1.3 hat die Cipher-Suite-Namen radikal vereinfacht: Weil der Schlüsselaustausch (immer ECDHE) und die Authentifizierung (immer über das Zertifikat) nicht mehr Teil der Cipher-Suite-Aushandlung sind, sondern separat verhandelt werden, bleiben nur noch drei Bestandteile im Namen übrig, z. B. TLS_AES_256_GCM_SHA384 statt der langen TLS-1.2-Namen. Das reduziert gleichzeitig die Anzahl möglicher Kombinationen drastisch — TLS 1.3 kennt nur eine Handvoll Cipher Suites, alle mit Forward Secrecy und ohne bekannte Schwachstellen, im Gegensatz zu hunderten historisch existierenden TLS-1.2-Kombinationen, von denen viele längst als unsicher gelten.
Bekannte Downgrade- und Schwachstellen-Angriffe
Die Geschichte von TLS kennt mehrere prominente Angriffe, die gezielt schwache Cipher-Suite-Bestandteile ausnutzten: BEAST (2011) nutzte eine Schwäche im CBC-Verschlüsselungsmodus bei TLS 1.0 aus, POODLE (2014) zwang Verbindungen auf das veraltete SSL 3.0 herunter, um eine ähnliche CBC-Schwäche auszunutzen, und Sweet32 (2016) betraf Cipher Suites mit 3DES, dessen kleine 64-Bit-Blockgröße bei sehr langen Verbindungen Kollisionen wahrscheinlich machte. Jeder dieser Vorfälle führte dazu, dass Browser-Hersteller und Serverbetreiber die jeweils betroffenen Cipher-Suite-Bestandteile (CBC-Modi, SSL 3.0, 3DES) aus ihren Standard-Konfigurationen entfernten — die heutige, vergleichsweise kurze Liste sicherer Cipher Suites ist das Ergebnis eines jahrzehntelangen “Ausdünnungsprozesses”.
Server-Konfiguration in der Praxis
Serverbetreiber können die eigene Cipher-Suite-Priorität konfigurieren (z. B. in nginx oder Apache) und damit steuern, welche Suite bei mehreren vom Client unterstützten Optionen bevorzugt wird. Tools wie Qualys SSL Labs’ “SSL Server Test” prüfen öffentlich erreichbare Server automatisiert auf veraltete Cipher Suites und vergeben eine Bewertung von A bis F — ein gängiger erster Schritt bei der Absicherung eines neuen Servers.
Siehe auch: Handshake Protocol, TLS