When you load a website, your packets do not travel along a fixed wire. They are handed from network to network, each one consulting a routing table that says "to reach this block of addresses, forward toward that neighbor." Those tables are built from announcements. Networks tell their neighbors which address ranges they can deliver to, the neighbors propagate the claim, and within minutes the whole internet agrees on a path.
The protocol that carries those announcements is BGP, and it was designed in an era when every network operator personally knew the others. It assumes good faith. A network can announce a route for address space it does not own, and by default its neighbors will believe it. When that false announcement is more attractive than the legitimate one, traffic for a victim's addresses starts flowing to the attacker instead. That is a BGP hijack.
How a Hijack Actually Works
Every network on the internet has an Autonomous System Number — an AS number — and the address blocks it is authorized to originate. A hijack is an AS announcing a block it has no authority over. There are two flavors, and the difference matters.
The more-specific route hijack
Internet routing always prefers the most specific match. If the legitimate owner announces a large block and an attacker announces a smaller, more specific sub-block of it, every network on earth will prefer the attacker's route for that sub-block — not because it is shorter, but because it is more precise. This is why even a network "far" from the victim can pull traffic globally with a single sufficiently specific announcement.
The equal-specificity hijack
If the attacker announces the same block size as the victim, there is no precision tiebreaker. The hijack only succeeds for the slice of the internet that happens to be topologically closer to the attacker. It is partial — but partial is often enough.
Hijack vs. blackhole — An attacker who simply wants to take a service offline can announce the route and drop the traffic — a blackhole. An attacker who wants to spy does something harder: announce the route, inspect or modify the traffic, then forward it on to the real destination so the victim never notices the detour. That second pattern is an interception hijack.
What Hijacks Have Actually Been Used For
BGP incidents fall into a few recurring categories, and not all of them are malicious:
- Fat-finger leaks. A misconfigured router accidentally announces routes it should not. A well-known 2008 incident took a large video platform globally unreachable for hours after a telecom's attempt to block it domestically leaked worldwide.
- Traffic interception for surveillance. Researchers have documented hijacks that route traffic through a distant country and back, holding it just long enough to inspect.
- Cryptocurrency theft. One of the most cited criminal cases involved hijacking the address space of a public DNS service in 2018, redirecting users of a cryptocurrency wallet site to a malicious clone and draining funds.
- Spam and abuse. Hijacking unused address space to send spam from "clean" IPs, then disappearing.
The common thread: the attacker briefly becomes a network you never chose to trust, sitting directly in the path of your traffic. Everything that crosses an untrusted network in plaintext is readable. Everything not cryptographically authenticated can be modified.
The Defenses: RPKI and BGPsec
The internet's structural answer to hijacking is to attach cryptographic proof to routing claims. Two mechanisms matter.
RPKI — Resource Public Key Infrastructure — lets an address-block owner publish a signed statement called a Route Origin Authorization: "AS number X is authorized to originate this block." Networks that perform Route Origin Validation reject announcements that contradict a valid ROA. RPKI adoption has grown substantially, and it is genuinely effective against the most common case: a wrong-origin announcement, whether accidental or malicious.
But RPKI only validates the origin of a route, not the path it claims to have taken. A sophisticated attacker can craft an announcement that lists the legitimate origin AS at the end while still inserting itself into the path — a defense-aware hijack that RPKI alone does not catch.
BGPsec closes that gap by cryptographically signing the entire AS path, so each hop can be verified. It is the more complete answer — and the less deployed one, because it demands far more router resources and near-universal adoption to be useful. The realistic state of the internet in 2026 is broad RPKI origin validation and very limited path validation.
| Mechanism | Protects against | Does not stop |
|---|---|---|
| RPKI / ROV | Wrong-origin announcements — the most common hijack and nearly all accidental leaks | Path manipulation that keeps the real origin AS at the end |
| BGPsec | Forged AS paths, by signing every hop | Limited by sparse deployment; high router cost |
| Transport encryption (TLS) | Reading or altering your content on a hijacked path | The hijack itself, and metadata exposure |
Why This Is Ultimately an Encryption Problem for You
Here is the uncomfortable part: as an individual, you cannot fix routing. You do not run an AS. You cannot make your ISP deploy RPKI or audit the path your packets take. Routing security is an operator-level discipline, and you are downstream of every decision those operators make.
What you can control is whether a hijack matters when it happens. An attacker who diverts your traffic through their network gains a front-row seat — but only to whatever you sent in the clear. If your connection is protected by TLS 1.3, the attacker sees ciphertext. They cannot read it, and they cannot modify it without breaking the connection, because TLS authenticates both endpoints and every byte.
The internet's routing layer was built on trust and never fully retrofitted with proof. Treat every network between you and your destination as potentially hostile — because for the duration of a hijack, one of them is.
This is the same logic behind certificate pinning and forward secrecy: assume the path is compromised and design so it does not matter. A hijack can still hurt you in two ways encryption does not erase — it can take a service offline entirely, and it still exposes metadata, the fact that you connected to a given destination at a given time. But it cannot turn your communications into the attacker's reading material.
Where Haven Fits
Haven cannot patch BGP, and we would be lying if we claimed to. What we can do is assume the network is untrustworthy and build accordingly. Message content is end-to-end encrypted with keys derived on your device, so a hijacked path carries ciphertext and nothing else. Connections are authenticated, so a man-in-the-middle on a diverted route cannot silently substitute itself.
Routing-layer security is a job for network operators, and the slow grind of RPKI and BGPsec adoption genuinely helps everyone. But your defense as a user does not depend on that grind finishing. It depends on never trusting the path in the first place — which is a property your tools either have or do not. Haven is one option built on that assumption; the principle holds whichever service you choose.
Originally published at havenmessenger.com
