Ein Name, für den nur sein Inhaber bürgen kann

Text erstellt am 7. Oktober 2026.

Kurz gefasst

Am 6. Oktober gab Google bekannt, dass Angreifer die Registries dreier Länderdomains übernommen hatten — Ghana (.gh), Sierra Leone (.sl) und Amerikanisch-Samoa (.as) — und darüber echte, von Browsern akzeptierte Zertifikate für mehrere Google-Domains und andere große Dienste erhielten. Keine Zertifizierungsstelle wurde gehackt; Google zufolge hielten sich die ausstellenden Stellen an die Regeln. Genau das macht den Vorfall beunruhigend: Die Prüfungen wurden korrekt durchgeführt, und der Angriff gelang trotzdem. Die Schwachstelle liegt in den Prüfungen selbst. 1 2

Dieser Artikel erklärt, wie das möglich ist, warum die üblichen Gegenmaßnahmen lediglich den Schaden begrenzen und wie lopux.net — ein Projekt von Reliable Communications s.r.o., einem in Tschechien registrierten Netzbetreiber — den angegriffenen Schritt entfernt. Im Modell von lopux.net liegen Namen auf einer Blockchain, und Website-Betreiber veröffentlichen ihre eigenen Schlüssel; weder eine Zertifizierungsstelle noch eine Domain-Registry steht dazwischen.

Was passiert ist

Eine Website weist ihre Identität mit einem Zertifikat nach: einem von einer Zertifizierungsstelle signierten Dokument, das bestätigt, dass ein bestimmter Schlüssel zu einem bestimmten Namen gehört. Vor dem Signieren prüft die Stelle, ob der Antragsteller den Namen kontrolliert — meist, indem sie ihn auffordert, eine Kennung in den DNS-Einträgen der Domain oder auf dem Server zu hinterlegen, auf den der Name verweist.

Die Angreifer mussten die Zertifizierungsstelle nicht täuschen. Sie drangen in die Registries ein, die die drei Länderdomains betreiben, und änderten die Einträge ausgewählter Namen: wohin sie zeigen und welche Server für sie antworten. Danach sah jede Prüfung im Internet die Angreifer als Inhaber. Sie mussten nur noch Zertifikate beantragen und bestanden die Prüfungen regelkonform. Mit einem solchen Zertifikat und der Kontrolle darüber, wohin der Name aufgelöst wird, kann ein Angreifer den echten Dienst imitieren, während der Browser das übliche Schloss anzeigt.

Google sperrte die gefundenen Zertifikate in Chrome, bat die ausstellenden Stellen um deren Widerruf und suchte in den öffentlichen Certificate-Transparency-Protokollen nach weiteren. Das Unternehmen erklärte ausdrücklich, dass es nicht sicher sein könne, alle betroffenen Domains gefunden zu haben, und dass Nutzer sich zum Schutz nicht auf die Sperrung im Browser verlassen sollten. 1

Das ist schon früher passiert

2011, DigiNotar. Eine niederländische Zertifizierungsstelle wurde gehackt und stellte mehr als 500 gefälschte Zertifikate aus, darunter ein Wildcard-Zertifikat für google.com. Damit wurde die E-Mail-Kommunikation von schätzungsweise 300.000 Menschen im Iran abgefangen. Der Angriff fiel auf, weil der Browser eines Nutzers, Chrome, die echten Schlüssel von Google eingebaut hatte. Wenige Wochen später war das Unternehmen insolvent. 5
2017, Togo (.tg). Die Registry der Länderdomain von Togo stand eine Woche lang unter der Kontrolle von Angreifern; für google.tg erhielten sie ein Zertifikat von einer weit verbreiteten kostenlosen Zertifizierungsstelle. Chrome lehnte es nur ab, weil die eigenen Schlüssel von Google im Browser eingebaut sind — einen solchen Schutz hat kaum eine andere Website. 3
2017–2019, „Sea Turtle“. Cisco Talos dokumentierte eine staatlich unterstützte Kampagne gegen Registrare, Registries und DNS-Anbieter, mit der der Datenverkehr staatlicher Organisationen in ungefähr einem Dutzend Ländern umgeleitet wurde. Talos bezeichnete sie als ersten bekannten Fall einer kompromittierten Registry zu Spionagezwecken. 4

In allen drei Fällen griffen die Angreifer einen Vermittler an, nicht den Inhaber des Namens: eine Registry, einen DNS-Betreiber oder eine Zertifizierungsstelle. Die Kompromittierung eines einzigen von ihnen genügt, um sich als Inhaber auszugeben.

Warum die üblichen Gegenmaßnahmen nur den Schaden begrenzen

Die nach der Bekanntgabe ausgesprochenen Empfehlungen sind vernünftig und sollten befolgt werden. Doch jede reagiert entweder auf ein bereits ausgestelltes gefälschtes Zertifikat oder hängt von derselben DNS-Ebene ab, die die Angreifer übernommen haben.

Die Überwachung von Certificate-Transparency-Protokollen macht ein gefälschtes Zertifikat erst nach seiner Ausstellung sichtbar — und nur, wenn jemand hinsieht und rechtzeitig reagiert.
CAA-Einträge, die festlegen, welche Stellen Zertifikate für eine Domain ausstellen dürfen, werden im DNS veröffentlicht — genau auf der Ebene, die ein Angreifer nach der Übernahme der Registry kontrolliert.
Ein Widerruf erreicht Browser nicht sofort; viele andere Programme prüfen ihn überhaupt nicht.
Key Pinning deckte DigiNotar 2011 auf und schützte Google 2017. Der allgemeine Mechanismus dafür wurde jedoch vor Jahren aus den Browsern entfernt. Heute schützt er nur noch wenige sehr große Unternehmen, deren Schlüssel die Browseranbieter von Hand hinterlegen.

DNSSEC und DANE verdienen eine eigene Erwähnung: Auf dem Papier kommen sie dem Ansatz von lopux.net am nächsten — der Inhaber signiert seine Einträge selbst und kann die Fingerabdrücke seiner Schlüssel im DNS veröffentlichen. Die Vertrauenskette verläuft aber durch die Registry. Wer sie kontrolliert, kann zusammen mit den Einträgen einer Domain auch deren Signaturschlüssel ersetzen; bei diesem Vorfall kontrollierten die Angreifer genau diese Registry. Zudem prüft kein verbreiteter Browser DANE.

Zusammen mit Certificate Transparency und Key Pinning sind das Reparaturen an einem fehlerhaften Fundament: Jede schließt eine Lücke, lässt das Vertrauensmodell, das die Lücken erzeugt, unangetastet und eröffnet häufig eine neue. DNSSEC vergrößert DNS-Antworten um ein Mehrfaches; signierte Zonen wurden dadurch zu beliebten Reflektoren für Verstärkungsangriffe. Es brauchte Reparaturen an der Reparatur: die Begrenzung der Antwortfrequenz und minimale Antworten auf ANY-Anfragen. 2024 zeigte die Schwachstelle KeyTrap, dass eine einzige präparierte Antwort jeden großen validierenden Resolver für Minuten oder Stunden anhalten konnte. Der Fehler lag nicht in einer einzelnen Implementierung, sondern in dem vom Standard vorgeschriebenen Prüfverfahren. 6 7 8

Das Internet hat das schon einmal erlebt. Als IPv4 die Adressen ausgingen, hielten NAT und zahlreiche Behelfslösungen es am Leben. IPv6 sollte der saubere Ersatz mit eingebauter Sicherheit sein. IPsec-Unterstützung war für jeden Knoten vorgeschrieben, bis die Anforderung 2011 gelockert wurde; durchgängiges IPsec setzte sich nie durch. Neighbor Discovery ersetzte ARP und übernahm dessen Anfälligkeit für Manipulationen. Die kryptografische Lösung SEND fand kaum praktische Verbreitung. Netzwerke verlassen sich deshalb auf RA Guard in Switches, der anschließend mit Erweiterungsheadern umgangen und erneut nachgebessert wurde. Die Übergangstunnel, die die Migration erleichtern sollten, führten Datenverkehr an IPv4-Firewalls vorbei. Jede zusätzliche Sicherheitsschicht brachte eigene Lücken und Reparaturen mit sich: Datenschutz-Erweiterungen für Adressen mit eingebauter Hardware-MAC, einen ganzen RFC darüber, welche ICMPv6-Nachrichten eine Firewall noch verwerfen darf, die Übernahme von Dual-Stack-Rechnern durch gefälschte Router Advertisements in reinen IPv4-Netzen, die Empfehlung, NSEC3-Iterationen auf null zu setzen, eine DNSSEC-Einführung, die einen Teil der Slack-Nutzer stundenlang vom Dienst abschnitt … 9 10 11 12 13 14 15 16 17 18

Das Grundproblem bleibt: Für die Echtheit eines Namens bürgen Organisationen, denen er nicht gehört.

Der Ansatz von lopux.net: die Vermittler entfernen

lopux.net vereint zwei Dienste in einer Anwendung 19. Lopux-VPN ist ein VPN: Es leitet den Datenverkehr der Nutzer durch einen verschlüsselten Tunnel über die Server des Projekts, der so gestaltet ist, dass er wie gewöhnlicher Webverkehr aussieht. Lopux-Internet ist ein eigener Namensraum, bewusst außerhalb des ICANN-Domainsystems, dessen Einträge nicht in einer Registry, sondern auf einer öffentlichen Blockchain gespeichert werden. Derzeit gibt es zwei Top-Level-Zonen: .lopux und .ipvx.

Beide Dienste lassen sich unabhängig voneinander nutzen. Wie jedes VPN verbirgt Lopux-VPN die IP-Adresse der Nutzer vor den besuchten Websites; zusätzlich verknüpft der Dienst nach Angaben des Projekts IP-Adressen nicht mit Benutzerkonten 19.

Lopux-Internet beruht auf einem anderen Prinzip: Nur der Inhaber einer Domain kann für sie bürgen, und die Überprüfung findet auf dem eigenen Gerät der Nutzer statt.

Einträge liegen auf einer Blockchain, nicht in einer Registry-Datenbank. Ein Name und seine Einträge werden auf einer öffentlichen Blockchain gespeichert und können nur mit der Signatur des Inhabers geändert werden; jede andere weist die Blockchain zurück. Jede Änderung ist öffentlich und mit einem Zeitstempel versehen.

Keine Zertifizierungsstelle. Der Betreiber der Website stellt sein eigenes Zertifikat aus und veröffentlicht den Fingerabdruck seines Schlüssels zusammen mit den Einträgen des Namens. Die Anwendung der Nutzer vergleicht diesen Fingerabdruck mit dem Schlüssel, den die Website tatsächlich vorlegt: Stimmen sie überein, wird die Verbindung aufgebaut; andernfalls wird sie abgelehnt. Es gibt keinen Schritt der Domain-Validierung, in dem jemand, der den Namen für eine Stunde kontrolliert, einen Nachweis erhalten kann, dass der Name ihm gehört.

Mehrere unabhängige Quellen. Die Anwendung liest die Blockchain gleichzeitig über mehrere öffentliche RPC-Knoten oder über einen vom Nutzer selbst betriebenen Knoten und vergleicht die Antworten. Weichen sie voneinander ab, wird keine Verbindung hergestellt.

Schlüsselwechsel. Um den Schlüssel einer Website zu ersetzen, aktualisiert der Inhaber einfach den veröffentlichten Fingerabdruck, und innerhalb von Minuten sieht jeder Client den neuen. Nichts muss in Browsern gesperrt werden, und es müssen keine Sperrlisten verteilt werden. Der Preis dafür: Der Signaturschlüssel des Inhabers – derjenige, der Änderungen auf der Blockchain autorisiert – wird zum Einzigen, das weder verloren gehen noch durchsickern darf. Geschieht das doch, gibt es keinen Registrar, an den man sich wenden könnte.

Der Angriff von 2026 beruhte auf zwei Schritten: der Änderung von Einträgen bei einer Registry und dem Bestehen der Prüfung einer Zertifizierungsstelle 1 2. Im Modell von lopux.net ist der erste ohne den Schlüssel des Inhabers unmöglich, und den zweiten gibt es nicht.

Heute bewusst begrenzt, offen für Erweiterung

Vorerst dient diese Technik nur lopux.net selbst: Namen in .lopux und .ipvx und den dahinterliegenden Websites. Die Begrenzung ist gewollt; technisch steht einer breiteren Einführung nichts im Weg.

Das Design ist nicht an diese Namen gebunden. Die Blockchain-Resolver, die Lopux-Internet bedienen, könnten für das gesamte Internet geöffnet werden, und die Einträge gewöhnlicher Domains – .com, .org oder Länderdomains – könnten auf dieselbe Weise auf der Blockchain gespeichert werden, mit denselben vom Inhaber veröffentlichten Schlüssel-Fingerabdrücken. Inhaber bestehender Domains würden diese bei ihrem bisherigen Registrar behalten und sich lediglich dafür entscheiden, die Einträge über lopux.net auf der Blockchain zu hosten.

Was lopux.net in diesem Stadium nicht vorhat, ist, neue Namen im gewöhnlichen Domainraum zu registrieren. Die Registrierung dort ist Sache von ICANN und seinen Registries. Ein außerhalb dieses Systems vergebener Name könnte später von jemand anderem über das offizielle System registriert werden – und zwei Inhaber für einen Namen sind genau die Situation, die dieses Design ausschließen soll. Das Hosten von Einträgen für eine Domain, die bereits einen Inhaber hat, erzeugt keinen solchen Konflikt.

Nutzer könnten eine solche Website dann auf einem von zwei Wegen erreichen:

Über gewöhnliches DNS, voll kompatibel mit heutigen Browsern, Betriebssystemen und Netzwerken: Die Einträge der Domain werden von der Blockchain an jeden ausgeliefert, der sie auf dem üblichen Weg abfragt.
Über die Lopux-Anwendung, direkt von der Blockchain. Dieser Weg bietet den oben beschriebenen vollen Schutz, weil die Antwort von der Blockchain selbst kommt und nicht über eine Kette aus Registries, DNS-Servern und Zertifizierungsstellen.

Warum eine Anwendung nötig ist

Browser und Betriebssysteme unterstützen bislang weder auf einer Blockchain gespeicherte Namen noch Schlüssel, die Website-Betreiber dort veröffentlichen; sie verstehen nur gewöhnliches DNS und die Zertifizierungsstellen, die sie mitbringen. Bis sich das ändert, übernimmt die Lopux-Anwendung diese Arbeit auf dem Gerät der Nutzer: Sie liest die Blockchain, prüft den Schlüssel der Website gegen den Fingerabdruck des Inhabers und übergibt dem Browser eine bereits verifizierte Verbindung.

Warum das über lopux.net hinaus wichtig ist

Der Registry-Angriff hat erneut gezeigt, dass eine Domain zu besitzen und dies beweisen zu können zwei verschiedene Dinge sind – und dass das Zweite derzeit von Vermittlern abhängt 1 2. Für den größten Teil des Internets wird sich das nicht schnell ändern. Doch für Dienste, deren Nutzer unter staatlichem Druck leben, bedeutet ein gefälschtes Zertifikat abgefangene Korrespondenz – und für sie lohnt es sich, Namen aufzubauen, deren Echtheit nur der Inhaber bestätigen kann. Genau das tut lopux.net, beginnend mit seinen eigenen Websites.

Ein letzter Vorbehalt: Alles hier Beschriebene läuft derzeit im Sepolia-Testnetz von Ethereum und nicht in einem Produktivnetz, und das Projekt ist auf Rückmeldungen der Menschen angewiesen, die es nutzen 19. Jeder kann den Dienst kostenlos testen, und lopux.net möchte erfahren, was funktioniert, was nicht funktioniert und was unklar ist.