Ein Scan zeigt, dass Ihr Server noch SSLv3/TLS 1.0 und RC4 unterstützt. Was tun Sie?
Kurzantwort
SSLv3, TLS 1.0 und RC4 sind gebrochen oder veraltet und ermöglichen Downgrade- und Entschlüsselungsangriffe; deaktivieren Sie sie daher und verlangen Sie TLS 1.2 oder 1.3 mit starken, forward-secret Cipher-Suiten, wobei der seltene Verlust sehr alter Clients in Kauf genommen wird. Sie aus Kompatibilitätsgründen aktiviert zu lassen, hält die Schwäche ausnutzbar. Ein zweites Zertifikat hinzuzufügen oder auf ein selbstsigniertes zu wechseln, entfernt die schwachen Protokolle nicht, und das selbstsignierte schadet dem Vertrauen, ohne die Kryptografie zu beheben.
Ein Scan, der SSLv3, TLS 1.0 und RC4 meldet, berichtet von Kryptografie, die die Branche vor Jahren ausgemustert hat. Das sind keine theoretischen Schwächen — sie haben benannte, praktische Angriffe — daher ist der richtige Schritt, die veralteten Protokolle und Ciphers zu deaktivieren und modernes TLS zu verlangen.
Warum sie gebrochen sind
- SSLv3 ist durch POODLE fatal untergraben, womit ein Netzwerkangreifer Bytes aus einer verschlüsselten Sitzung entschlüsseln kann.
- TLS 1.0 trägt strukturelle Schwächen (z. B. BEAST) und ist durch PCI DSS sowie große Browser veraltet.
- RC4 weist Verzerrungen auf, die die Wiederherstellung von Klartext machbar machen, und ist durch RFC 7465 verboten.
Die tiefere Gefahr ist der Downgrade-Angriff: Selbst wenn ein moderner Client TLS 1.3 sprechen kann, kann ein aktiver Angreifer die Aushandlung auf die schwächste Option herunterstufen, die beide Seiten noch anbieten. Solange Ihr Server RC4 oder SSLv3 bewirbt, bleiben Sie ausnutzbar — schon die bloße Verfügbarkeit ist das Risiko.
Die richtige Lösung
Konfigurieren Sie den Server so, dass er mindestens TLS 1.2 (bevorzugt 1.3) verlangt und nur starke, forward-secret Cipher-Suiten anbietet (ECDHE-Schlüsselaustausch, AES-GCM oder ChaCha20-Poly1305). Forward Secrecy stellt sicher, dass die spätere Kompromittierung des Langzeitschlüssels des Servers zuvor mitgeschnittene Sitzungen nicht entschlüsseln kann. Validieren Sie das Ergebnis mit einem erneuten Scan. Der Kompromiss — der Verlust einer Handvoll uralter Clients — ist fast immer akzeptabel und weit günstiger als ein Vorfall.
Warum die anderen Antworten falsch sind
- „Aus Kompatibilität aktiviert lassen" bewahrt genau die Schwäche, auf die ein Angreifer herunterstuft; die Bequemlichkeit weniger Alt-Clients gefährdet alle.
- Ein zweites Zertifikat hinzuzufügen adressiert Identität/SAN-Abdeckung, nicht die Aushandlung von Protokoll und Cipher — die schwachen Optionen bleiben auf der Speisekarte.
- Auf ein selbstsigniertes Zertifikat zu wechseln ist aktiv schlimmer: Es bricht die Vertrauenskette (Browser-Warnungen, leichteres MITM), während SSLv3/TLS 1.0/RC4 voll aktiviert bleiben. Es verwechselt Zertifikatsvertrauen mit Protokollstärke.
Der Interviewer prüft, ob Sie die ausgehandelte Kryptografie beheben, das Downgrade-Risiko verstehen und einen Zertifikatswechsel nicht mit Protokollhärtung verwechseln.
Wahrscheinliche Anschlussfragen
- Welche Angriffe zielen speziell auf SSLv3 und RC4, und wie erzwingt ein Downgrade-Angriff deren Nutzung?
- Was bringt Ihnen Forward Secrecy, und welche Cipher-Suiten liefern sie?
- Wie würden Sie dies ausrollen, ohne eine kleine Gruppe von Alt-Clients zu brechen, die Sie nicht aktualisieren können?