Zusammenfassung

  • RFC 3268 ersetzte TLS nicht durch einen neuen Aushandlungsmechanismus. Die Spezifikation fügte zwölf AES-Cipher-Suite-IDs zur bestehenden Liste hinzu: sechs Kombinationen aus Schlüsselaustausch und Authentisierung, jeweils mit zwei Schlüsselgrößen.
  • AES-256 allein authentisiert keinen Kommunikationspartner und schafft keine Vorwärtsgeheimhaltung. Dafür sind Handshake-Verfahren und Umsetzung entscheidend.

Der neue Algorithmus brauchte einen gemeinsamen Verhandlungsnamen

Dass AES zum Standard wurde, bedeutete noch nicht, dass zwei TLS-Endpunkte seine Parameter gemeinsam aushandeln konnten. TLS 1.0 hatte dafür bereits eine Schnittstelle: Der Client listete seine Cipher Suites in ClientHello auf, der Server wählte eine unterstützte aus. RFC 2246 definierte eine Suite als Kombination aus Schlüsselaustausch, Nutzdatenverschlüsselung und Nachrichtenauthentisierung.

RFC 3268 nutzte diese Struktur im Juni 2002 für AES-CBC mit HMAC-SHA-1. Es gab jedoch nicht bloß eine Option „AES“. Die Spezifikation umfasste sechs Handshake-Familien: RSA, statisches DH mit DSS- oder RSA-Zertifikat, ephemeres DHE mit DSS- oder RSA-Signatur sowie anonymes DH. Jede Familie erhielt Varianten mit 128- und 256-Bit-AES-Schlüsseln. Daraus entstanden zwölf Kennungen.

Die Matrix bewahrte wichtige Unterschiede. RSA, authentisiertes DH und anonymes DH werden nicht durch dieselbe Blockchiffre zu gleichartigen Sicherheitsverfahren. DHE kann Vorwärtsgeheimhaltung bieten, wenn ephemere Schlüssel nur einmal verwendet, sicher gelöscht und mit geeignetem Zufall erzeugt werden. Anonymes DH authentisiert den Partner nicht und bleibt für Man-in-the-Middle-Angriffe anfällig, sofern kein anderes Verfahren beide Seiten an dieselbe TLS-Finished-Nachricht bindet. Die AES-Schlüssellänge beantwortet diese Fragen nicht.

AES erlaubt 128-, 192- und 256-Bit-Schlüssel; RFC 3268 definierte nur 128 und 256 Bit, um eine weitere Vermehrung der Suite-Namen zu vermeiden. Alle zwölf Varianten verwenden den 128-Bit-Block von AES. Mehr Schlüsselbits bedeuten keinen größeren Block. CBC und SHA-1 in HMAC gehören ebenfalls zum Paket. „AES“ bezeichnete nur einen Baustein.

Kompatibilität vergrößerte die Auswahlfläche

Die Einleitung verwies darauf, dass verfügbare DHE-Suites damals vor allem Triple-DES nutzten und daneben Exportvarianten mit unzureichender Schlüssellänge existierten. AES konnte hinzukommen, ohne ClientHello oder TLS-1.0-Aushandlung zu ersetzen. Jede neue Kombination brauchte allerdings eine eigene Kennung, Richtlinie und Implementierung.

Ein IANA-Eintrag belegt weder Produktunterstützung noch Präferenz oder tatsächliche Aushandlung. Spätere Versionen zeigen, wie sich die Grenze verschob: Viele TLS-1.2-Suites bündelten weiterhin mehrere Entscheidungen; bei TLS 1.3 steht die Suite für AEAD-Algorithmus und Hash, während Schlüsselaustauschgruppen und Signaturalgorithmen getrennt ausgehandelt werden. RFC 3268 dokumentiert deshalb nicht nur die Einführung von AES, sondern auch die Platzierung kryptografischer Entscheidungen in TLS.

Die historische Lehre ist nüchtern: Algorithmus, Schlüsselgröße, Authentisierung, Schlüsselaustausch und Record-Schutz beantworten verschiedene Fragen. Eine Cipher Suite ist ein ausgehandeltes Paket. Ein einzelnes Wort daraus als Sicherheitsurteil über die Verbindung zu lesen, verwechselt Teil und Ganzes.

Quellen