TLS-Cipher-Suites mit Namen in OpenSSL, GnuTLS und NSS

TLS_NULL_WITH_NULL_NULL

Die Platzhalter-Suite einer Verbindung, bevor der erste Handshake abgeschlossen ist: kein Schlüsselaustausch, keine Authentifizierung, kein Schutz.

TLS_NULL_WITH_NULL_NULL (0x00,0x00) beschreibt den Anfangszustand einer Verbindung unter TLS 1.2 (RFC 5246 §6.1). Die Suite wird nie ausgehandelt; ein Server, der sie auswählt, hat einen schweren Fehler.

TLS_RSA_WITH_RC4_128_SHA

RC4 mit SHA-1 und RSA-Schlüsseltransport, einst eine beliebte Wahl gegen BEAST, heute durch RFC 7465 verboten.

RC4 entging den CBC-Angriffen von 2011–2013 und wurde deshalb kurzzeitig empfohlen, doch durch die Verzerrungen seines Schlüsselstroms können Angreifer Klartext wiederherstellen, der wiederholt gesendet wird, etwa Cookies. Laut RFC 7465 §2 dürfen Clients keine RC4-Suiten in das ClientHello aufnehmen und Server keine auswählen (MUST NOT).

TLS_RSA_WITH_3DES_EDE_CBC_SHA

Die Suite, die TLS 1.1 für alle Implementierungen vorschrieb; ihre 64-Bit-Blöcke machten sie anfällig für den Geburtstagsangriff Sweet32.

RFC 4346 §9 verlangte, dass Implementierungen von TLS 1.1 TLS_RSA_WITH_3DES_EDE_CBC_SHA (OpenSSL: DES-CBC3-SHA) unterstützen. Triple DES hat 64-Bit-Blöcke, daher geben Kollisionen nach etwa 2^32 Blöcken unter einem Schlüssel Klartext preis; der Angriff Sweet32 von 2016 hat auf diese Weise HTTP-Cookies aus langlebigen Verbindungen wiederhergestellt.

Außerdem bietet die Suite keine Forward Secrecy. Moderne Bibliotheken deaktivieren sie standardmäßig, und die IANA rät mit der Einstufung Discouraged von ihr ab.

TLS_RSA_WITH_AES_128_CBC_SHA

Die Suite, die TLS 1.2 für alle Implementierungen vorschrieb; sie hat keine Forward Secrecy, nutzt CBC und ist nach RFC 10015 inzwischen verboten.

RFC 5246 §9 verlangte, dass jede Implementierung von TLS 1.2 TLS_RSA_WITH_AES_128_CBC_SHA (OpenSSL: AES128-SHA) unterstützt; deshalb ist diese Suite bei vielen alten Clients die letzte Rückfalloption. Beim RSA-Schlüsseltransport verschlüsselt der Client das Premaster Secret mit dem Schlüssel aus dem Serverzertifikat: Wer diesen Schlüssel später erlangt, kann jede aufgezeichnete Sitzung entschlüsseln.

CBC mit MAC-then-Encrypt machte die Suite anfällig für Padding-Oracle-Angriffe wie Lucky Thirteen. RFC 10015 §4 legt inzwischen fest, dass Clients Suiten mit RSA-Schlüsselaustausch in TLS 1.2 nicht anbieten und Server sie nicht auswählen dürfen (MUST NOT).

TLS_EMPTY_RENEGOTIATION_INFO_SCSV

Ein Signalwert, keine echte Suite: Der Client unterstützt sichere Renegotiation (RFC 5746).

Clients setzen TLS_EMPTY_RENEGOTIATION_INFO_SCSV (0x00,0xFF) in die Cipher-Liste, um Unterstützung für sichere Renegotiation zu signalisieren, ohne eine Erweiterung zu senden. RFC 5746 §3.3 führte den Wert ein, weil manche Server Erweiterungen falsch behandelten; er „kann nicht ausgehandelt werden“. Die Korrektur der Renegotiation beseitigte den Angriff von 2009, bei dem ein Angreifer eigene Daten vor die neu ausgehandelte Sitzung eines Clients setzte.

TLS_AES_128_GCM_SHA256

Die Cipher Suite, die jede Implementierung von TLS 1.3 unterstützen muss: AES-128 im GCM-Modus mit SHA-256 für den Key Schedule.

RFC 8446 §9.1 macht TLS_AES_128_GCM_SHA256 für Implementierungen von TLS 1.3 zur Pflicht, und der Nachfolger RFC 9846 behält diese Anforderung bei. In TLS 1.3 nennt eine Suite nur das AEAD-Verfahren und den Hash für HKDF; Schlüsselaustausch (zum Beispiel X25519MLKEM768) und Signatur (zum Beispiel ecdsa_secp256r1_sha256) werden in eigenen Erweiterungen ausgehandelt.

OpenSSL konfiguriert die Suiten von TLS 1.3 mit -ciphersuites, nicht mit dem für TLS 1.2 verwendeten String -cipher; deshalb bleibt TLS 1.3 oft unberührt, wenn du die Cipher-Liste eines Servers änderst.

TLS_AES_256_GCM_SHA384

AES-256-GCM mit SHA-384, eine der beiden Suiten von TLS 1.3, die Implementierungen laut RFC 8446 unterstützen sollten (SHOULD).

TLS_AES_256_GCM_SHA384 kombiniert einen 256-Bit-AES-Schlüssel mit SHA-384 im Key Schedule. RFC 8446 §9.1 führt die Suite zusammen mit TLS_CHACHA20_POLY1305_SHA256 als SHOULD; die meisten Server bieten sie an, und an CNSA ausgerichtete Profile verlangen sie.

Der Grover-Algorithmus würde die effektive Schlüssellänge von AES gegenüber einem Angreifer mit Quantencomputer bestenfalls halbieren, daher behält AES-256 einen großen Spielraum; das NIST hält auch AES-128 für ausreichend, weil sich solche Angriffe schlecht parallelisieren lassen.

TLS_CHACHA20_POLY1305_SHA256

ChaCha20-Poly1305, die Suite von TLS 1.3, die auf Geräten ohne AES-Befehle in Software schnell läuft.

TLS_CHACHA20_POLY1305_SHA256 verwendet die Stromchiffre ChaCha20 mit dem Authenticator Poly1305 (RFC 8439). Die Suite läuft ohne Hardwareunterstützung in konstanter Zeit und wurde deshalb zur bevorzugten Suite auf Mobilgeräten ohne AES-Befehle; Server richten sich meist nach einem Client, der sie an erster Stelle nennt.

Laut RFC 8446 §9.1 sollten (SHOULD) Implementierungen von TLS 1.3 diese Suite unterstützen. Die Gegenstücke in TLS 1.2 sind TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 und TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (RFC 7905).

TLS_AES_128_CCM_SHA256

AES-128-CCM für TLS 1.3, eingesetzt vor allem in ressourcenbeschränkten Geräten, die bereits Hardware für AES-CCM haben.

CCM kombiniert eine AES-CTR-Verschlüsselung mit einem AES-CBC-MAC und ist in IoT-Funkmodulen verbreitet. Die IANA kennzeichnet TLS_AES_128_CCM_SHA256 als empfohlen, TLS_AES_128_CCM_8_SHA256 dagegen nicht: Dessen 8-Byte-Tag empfiehlt die IANA nicht für den allgemeinen Einsatz.

TLS_FALLBACK_SCSV

Ein Signalwert, der einem Server mitteilt, dass der Client es mit einer niedrigeren Protokollversion erneut versucht (RFC 7507).

Clients, die fehlgeschlagene Handshakes mit älteren Protokollversionen wiederholten, konnte ein Angreifer bis auf SSL 3.0 herunterdrücken – das nutzte POODLE 2014 aus. Bei einem solchen erneuten Versuch sendet ein Client TLS_FALLBACK_SCSV (0x56,0x00); ein Server, der eine höhere Version unterstützt, als der Client anbietet, bricht dann mit inappropriate_fallback ab, statt fortzufahren. Der Sentinel-Wert für Downgrades, den TLS 1.3 in ServerHello.random setzt, macht den Mechanismus zwischen Gegenstellen mit TLS 1.3 überflüssig.

TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256

Die gängige Suite von TLS 1.2 für ECDSA-Zertifikate: ECDHE-Schlüsselaustausch, ECDSA-Authentifizierung und AES-128-GCM.

TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (RFC 5289) bietet Forward Secrecy durch einen ephemeren Schlüssel für ECDHE und authentifiziert den Server mit einem ECDSA-Zertifikat, meist auf P-256. Browser bevorzugen diese Suite unter TLS 1.2, wenn der Server ein ECDSA-Zertifikat hat.

In Cipher-Strings von OpenSSL heißt die Suite ECDHE-ECDSA-AES128-GCM-SHA256. Ein Server, der nur ein RSA-Zertifikat hat, kann sie nicht aushandeln – der Authentifizierungsteil einer Suite von TLS 1.2 muss zum Schlüsseltyp des Zertifikats passen.

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

Die Suite von TLS 1.2, die HTTP/2 vorschreibt: ECDHE-Schlüsselaustausch, RSA-Authentifizierung und AES-128-GCM.

RFC 9113 §9.2.2 verlangt von Diensten, die HTTP/2 über TLS 1.2 betreiben, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 mit der Kurve P-256 zu unterstützen, damit ein Client und ein Server, die beide die Einschränkungen von HTTP/2 für TLS 1.2 einhalten, immer eine gemeinsame Suite haben.

OpenSSL nennt die Suite ECDHE-RSA-AES128-GCM-SHA256. Trotz des Namens signiert der RSA-Schlüssel nur den Handshake; der Sitzungsschlüssel stammt aus dem ephemeren ECDHE-Austausch, daher bietet die Suite Forward Secrecy.

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

Die 256-Bit-Variante der häufigsten Suite von TLS 1.2: ECDHE, RSA-Authentifizierung, AES-256-GCM und die PRF mit SHA-384.

Fast jeder Server mit TLS 1.2 und RSA-Zertifikat bietet TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (RFC 5289) an. Das SHA384 im Namen legt den Hash der PRF von TLS 1.2 fest; GCM selbst braucht keinen separaten MAC.

TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256

ChaCha20-Poly1305 für TLS 1.2 mit ECDHE-Schlüsselaustausch und einem ECDSA-Zertifikat (RFC 7905).

Diese Suite kam 2016 zu TLS 1.2 hinzu und brachte das softwarefreundliche AEAD-Verfahren ChaCha20-Poly1305 auf Server, die TLS 1.3 noch nicht anbieten konnten. Die IANA kennzeichnet sie als empfohlen. OpenSSL nennt sie ECDHE-ECDSA-CHACHA20-POLY1305.