A name only its owner can vouch for

Text prepared on 7 October 2026.

In short

On 6 October, Google disclosed that attackers had taken over the registries of three country-code domains — Ghana (.gh), Sierra Leone (.sl) and American Samoa (.as) — and used that access to obtain genuine, browser-trusted certificates for several Google domains and other large services. No certificate authority was breached, and according to Google, the authorities that issued the certificates followed the rules. That is what makes the incident troubling: the checks were performed correctly, and the attack still succeeded. The weakness lies in the checks themselves. 1 2

This article explains how that is possible, why the standard countermeasures only limit the damage, and how lopux.net — a project of Reliable Communications s.r.o., a network operator registered in the Czech Republic — removes the step that was attacked. In the lopux.net model, names are kept on a blockchain and site owners publish their own keys; no certificate authority or domain registry sits in between.

What happened

A website proves its identity with a certificate: a document, signed by a certificate authority, stating that a particular key belongs to a particular name. Before signing, the authority verifies that the applicant controls the name, usually by asking them to place a token in the domain's DNS records or on the server the name points to.

The attackers had no need to deceive the authority. They broke into the registries that operate the three country domains and changed the records for selected names: where each name points and which servers answer for it. From then on, every check on the internet saw the attackers as the owners. All that remained was to request certificates, and they passed the checks by the book. With such a certificate and control over where the name resolves, an attacker can impersonate the real service while the browser shows the usual padlock.

Google blocked the certificates it found in Chrome, asked the issuing authorities to revoke them, and searched the public Certificate Transparency logs for others. It also stated plainly that it cannot be sure it has found every affected domain, and that users should not rely on browser-side blocking for protection. 1

It has happened before

2011, DigiNotar. A Dutch certificate authority was breached and more than 500 fraudulent certificates were issued, including a wildcard certificate for google.com. It was used to intercept the email of an estimated 300,000 people in Iran. The attack came to light because one user's browser, Chrome, had Google's real keys built in. Within weeks the company was bankrupt. 5
2017, Togo (.tg). The registry for Togo's country domain was under attacker control for a week, and a certificate for google.tg was obtained from a widely used free certificate authority. Chrome rejected it only because Google's own keys are built into the browser — protection that almost no other website has. 3
2017–2019, "Sea Turtle". Cisco Talos documented a state-sponsored campaign that targeted registrars, registries and DNS providers to redirect the traffic of government organisations in roughly a dozen countries. Talos called it the first known case of a registry being compromised for espionage. 4

In all three cases the attackers went after an intermediary rather than the name's owner: a registry, a DNS operator or a certificate authority. Compromising any one of them is enough to impersonate the owner.

Why the usual countermeasures only limit the damage

The recommendations issued after the disclosure are sound and worth following. But each of them either reacts to a fraudulent certificate that already exists or depends on the same DNS layer the attackers took over.

Certificate Transparency monitoring reveals a fraudulent certificate only after it has been issued, and only if someone is watching and responds in time.
CAA records, which list the authorities permitted to issue certificates for a domain, are published in DNS — the very layer an attacker controls once the registry is compromised.
Revocation takes time to reach browsers, and many clients other than browsers never check it.
Key pinning is what exposed DigiNotar in 2011 and protected Google in 2017, but the general-purpose pinning mechanism was removed from browsers years ago. Today it protects only a handful of very large companies whose keys browser vendors add by hand.

DNSSEC and DANE deserve a separate mention, because on paper they come closest to the lopux.net approach: the owner signs their own records and can publish their own key fingerprints in DNS. But the chain of trust runs through the registry. Whoever controls the registry can replace a domain's signing keys along with its records, and in this incident that is exactly what the attackers controlled. No mainstream browser checks DANE in any case.

Together with Certificate Transparency and key pinning, these are patches on a flawed foundation: each closes one gap, leaves the trust model that creates the gaps untouched, and often opens a gap of its own. DNSSEC makes DNS answers several times larger, which turned signed zones into a favourite reflector for amplification attacks and called for patches on the patch: response rate limiting, minimal answers to ANY queries. In 2024 the KeyTrap flaw showed that a single crafted answer could stall every major validating resolver for minutes or hours, and the bug was not in any one implementation but in the validation procedure the standard prescribes. 6 7 8

The internet has been through this before. When IPv4 ran out of addresses it was kept alive with NAT and a stack of workarounds. IPv6 was meant to be the clean replacement, with security built in. IPsec support was mandatory in every node until the requirement was relaxed in 2011, and end-to-end IPsec never arrived. Neighbor Discovery replaced ARP and inherited its spoofing; the cryptographic fix, SEND, never saw real deployment, so networks rely on RA Guard in switches, which was then evaded through extension headers and patched again. The transition tunnels meant to ease migration carried traffic straight past IPv4 firewalls. Every added layer of security has brought a layer of holes and patches of its own: privacy extensions for addresses with the hardware MAC built in, a whole RFC on which ICMPv6 messages a firewall may still drop, dual-stack hosts hijacked through rogue router advertisements on IPv4-only networks, a recommendation to set NSEC3 iterations to zero, a DNSSEC rollout that cut off part of Slack's users for hours… 9 10 11 12 13 14 15 16 17 18

The underlying problem remains: a name's authenticity is vouched for by organisations that do not own it.

The lopux.net approach: remove the intermediaries

lopux.net combines two services in one application. Lopux-VPN is a VPN: it routes the user's traffic through the project's servers in an encrypted tunnel designed to look like ordinary web traffic. Lopux-Internet is a separate namespace, deliberately outside the ICANN domain system, whose records are stored on a public blockchain rather than in a registry. It currently has two top-level zones: .lopux and .ipvx.

The two services can be used independently. Like any VPN, Lopux-VPN hides the user's IP address from the sites they visit; in addition, the service does not link IP addresses to user accounts.

Lopux-Internet rests on a different principle: only a domain's owner can vouch for it, and verification takes place on the user's own device.

Records live on a blockchain, not in a registry database. A name and its records are stored on a public blockchain and can be changed only with the owner's signature; the blockchain rejects any other. Every change is public and timestamped.

No certificate authority. The site owner issues their own certificate and publishes the fingerprint of its key alongside the name's records. The user's application compares that fingerprint with the key the site actually presents: if they match, the connection proceeds; if not, it is refused. There is no domain-validation step in which someone who controls the name for an hour can obtain proof that the name is theirs.

Several independent sources. The application reads the blockchain through several public RPC nodes at once, or through a node the user runs themselves, and compares the answers. If they differ, no connection is made.

Key changes. To replace a site's key, the owner simply updates the published fingerprint, and within minutes every client sees the new one. Nothing has to be blocked in browsers, and no revocation lists have to be distributed. The trade-off is that the owner's signing key — the one that authorises changes on the blockchain — becomes the one thing that must be neither lost nor leaked. If it is, there is no registrar to turn to.

The 2026 attack relied on two steps: altering records at a registry and passing a certificate authority's check. In the lopux.net model the first is impossible without the owner's key, and the second does not exist.

Deliberately limited today, open to extension

For now, this technology serves only lopux.net itself: names in .lopux and .ipvx and the sites behind them. The limit is deliberate; nothing technical prevents a wider rollout.

The design is not tied to these names. The blockchain resolvers that serve Lopux-Internet could be opened to the whole internet, and the records of ordinary domains — .com, .org or country domains — could be stored on the blockchain in the same way, with the same owner-published key fingerprints. Owners of existing domains would keep them with their current registrar and simply choose to host the records on the blockchain through lopux.net.

What lopux.net does not plan to do at this stage is register new names in the ordinary domain space. Registration there belongs to ICANN and its registries. A name issued outside that system could later be registered by someone else through the official one, and two owners for one name is precisely the situation this design is meant to rule out. Hosting records for a domain that already has an owner creates no such conflict.

Users could then reach such a site in one of two ways:

Through ordinary DNS, with full compatibility with today's browsers, operating systems and networks: the domain's records are served from the blockchain to anyone who queries them in the usual way.
Through the Lopux application, directly from the blockchain. This route gives the full protection described above, because the answer comes from the blockchain itself rather than through a chain of registries, DNS servers and certificate authorities.

Why an application is needed

Browsers and operating systems do not yet support names stored on a blockchain or keys that site owners publish there; they understand only ordinary DNS and the certificate authorities they ship with. Until that changes, the Lopux application does this work on the user's device: it reads the blockchain, checks the site's key against the owner's fingerprint, and hands the browser an already verified connection.

Why this matters beyond lopux.net

The registry attack showed once again that owning a domain and being able to prove it are two different things, and that the second currently depends on intermediaries. For most of the internet, that will not change quickly. But for services whose users live under state pressure, a forged certificate means intercepted correspondence — and for them it is worth building names whose authenticity only the owner can confirm. That is what lopux.net is doing, starting with its own sites.

A final caveat. Everything described here currently runs on Ethereum's Sepolia test network rather than a production network, and the project cannot do without feedback from the people who use it. Anyone can test the service free of charge, and lopux.net would like to hear what works, what breaks and what is unclear.