Das Schloss war gültig, die Website war falsch: die Registry-Hijacks von .gh, .sl und .as erklärt

Am 6. Oktober 2026 veröffentlichte Googles Chrome-Sicherheitsteam einen kurzen Beitrag mit trockenem Titel und alarmierendem Inhalt: Angreifer hatten die Kontrolle über drei Länderdomain-Registries übernommen, Ghanas .gh, Sierra Leones .sl und Amerikanisch-Samoas .as, autoritative DNS-Einträge geändert und gültige HTTPS-Zertifikate erhalten, für Google-Domains und für “mehrere führende globale Marken”, die Google nicht nannte. Wer auf einer der gefälschten Seiten gelandet wäre, hätte ein Browser-Schloss gesehen, an dem nichts auffällig war.

Der Vorfall lohnt ein genaues Verständnis, denn er sitzt exakt an der Stelle, an der das mentale Modell der meisten Menschen von Web-Sicherheit falsch ist. Das Schloss bedeutet nicht “dies ist die echte Website”. Es bedeutet etwas viel Engeres, und Ende September wurde die Lücke zwischen beidem zu einem operativen Angriff.

Eine Definition trägt diese ganze Seite: Ein domainvalidiertes Zertifikat beweist nur eines, nämlich dass der Antragsteller im Moment der Ausstellung das DNS der Domain kontrollierte. Wird die Registry über dem DNS gestohlen, ist der Dieb für jede automatisierte Prüfung auf der Welt der Eigentümer.

Was ist mit .gh, .sl und .as passiert?

Eine Länderdomain-Registry ist die Organisation, die die Master-Datenbank für alles unter ihrer Zwei-Buchstaben-Domain führt: .gh betreibt Network Computer Systems in Accra, .sl der Telekommunikationskonzern Sierratel, .as die AS Domain Registry. Wer diese Datenbank kompromittiert, muss keine einzige Website mehr hacken, denn er kann jeden Namen unter der TLD auf Server umdelegieren, die er selbst kontrolliert.

Genau das geschah, eine Registry nach der anderen. Zertifikate tauchten in den öffentlichen Logs auf, für .gh-Namen am 22. September, für .sl am 25. September und für .as am 27. September, was sich liest wie eine Crew, die eine Liste abarbeitet. Google sagt, die Angreifer hätten “autoritative DNS-Einträge geändert und nicht autorisierte HTTPS-Zertifikate erlangt, die mehrere Google-Domains sowie Domains anderer Organisationen abdecken”, und die eigenen Systeme seien nicht berührt worden.

Bemerkenswert viel bleibt unveröffentlicht: wie die Registries geknackt wurden, wer es war, ob irgendein Zertifikat gegen echte Nutzer eingesetzt wurde, und die vollständige Opferliste. Keiner der drei Registry-Betreiber hatte zum Zeitpunkt dieses Textes eine Stellungnahme veröffentlicht. Wir schreiben “nicht offengelegt”, wo das der Stand der Dinge ist, und das sollte jeder Bericht tun, den Sie lesen.

Wie kamen Angreifer an gültige Zertifikate für Google-Domains?

Indem sie höflich fragten. The Hacker News zählte, gestützt auf das öffentliche Certificate-Transparency-Verzeichnis, mindestens 12 Zertifikate für 7 Google- und YouTube-Domains, darunter google.com.gh, google.sl, google.as und Varianten: 11 ausgestellt von Let’s Encrypt und 1 von ZeroSSL, alle domainvalidiert. Ein Let’s-Encrypt-Mitarbeiter bestätigte die Ausstellung und die Widerrufe im Forum des Projekts.

Hier kommt der unbequeme Teil: Die CAs folgten ihren Regeln. Google selbst schrieb, es gebe “keinen Grund zu der Annahme, dass die Zertifizierungsstellen (CAs), die die betroffenen Zertifikate ausgestellt haben, etwas falsch gemacht haben”. Die Domain-Validierung verlangt vom Antragsteller den Nachweis der Kontrolle über das DNS der Domain, typischerweise durch Veröffentlichen eines Eintrags. Die Angreifer waren das DNS. Jede automatisierte Prüfung, der sie gegenüberstanden, bestanden sie ehrlich, in dem engen Sinn, in dem Maschinen Ehrlichkeit verstehen.

Ein Detail zeigt, wie Wachsamkeit auf dieser Ebene aussieht: In den geprüften Log-Einträgen, zurück bis mindestens zum 10. September, stammte jedes andere Zertifikat für google.com.gh, google.sl und google.as von Google Trust Services, Googles eigener CA. Zwölf Zertifikate von zwei unbeteiligten CAs waren selbst die Anomalie, abgelegt in einem öffentlichen Log, wartend darauf, dass jemand hinsieht.

Wer hat es bemerkt, und wie wurde es gestoppt?

Drei Mechanismen, geordnet nach Geschwindigkeit.

Erstens machte Certificate Transparency die Zertifikate überhaupt erst sichtbar. Seit dem 30. April 2018 lehnt Chrome jedes Zertifikat ab, das nicht in öffentlichen CT-Logs offengelegt ist, sodass ein Angreifer, der ein im meistgenutzten Browser der Welt funktionierendes Zertifikat will, der Welt zugleich ein signiertes Geständnis seiner Existenz aushändigen muss. Der öffentliche Zähler des Ökosystems steht bei über 2,5 Milliarden protokollierten Zertifikaten, und Let’s Encrypt allein überschritt Ende September 2025 die zehn Millionen an einem einzigen Tag ausgestellten Zertifikate; 12 schlechte in diesem Heuhaufen zu finden ist genau das, wofür die Log-Infrastruktur da ist.

Zweitens blockierte Chrome die Zertifikate über CRLSets, seine Notfall-Sperrliste, die über den Komponenten-Updater des Browsers ausgeliefert wird und ohne Update oder Neustart wirkt. Chromes Sicherheitsteam argumentiert seit Jahren, dass Online-Widerrufsprüfungen genau dann versagen, wenn man sie braucht, weil der Angreifer in der Mitte die Prüfung selbst blockieren kann; die Sperrliste reist stattdessen mit dem Browser. Google durchkämmte anschließend die CT-Daten nach weiteren Opfern, blockierte auch diese Zertifikate und sagt, es habe die betroffenen Organisationen kontaktiert, wo es konnte.

Drittens der langsame Weg, der alle anderen abdeckt: Die CAs widerriefen alle 12 Zertifikate, die beiden .gh-Zertifikate und das einzelne ZeroSSL-Zertifikat am 26. September, die übrigen neun am 1. Oktober. Das kürzeste Fenster zwischen dem Auftauchen eines Zertifikats im Log und seinem Ende betrug etwa anderthalb Tage; das längste fast eine Woche. Googles eigene Ehrlichkeitsklausel verdient das Zitat: “Wir können nicht garantieren, dass unsere Analyse jede betroffene Domain identifiziert hat, noch schützen Chrome-Interventionen Nutzer anderer Browser zuverlässig.”

Hätten DNSSEC oder CAA-Einträge das verhindert?

Dieser Vorfall ist die sauberste Demonstration seit Jahren, was diese beiden Kürzel einem einbringen und was nicht.

DNSSEC zuerst. Ein Blick in die veröffentlichte Root-Zone: .gh und .sl sind gar nicht signiert, was sie zu den vielen ccTLDs zählt, die DNSSEC nie eingeführt haben, eine Technologie mit 99 Prozent Registry-Verbreitung in Europa, aber 65 Prozent in Afrika. Und .as ist signiert und wurde trotzdem gekapert. DNSSEC erlaubt einem Resolver zu prüfen, ob eine Antwort dem entspricht, was die Registry veröffentlicht hat. Ist die Registry selbst feindselig, veröffentlicht sie die Daten des Angreifers, Schlüssel inklusive. Die Signatur unter einer Lüge ist immer noch eine gültige Signatur.

CAA-Einträge, mit denen ein Domain-Inhaber festlegt, welche CAs für ihn ausstellen dürfen, haben eine subtilere Form. Während des Hijacks sind sie nutzlos, denn der CAA-Eintrag lebt in genau dem DNS, das der Angreifer kontrolliert; der CAA-Standard selbst räumt ein, dass ein Angreifer, der das DNS bearbeiten kann, den Eintrag entfernen kann. Nach dem Hijack zählen sie sehr wohl, denn CAs dürfen eine abgeschlossene Validierung nach den aktuellen Regeln des CA/Browser Forum bis zu 200 Tage wiederverwenden, ein Fenster, das im März 2027 auf 100 Tage und 2029 auf 10 Tage fällt, sodass ein Angreifer, der das DNS verloren hat, aus zwischengespeicherten Prüfungen weiter frische Zertifikate prägen könnte. Zum 7. Oktober trugen alle sieben bekannten Google-Opferdomains CAA-Einträge, die nur Googles eigene CA benennen. Das ist das Schloss, das man nach genau diesem Einbruch nachrüstet, und es ist ein echtes.

Ist das schon einmal passiert?

Angriffe auf Registries und DNS-Infrastruktur sind ein Genre, keine Neuheit. Die datierte Chronik:

Unter den rund 1.400 Domains der Root-Zone sind 316 Länder-TLDs, jede an ein Land oder Territorium gebunden, jede mit eigenem Budget, eigener Governance und eigener Sicherheitslage, manche von privaten Betreibern geführt. Ghanas eigene gesetzliche Domain-Behörde steckt seit Jahren in einem öffentlichen Streit darüber, wer .gh überhaupt betreiben soll. Das Vertrauensmodell des Webs ruht zum Teil darauf, dass die am schlechtesten finanzierte dieser Organisationen ein gutes Sicherheitsteam hat.

Was hätten Sie gesehen, und was schützt Sie wirklich?

Wären Sie während des Zeitfensters auf eine der gefälschten Seiten geleitet worden, hätten Sie nichts gesehen. Ein gültiges Zertifikat, ein normales Schloss, keinerlei Warnung; wie Ars Technica es formulierte, erlaubt der Besitz solcher Zertifikate “Angreifern, die betroffene Infrastruktur kryptografisch zu imitieren”. Ob tatsächlich jemand dorthin geleitet wurde, gehört zu den nicht offengelegten Fakten.

Was die Nutzer schützte, war nichts, was ein Nutzer getan hat. Die verpflichtende CT-Papierspur legte die Zertifikate offen, CRLSets erledigten sie in Chrome ohne jedes Zutun, und der Widerruf deckte den Rest ab. Eine weitere Schicht verdient Erwähnung: native Apps, die ihre Schlüssel pinnen. Im Togo-Fall von 2017 hätte Chromes Pinning das gefälschte google.tg-Zertifikat ohnehin zurückgewiesen, und Googles eigene Apps wie viele Banking-Apps pinnen bis heute. Verteidigung in der Tiefe ist hier kein Slogan; es ist ein konkreter Stapel, und Ende September trug jede Schicht dieses Stapels Last.

Schützt ein VPN vor diesem Angriff?

Eine ehrliche Sicherheitsseite beantwortet diese Frage präzise, also hier die präzise Antwort: nein für diese Angriffsklasse, ja für ihre weit häufigeren Verwandten, und zu wissen, was was ist, ist das ganze Spiel.

Ein VPN nimmt an TLS nicht teil. Ihr Browser validiert Zertifikate gegen seinen Vertrauensspeicher in jedem Netz identisch, und diese Zertifikate waren gültig. Schlimmer noch für jedes Werkzeug unterhalb des DNS: Die Angreifer vergifteten die autoritativen Einträge bei der Registry, sodass jeder ehrliche Resolver des Planeten, die eines VPN-Anbieters eingeschlossen, die Antworten des Angreifers auslieferte. Kein VPN, unseres eingeschlossen, hätte das blockiert. Gestoppt hat es die oben beschriebene Kette aus CT, CRLSets und Widerruf.

Was ein VPN verteidigt, ist Ihre Seite der Verbindung. In einem feindseligen lokalen Netz, an einem manipulierten Hotspot oder bei einem eingreifenden ISP sitzt der Angreifer zwischen Ihrem Gerät und dem Internet, injiziert DNS-Antworten oder leitet Verkehr um. Ein VPN verlegt Ihre DNS-Auflösung und den Pfad Ihres Verkehrs in einen verschlüsselten Tunnel und verbirgt Ihren Verkehr, wie es der Leitfaden der EFF ausdrückt, vor “Ihrem ISP und dem Besitzer des lokalen Netzwerks (etwa einem Café oder Hotel)”. Das ist die alltägliche, häufige Angriffsfläche, die wir in unseren Leitfäden zur VPN-Verschlüsselung und zur Sicherheit in öffentlichem WLAN behandeln, und es ist genau die Schicht, die die Registry-Angreifer nie anfassen mussten. Die beiden Schutzmechanismen ergänzen einander, sie ersetzen einander nicht, und genau deshalb führen wir auch eine eigene ehrliche Seite darüber, was Websites trotz aktivem VPN weiterhin sehen.

Was sollten Domain-Inhaber jetzt tun?

Googles Rat an Organisationen besteht aus zwei Schritten, und er gilt für ein Unternehmen mit drei Domains genauso wie für eines mit dreitausend. Überwachen Sie die Certificate-Transparency-Logs für jede Domain, die Sie halten, geparkte und regionale eingeschlossen; die 12 gefälschten Zertifikate lagen tagelang in öffentlichen Logs, sichtbar für jeden, der hinsah. Und veröffentlichen Sie restriktive CAA-Einträge, die Ihre CA benennen, idealerweise mit ACME-Account-Bindung, damit selbst Ihre eigene CA nur an Ihr Konto ausstellt. Das Regelwerk der CAs ergänzt einen dritten Schritt: Taucht ein nicht beantragtes Zertifikat auf, reichen Sie einen Certificate Problem Report ein, den die CA nach den Baseline Requirements der Branche untersuchen und zu dem sie binnen 24 Stunden erste Ergebnisse melden muss.

Für alle anderen sind die Lehren kleiner, aber real. Halten Sie Ihren Browser aktuell, denn die Sperrliste, die Chrome-Nutzer rettete, reist mit ihm. Nehmen Sie das Schloss als das, was es ist, eine Aussage über Verschlüsselung auf dem Transportweg, nicht darüber, wer am anderen Ende sitzt. Und ordnen Sie jedes Werkzeug seiner eigenen Schicht zu: Das Zertifikatssystem authentifiziert Websites, ein VPN schützt den Weg, den Ihr Verkehr nimmt, und der September-Vorfall brauchte vom ersten ein sicheres Scheitern, während das zweite nie im Spiel war.