TLS-Cipher-Suites härten und überwachen

Was eine Cipher-Suite überhaupt festlegt

Eine Cipher-Suite ist die Liste der kryptografischen Bausteine, auf die sich Client und Server beim TLS-Handshake einigen. Sie umfasst klassischerweise vier Komponenten: das Schlüsselaustausch-Verfahren, die Authentifizierung des Servers, das Verschlüsselungs-Verfahren für die eigentlichen Nutzdaten und die Funktion zur Integritätsprüfung. Bei TLS 1.2 stehen alle vier in einem Namen wie ECDHE-RSA-AES128-GCM-SHA256: ECDHE für den Schlüsselaustausch mit Forward Secrecy, RSA für die Authentifizierung, AES-128 im GCM-Modus für die Verschlüsselung und SHA-256 für die Integrität. Welche Komponente schwach ist, entscheidet über das Gesamtrisiko der Verbindung - und genau das macht die Bewertung einer Suite anhand ihres Namens für Laien so schwer.

Mit TLS 1.3 wurde dieses Modell radikal vereinfacht. Der Standard erlaubt nur noch fünf Cipher-Suites, und alle nutzen ausschließlich Authenticated Encryption with Associated Data (AEAD) - also Verschlüsselung und Integritätsprüfung in einem Schritt (Web Almanac 2025). Veraltete Konstruktionen wie statisches RSA, reine CBC-Modi oder Stromchiffren wie RC4 sind in TLS 1.3 gar nicht mehr vorgesehen. Das ist der eigentliche Sicherheitsgewinn der Version - nicht ein einzelnes neues Feature, sondern das konsequente Entfernen schwacher Optionen. Diese Reduktion ist in der TLS-1.3-Spezifikation festgeschrieben (RFC 8446). Wie sich die Protokollversionen im Detail unterscheiden, vertieft der Beitrag zum Vergleich von TLS 1.2 und TLS 1.3.

Das Problem liegt selten in TLS 1.3 selbst, sondern im parallelen Weiterbetrieb älterer Protokolle. Damit ältere Clients eine Seite weiterhin erreichen, halten viele Server TLS 1.2 aktiv - und damit die gesamte Bandbreite von dessen Cipher-Suites, von stark bis bedenklich. Ein Server kann gleichzeitig modernes TLS 1.3 mit AEAD und ein angreifbares 3DES-Verfahren über TLS 1.2 anbieten. Welche Suite am Ende genutzt wird, entscheidet der Handshake - und ein Angreifer mit Position im Netzwerkpfad versucht genau, diese Aushandlung auf die schwächste verfügbare Option zu lenken. Solange diese Option überhaupt angeboten wird, bleibt sie ein offenes Tor.

Welche Cipher-Suites heute als schwach gelten

Nicht jede Suite, die ein Server technisch anbietet, ist auch sicher. Die folgende Übersicht ordnet die wichtigsten Kategorien ein - von den heute empfohlenen Verfahren bis zu denen, die abgeschaltet gehören. Die Bewertung orientiert sich an den Empfehlungen der einschlägigen technischen Richtlinien und an den Grading-Kriterien etablierter Testverfahren.

Die Begründungen sind gut dokumentiert. RC4 gilt seit Jahren als gebrochen, weil die Stromchiffre statistische Verzerrungen aufweist, die sich zur Wiederherstellung von Klartext ausnutzen lassen. 3DES arbeitet mit einer effektiven Blockgröße von 64 Bit und ist dadurch für den Sweet32-Angriff anfällig, bei dem ein Angreifer aus genügend mitgeschnittenem Verkehr Teile des Klartextes rekonstruieren kann. Cipher-Suites ohne Forward Secrecy - etwa solche mit statischem RSA-Schlüsselaustausch - haben einen anderen Mangel: Wird der private Serverschlüssel jemals kompromittiert, lassen sich damit rückwirkend alle früher aufgezeichneten Verbindungen entschlüsseln. Forward Secrecy über ephemere Schlüssel verhindert genau das, weil für jede Sitzung ein neuer, kurzlebiger Schlüssel ausgehandelt wird.

Die gute Nachricht: Der Anteil sicherer Verfahren wächst. Laut Web-Almanac-Auswertung läuft der überwiegende Teil der Anfragen heute über GCM-Cipher mit AEAD, und ein großer Teil nutzt Forward Secrecy (Web Almanac 2025). Auch die TLS-1.3-Verbreitung steigt: Cloudflare Radar weist einen TLS-1.3-Request-Anteil von über 70 % aus (Cloudflare Radar). Die schwachen Verfahren sind also klar in der Minderheit - aber sie verschwinden nicht von selbst, und ein einzelner reaktivierter Eintrag genügt, um eine ansonsten saubere Konfiguration angreifbar zu machen.

Warum Härtung kein Einmalprojekt ist

Viele Teams härten ihre TLS-Konfiguration einmal sorgfältig, erreichen ein A- oder A-plus-Rating im Test und betrachten das Thema als erledigt. Genau hier liegt die Falle: Die Cipher-Konfiguration ist kein statischer Zustand, sondern ein bewegliches Ziel. Sie hängt von der TLS-Bibliothek (etwa OpenSSL), vom Webserver, vom Betriebssystem-Image und von der jeweiligen Default-Liste ab - und jeder dieser Bausteine wird regelmäßig aktualisiert. Eine Aktualisierung, die eigentlich der Sicherheit dient, kann dabei unbeabsichtigt eine alte Standardliste mitbringen.

Hinzu kommt der regulatorische Druck. PCI DSS 4.0 verlangt nicht nur eine starke Verschlüsselung, sondern ausdrücklich eine fortlaufend gepflegte Bestandsliste der eingesetzten Cipher-Suites mit regelmäßiger Prüfung auf schwache oder veraltete Verfahren (PCI DSS 4.0). Auch die deutsche Technische Richtlinie BSI TR-02102-2 wird regelmäßig fortgeschrieben - in der Fassung von 2026 empfiehlt sie AES-128 als langfristig sicher und AES-256 für den Schutz über 2030 hinaus, auch mit Blick auf Post-Quantum (BSI TR-02102-2). Eine einmal eingerichtete Konfiguration kann also schon durch eine neue Richtlinienfassung formal hinter den Stand der Technik zurückfallen, ohne dass sich am Server etwas geändert hat. Wer Compliance-Nachweise führen muss, braucht daher nicht nur den einmaligen Beleg, sondern die laufende Dokumentation des Ist-Zustands.

Angriffe, die schwache Suites erst ermöglichen

Schwache Cipher-Suites sind keine theoretische Schönheitsfehler-Liste, sondern die Voraussetzung für eine ganze Familie praktischer Angriffe. Die meisten davon sind sogenannte Downgrade-Angriffe: Ein Angreifer mit Position im Netzwerkpfad manipuliert den Handshake so, dass Client und Server eine schwächere Option wählen, als beide eigentlich beherrschen würden (CyberArk). Der Angreifer muss die starke Verschlüsselung gar nicht brechen - er sorgt nur dafür, dass sie nicht zum Einsatz kommt.

• POODLE - erzwingt das Herabstufen auf SSL 3.0 und nutzt dann eine Schwäche im Polster-Verfahren der CBC-Modi aus, um verschlüsselte Daten byteweise zu erraten (CyberArk).
• Sweet32 - zielt auf 64-Bit-Blockchiffren wie 3DES; aus genügend mitgeschnittenem Verkehr lassen sich Klartextteile rekonstruieren.
• Logjam und FREAK - drücken die Verbindung auf alte Export-Cipher mit absichtlich geschwächten Schlüssellängen herab, die sich mit heutiger Rechenleistung knacken lassen (weakdh.org).
• Verlust der Forward Secrecy - bei Suiten mit statischem Schlüsselaustausch kann ein später kompromittierter Serverschlüssel rückwirkend früheren Verkehr entschlüsseln.

Allen Downgrade-Angriffen ist eines gemeinsam: Sie funktionieren nur, wenn die schwache Option überhaupt angeboten wird. Bietet ein Server gar keine 64-Bit-Blockchiffre und keine Export-Suite mehr an, läuft der entsprechende Angriff ins Leere. Die wirksamste Verteidigung ist deshalb nicht ein zusätzliches Schutzsystem, sondern das konsequente Entfernen der schwachen Suites - und die laufende Kontrolle, dass sie auch entfernt bleiben. Diese Logik des Soll-Ist-Abgleichs liegt auch der Überwachung von HTTP-Security-Headern zugrunde, die etwa per HSTS das Herabstufen auf unverschlüsseltes HTTP verhindert. Verwandte Protokollfragen auf der DNS-Ebene behandelt der Beitrag zur DNSSEC-Validierung als DNS-Sicherheit - auch dort entscheidet die korrekte Aushandlung über die Vertrauenswürdigkeit.

Eine gehärtete Cipher-Konfiguration aufsetzen

Eine moderne, gehärtete Konfiguration folgt einem einfachen Grundsatz: so wenig wie nötig anbieten. TLS 1.3 wird aktiviert, TLS 1.2 bleibt für die Kompatibilität aktiv, aber mit einer eng begrenzten Suite-Liste, und alles darunter - TLS 1.1, TLS 1.0, SSL 3.0 - wird abgeschaltet. Bei TLS 1.2 bleiben ausschließlich Suiten mit ECDHE-Schlüsselaustausch und AEAD-Verschlüsselung übrig. Das folgende Beispiel zeigt eine solche Liste in der Notation eines verbreiteten Webservers.

# Protokolle: nur TLS 1.2 und 1.3
ssl_protocols TLSv1.2 TLSv1.3;

# TLS 1.2 - nur ECDHE + AEAD (GCM / ChaCha20)
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:\
ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:\
ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305;

ssl_prefer_server_ciphers on;

# entfernt: 3DES, RC4, CBC-only, statisches RSA, Export-Suiten
# TLS 1.3 verwaltet seine 5 AEAD-Suiten selbst

Wichtig ist die Reihenfolge der drei Schritte: erst die schwachen Suites entfernen, dann die Änderung deployen, dann unmittelbar prüfen, ob die Seite für alle relevanten Clients erreichbar bleibt. Ein zu aggressives Entfernen kann ältere Geräte aussperren - deshalb gehört zu jeder Härtung ein bewusster Blick auf die tatsächliche Client-Basis. Anschließend wird der erreichte Zustand als Baseline festgehalten. Diese Baseline ist der Bezugspunkt, gegen den jedes spätere Monitoring vergleicht. Wer die Zertifikatsausstellung ohnehin automatisiert, kann die Cipher-Härtung in denselben Prozess einbinden - wie sich das mit ACME lösen lässt, beschreibt der Beitrag zur SSL-Automatisierung mit ACME-Zertifikaten.

1. Schwache Suites entfernen - 3DES, RC4, reine CBC-Modi, statisches RSA und Export-Cipher aus der Liste streichen.
2. Protokolle eingrenzen - TLS 1.0 und 1.1 sowie SSL 3.0 deaktivieren, nur TLS 1.2 und 1.3 zulassen.
3. Erreichbarkeit prüfen - die Seite mit der tatsächlich relevanten Client-Basis gegentesten, bevor die Änderung dauerhaft bleibt.
4. Baseline festhalten - den sauberen Zustand als Soll-Wert speichern, an dem sich künftiges Monitoring orientiert.

Cipher-Konfiguration laufend überwachen

Eine einmalige Prüfung in einem öffentlichen Test-Tool ist eine Momentaufnahme - sie verfällt mit dem nächsten Server-Update. Weil Drift typischerweise unbemerkt durch Updates entsteht, muss die Prüfung wiederkehrend laufen und das Ergebnis gegen die freigegebene Baseline halten. Genau das leistet das XICTRAQ SSL- und TLS-Monitoring: Es baut regelmäßig echte TLS-Verbindungen zu Ihren Hosts auf, protokolliert die tatsächlich angebotenen Protokolle und Cipher-Suites und vergleicht sie mit dem zuletzt bekannten sauberen Stand. Die folgenden vier Bausteine bilden den Kern dieser Überwachung.

Weicht der aktuelle Zustand ab - taucht eine neue schwache Suite auf, antwortet ein abgeschaltetes Protokoll wieder oder verschwindet Forward Secrecy von einer Verbindung - löst das eine Benachrichtigung aus. So erfahren Sie von der Schwäche, während sie noch Stunden alt ist, statt erst beim nächsten externen Penetrationstest oder einer Compliance-Prüfung. Dasselbe Prinzip des kontinuierlichen Soll-Ist-Abgleichs liegt auch dem Monitoring von Certificate-Transparency-Logs zugrunde, das unerwartet ausgestellte Zertifikate für Ihre Domain meldet.

Cipher-Härtung als Teil der TLS-Hygiene

Cipher-Härtung ist ein Baustein einer breiteren TLS-Hygiene, die mehrere Ebenen umfasst. Das gültige Zertifikat, die korrekte Protokollauswahl, die gehärtete Cipher-Liste und die Security-Header greifen ineinander - eine Lücke an einer Stelle entwertet die Sorgfalt an den anderen. Wer alle Ebenen kontinuierlich prüfen lässt, erhält ein belastbares Gesamtbild statt vieler isolierter Momentaufnahmen. Erst dieses Zusammenspiel macht aus einzelnen Maßnahmen eine nachvollziehbare Sicherheitslinie.

Der Wert liegt vor allem im Zeitfaktor. Ohne Monitoring fällt eine reaktivierte schwache Suite erfahrungsgemäß erst auf, wenn ein externer Test oder eine Prüfung sie aufdeckt - oft Monate später. Mit laufender Überwachung wird dieselbe Abweichung innerhalb von Stunden sichtbar, meist bevor sie in einem Angriff oder Audit relevant wird. Das ergänzt die rein zertifikatsbezogene Sicht, wie sie der Beitrag dazu beschreibt, warum SSL-Zertifikats-Monitoring wichtig ist - die Gültigkeit des Zertifikats und die Stärke der Cipher sind zwei verschiedene Fragen, die beide laufend beantwortet werden sollten.

Ein Server-Update lässt sich nicht verhindern - und das soll es auch nicht, denn Updates schließen Sicherheitslücken. Was sich verhindern lässt, ist, dass ein Update unbemerkt eine schwache Cipher-Suite zurückbringt und diese monatelang aktiv bleibt. Genau dafür ist kontinuierliches TLS-Monitoring gedacht: Es macht aus der unsichtbaren Änderung in der Cipher-Liste ein sichtbares, alarmierbares Signal - und gibt der einmal investierten Härtungsarbeit eine dauerhafte Grundlage. Aus einem Einmalprojekt wird so ein dauerhaft überprüfter Zustand.

Häufig gestellte Fragen zur TLS-Cipher-Härtung