Cipher Suite

Eine Suite ist kein Algorithmus, sondern ein Bündel. Sie legt fest, wie die Schlüssel ausgetauscht werden, wie sich die Gegenseite ausweist, womit die Nutzdaten verschlüsselt werden und wie ihre Unverändertheit belegt wird. Welche dieser Teile in einer Suite stehen, hat sich mit TLS 1.3 grundlegend geändert.

Was eine Suite benennt

In TLS 1.2 trägt der Name alle vier Bestandteile:

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
    └┬──┘ └┬┘      └┬────────┘ └┬────┘
     │     │        │           └ Hashfunktion für die Schlüsselableitung
     │     │        └ Verschlüsselung der Nutzdaten samt Betriebsart
     │     └ Authentifizierung des Servers
     └ Schlüsseleinigung

In TLS 1.3 bleiben nur zwei:

TLS_AES_128_GCM_SHA256

Schlüsseleinigung und Signaturverfahren werden dort über eigene Erweiterungen verhandelt — supported_groups und signature_algorithms. Das entkoppelt die Teile, die vorher fest verbunden waren, und reduziert die Zahl der Kombinationen drastisch: Statt hunderter Suiten in TLS 1.2 kennt TLS 1.3 eine Handvoll.

Wie die Einigung abläuft

Der Client schickt im ClientHello die Liste der Suiten, die er beherrscht, in seiner Vorzugsreihenfolge. Der Server wählt eine aus und nennt sie im ServerHello.

Wer dabei tatsächlich entscheidet, ist Konfigurationssache. Üblich und richtig ist, dass der Server seine eigene Reihenfolge durchsetzt und die des Clients nur als Angebot liest — bei Apache und nginx über SSLHonorCipherOrder beziehungsweise ssl_prefer_server_ciphers. Überlässt man die Wahl dem Client, bestimmt dessen Reihenfolge, und die ist bei alten Geräten schlecht.

Warum die Liste kurz sein soll

Eine Suite in der Liste ist eine Suite, die zum Einsatz kommen kann. Das ist der Kern des Risikos: Nicht die bevorzugte Suite entscheidet über die Sicherheit, sondern die schwächste, die noch angeboten wird.

Historisch ist das mehrfach schiefgegangen. Die absichtlich geschwächten Export-Suiten aus den neunziger Jahren blieben über Jahrzehnte in Serverkonfigurationen stehen; 2015 ließen sich Verbindungen gezielt darauf herunterhandeln, obwohl beide Seiten Besseres beherrschten. Dasselbe Muster gilt für Suiten ohne Verschlüsselung, die nur Integrität bieten, und für anonyme Suiten ohne Serverauthentifizierung.

Warum CBC verschwunden ist

In TLS 1.2 waren zwei Bauweisen zulässig: Verschlüsselung im Cipher-Block-Chaining-Modus mit anschließender HMAC-Prüfsumme, oder ein AEAD-Verfahren, das beides in einem Schritt erledigt.

Die erste Bauweise hat sich als dauerhafte Fehlerquelle erwiesen. Die Reihenfolge — erst verschlüsseln, dann prüfen — zwingt den Empfänger, Daten zu entschlüsseln, bevor er weiß, ob sie echt sind. Daraus entstand eine ganze Reihe von Angriffen, die aus Fehlermeldungen oder Laufzeitunterschieden Rückschlüsse auf den Klartext ziehen.

TLS 1.3 lässt deshalb nur noch AEAD zu. In der Praxis heißt das AES im Galois/Counter-Modus oder ChaCha20-Poly1305 — letzteres vor allem dort, wo der Prozessor keine AES-Befehle hat, etwa auf älteren Mobilgeräten.

Welche Suiten empfohlen sind

Zwei Dokumente geben die Richtung vor. RFC 9325 ist die aktuelle Empfehlung der IETF zum sicheren Einsatz von TLS und DTLS. Für den deutschen Behördenbereich und seine Dienstleister gilt Teil 2 der Technischen Richtlinie BSI TR-02102, die Suiten, Schlüssellängen und Verwendungszeiträume einzeln benennt.

Beide laufen auf dasselbe hinaus: TLS 1.3 bevorzugen, TLS 1.2 nur mit AEAD-Suiten und Schlüsseleinigung mit Perfect Forward Secrecy, alles andere abschalten.

Zwei Schreibweisen für dieselbe Suite

Eine Verwechslungsquelle in der Praxis: IANA und OpenSSL benennen Suiten unterschiedlich.

IANA     TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
OpenSSL  ECDHE-RSA-AES128-GCM-SHA256

Serverkonfigurationen verwenden meist die OpenSSL-Form, Prüfberichte und Normtexte die IANA-Form. Für TLS-1.3-Suiten gibt es zudem eigene Konfigurationsparameter, die von denen für TLS 1.2 getrennt sind — bei nginx etwa wirkt ssl_ciphers nicht auf TLS 1.3.