Ing. Calogero Bono
Cloudflare hat eine Folgeanalyse zu den acht schwachen kryptografischen Schlüsseln der indischen Zertifizierungsstelle eMudhra veröffentlicht, die am 19. Oktober 2026 entdeckt wurden. Laut dem Unternehmen sind die kritischsten Systeme bereits geschützt, und es gibt keine Hinweise auf Abfangen der eigenen Verbindungen. Dennoch sind gefälschte Zertifikate innerhalb weniger Stunden aufgetaucht, und viele Browser, Bots und eingebettete Apps akzeptieren die kompromittierte Kette weiterhin. Für alle, die Websites und Online-Dienste betreiben, ist das Risiko nicht theoretisch.
Ein paar Begriffe, bevor wir in die Fakten einsteigen. CA (Certificate Authority) ist die Stelle, die die Zertifikate ausstellt, auf denen das HTTPS-Schloss beruht. Zwischenschlüssel ist der Schlüssel, mit dem die CA die Zertifikate der Websites signiert. CRL ist die Liste der widerrufenen Zertifikate. Certificate Transparency ist das öffentliche Register der ausgestellten Zertifikate, und die SCTs sind deren Belege. SAN und SNI bezeichnen die Domainnamen im Zertifikat und den vom Client angefragten Namen.
Was ist mit den eMudhra-Schlüsseln passiert?
Laut Cloudflare hätte eMudhra für den Schutz seiner Schlüssel eine Zahl mit 115 Stellen wählen müssen, hat aber die Zahl 4 verwendet. Die anderen sieben Schlüssel waren ähnlich schwach, mit Werten wie 56, 66, 115, 155, 156, 230 und 237.
Cloudflare erklärt, dass sich die Zwischenschlüssel fast sofort von jedem aus den öffentlichen Zertifikaten rekonstruieren lassen. Jeder kann daher Zertifikate für beliebige Domains erstellen, die ein nicht aktualisierter Client ohne Certificate-Transparency-Prüfung akzeptieren würde.
Für das Unternehmen ist der Fall ohne Vorbild. Vorfälle wie DigiNotar, TÜRKTRUST und TrustWave hatten die Macht, gefälschte Zertifikate auszustellen, nur wenigen Akteuren gegeben.
Wie hat Cloudflare reagiert?
Am 19. Oktober begannen die Patches auf den Systemen mit hohem Einfluss, zuerst bei den Pingora-Proxys zu den Servern der Kunden, die den größten Teil der ausgehenden Verbindungen abwickeln. Innerhalb weniger Stunden lehnten sie die verwundbaren Schlüssel ab.
Parallel fand eine KI-gestützte Codeanalyse innerhalb von vier Stunden die anderen Systeme, die diesen Schlüsseln vertrauten. Für jedes wurde ein Ticket eröffnet. Dringende Maßnahmen mussten sofort erfolgen, die übrigen bis zum Ende der vergangenen Woche. Zum Zeitpunkt der Veröffentlichung bleiben einige Tickets mit geringer Auswirkung offen.
Wurden die Schlüssel schon zur Fälschung von Zertifikaten genutzt?
Ja, laut Cloudflare. Seit dem 21. Oktober erfasst ein Log in Pingora die mit den schwachen Schlüsseln signierten Zertifikate. In etwa einer Woche zählte es rund 22.000 Handshake-Versuche. Zwei Drittel richteten sich an Testseiten, fast alle übrigen an Server, die sich offenbar selbst ein Zertifikat mit dem schwachen Zwischenschlüssel erstellt hatten. Jeder Handshake mit aktiver Prüfung wurde abgelehnt.
Rund 160 Fälle waren auffällig, mit Domainnamen anderer Organisationen, einige verbunden mit IoT-Geräten für Verbraucher. Einige Zertifikate waren über zwei Jahre gültig, länger als eine öffentliche CA ausstellen darf. Eines stammt vom 20. Oktober um 18:19 UTC, weniger als eine Stunde nach der Meldung von Mozilla.
Für Cloudflare sehen diese Zertifikate jedoch wie Standardzertifikate von Servern aus und nicht wie Abfangversuche. Der Fall ähnelt anderen, bei denen eine Schwachstelle sofort abgetastet wurde, etwa dem Fall Oracle E-Business Suite.
Wie viele Besucher sind noch verwundbar?
Cloudflare kann Besucher nicht direkt testen, ohne Verbindungen zu unterbrechen. Deshalb hat es den Verifizierungsseiten zwei Sonden hinzugefügt, eine mit eMudhra-Zertifikat und eine als Kontrolle. In einer Woche sammelte es 50 Millionen Messungen.
Das Bild, das sich ergibt, sieht so aus.
- Moderne, aktualisierte Browser sind größtenteils geschützt.
- Bots und alte Browser nicht.
- Apps mit eingebettetem Browser, etwa Android WebView, akzeptieren die Kette in 30 bis 40 Prozent der Fälle weiterhin.
- In großen Netzen akzeptiert über die Hälfte der Sonden die kompromittierte Kette.
Nach einigen Fortschritten am ersten Wochenende ist der Trend nun flach. Der Datenverkehr ist jedoch durch nicht bestätigte Bots verzerrt, und nur Clients, die JavaScript ausführen, senden Sonden.
Grenzen, die du kennen solltest
eMudhra gibt einen Fehler in einem Skript zur Schlüsselerzeugung zu, hat ihn aber noch nicht veröffentlicht. Ungeklärt bleiben die Rolle von Prüfern und Cross-Signern und warum eine CRL zuerst mit einem möglicherweise korrekten und dann mit dem schwachen Schlüssel signiert wurde. Cloudflare schließt Abfangen nur auf Grundlage indirekter Signale aus. Ein gezielter Angriff ist damit nicht ausgeschlossen. Die Besucherdaten sind außerdem durch Bots verzerrt.
Was sich für alle ändert, die digital arbeiten
Wenn du Websites, Apps oder Verwaltungssoftware betreibst, prüfe, ob Server, Bibliotheken und Clients die eMudhra-Schlüssel ablehnen. Wichtig sind auch Programme, die sich mit externen Diensten verbinden, etwa mobile Apps mit WebView und automatisierte Skripte, denn sie werden oft verspätet aktualisiert. Wer unter macOS entwickelt, sollte die Anleitungen von Cloudflare genau befolgen. Wenn du ein Hosting mit verwalteten Sicherheitsupdates nutzt, kläre mit dem Anbieter den Stand des Patches. Das Thema betrifft auch alle, die Zertifikate für die digitale Signatur verwenden.
Unsere Einschätzung
Das alarmierendste Detail ist nicht der Fehler selbst, sondern die Langsamkeit der Updates. Ein Schlüssel, den jeder rekonstruieren kann, ist ein enormer Fehler, und dass über die Hälfte der Sonden die Kette weiterhin akzeptiert, zeigt ein größeres Problem – Software, die niemand aktualisiert. Der Fall erinnert daran, wie wichtig kryptografische Schlüssel sind, wie beim Malware-Fall KeyDrift bei Cisco SD-WAN. Bleibt außerdem die Frage nach dem Kontrollsystem, denn Audits und Cross-Signing haben nichts verhindert.
Häufige Fragen
Was sind die schwachen Schlüssel von eMudhra?
Es handelt sich um acht Zwischenschlüssel einer CA, die mit kleinen Zahlen wie 4 oder 56 erzeugt wurden. Deshalb kann jeder sie aus den öffentlichen Zertifikaten rekonstruieren und gefälschte Zertifikate signieren.
Wurde Cloudflare kompromittiert?
Laut Cloudflare gibt es keine Belege für ein Abfangen der eigenen Verbindungen. Die Systeme mit hoher Priorität wurden aktualisiert, und es bleiben nur wenige Tickets mit geringer Auswirkung offen.
Welches Risiko besteht für eine Website oder App?
Das hängt vom Client ab. Ein nicht aktualisierter Client ohne Certificate-Transparency-Prüfung kann gefälschte Zertifikate für beliebige Domains akzeptieren und so ein mögliches Abfangen ermöglichen.
Welche Software ist am stärksten gefährdet?
Bots, alte Browser und eingebettete Browser wie Android WebView. Bei Letzteren akzeptieren laut Cloudflare weiterhin 30 bis 40 Prozent die kompromittierte Kette.
Was sollte ich jetzt tun?
Aktualisiere deine Systeme und folge den Anleitungen auf der von Dennis Jackson betreuten Seite, die Cloudflare nennt. Wenn du unter macOS entwickelst, priorisiere diese Hinweise.
Worauf du in den nächsten Wochen im eMudhra-Fall achten solltest
Der Fall hat zwei offene Fronten, die Erklärungen von eMudhra und das Tempo der Updates. Es lohnt sich, beide im Blick zu behalten.
- Prüfe, ob eMudhra das Skript zur Schlüsselerzeugung und die Ergebnisse zu Audits und Cross-Signern veröffentlicht.
- Verfolge die Updates der Browser und Laufzeitumgebungen, die deine Apps verwenden, besonders WebViews.
- Kontrolliere in den Logs deiner Server, ob Zertifikate mit Domainnamen auftauchen, die nicht den angefragten entsprechen.
