Who Created the Dark Web? Onion Routing Explained

In 2013, the FBI arrested Ross Ulbricht and seized the Silk Road’s servers. The press narrative was that the Feds had “cracked the dark web.” They hadn’t. They found a StackOverflow post where Ulbricht asked a question under his real name, tied it to a Gmail address, and worked backward from there. Tor did exactly what it was designed to do — it hid the network layer. It couldn’t hide the human sitting at the keyboard.

That gap between what Tor protects and what people think it protects is the entire reason this article exists. If you’re a sysadmin, a security engineer, or someone running infrastructure that touches anonymity networks, you need to understand the threat model before you deploy anything. By the end of this, you’ll know who actually built the dark web, how onion routing works at the crypto level, how to run a relay or an onion service, and — more importantly — what all of it does not protect you from.

This is not a “how to buy drugs online” guide. It’s a network engineering guide to a set of overlay protocols that most people fundamentally misunderstand.

TL;DR

• The “dark web” isn’t a place — it’s a set of overlay networks (Tor, I2P, Freenet, Lokinet) that require specific software to reach. Nobody “created” it in a single act.
• Onion routing was built by the US Naval Research Laboratory in the mid-1990s for intelligence traffic, then open-sourced as Tor in 2002.
• Tor uses layered encryption across three relays by default. No single relay knows both who you are and where you’re going.
• Tor protects network metadata. It does not protect you from application-layer leaks, endpoint compromise, or your own OPSEC failures.

Prerequisites

Before any of this is useful, you should have:

• A Linux box (Debian/Ubuntu or similar) you can dedicate to experimentation
• Comfort with systemd, torrc config files, and basic networking
• Working knowledge of public-key crypto and Diffie-Hellman at a conceptual level
• The tor package installed (apt install tor) and a willingness to read the specs at spec.torproject.org

You do not need to be a cryptographer. You do need to stop treating Tor as magic.

Who Actually Built It — The Real Origin Story

The question “who created the dark web” is usually asked by someone who assumes there’s a founder, an HQ, and a business model. There isn’t. There’s a lineage of academic and military research that got progressively more public, and the “dark web” is just what happens when you take anonymity infrastructure and let anyone use it.

The Naval Research Laboratory and the Onion Routing Problem

Between 1995 and 1997, Paul Syverson, David Goldschlag, and Michael Reed at the US Naval Research Laboratory were working on a specific problem: how do you run an intelligence network where the sender and receiver can’t be linked by any single observer — including the network operator?

TLS alone doesn’t solve this. TLS protects the content of a connection, but the metadata — who’s talking to whom, from where, when — is fully visible to anyone on the path. For a spy network, the metadata is the intelligence. If your adversary can see that an asset in Moscow is connecting to a handler in Virginia, you’ve already lost.

Onion routing was the answer: route traffic through a chain of relays, each of which only knows its immediate predecessor and successor. Encrypt the payload in layers so each relay can only peel one. The NRL filed patents, ran prototypes, and proved the concept worked.

The Tor Project Fork (2002–2006)

In 2002, Roger Dingledine and Nick Mathewson took the NRL design, cleaned it up, and open-sourced it as “The Onion Router” — Tor. The EFF picked up funding around 2004, which is the moment the project transitioned from a military research artifact into civilian infrastructure.

The canonical reference is the 2004 USENIX Security paper, “Tor: The Second-Generation Onion Router” by Dingledine, Mathewson, and Syverson. If you’re going to run Tor infrastructure, read it. It’s dense but it’s the ground truth, and it explains every design decision you’re about to encounter in the config files.

What “Dark Web” Actually Means

Here’s where 90% of journalism goes wrong. These four terms are not synonyms:

• Clearnet — the publicly indexed internet. Google, your bank, this website.
• Deep Web — anything not indexed by search engines. Your Gmail inbox is deep web. So is your company’s internal wiki.
• Dark Web — content on overlay networks that require specific software (Tor Browser, I2P router) to access. Content exists, but you can’t reach it with Chrome.
• Darknet — a specific class of dark web where access is restricted or invite-only. Sometimes used to mean “any overlay network.”

The “dark web” is not one network. It’s Tor, I2P, Freenet, ZeroNet (dead), Lokinet, and a handful of academic mixnets. They have different threat models, different routing algorithms, and different communities.

Network	Access Method	Indexed?	Example	Threat Model
Clearnet	Standard browser	Yes (Google et al.)	example.com	ISP sees everything
Deep Web	Auth / direct link	No	Internal wiki	Perimeter-based
Dark Web	Tor Browser, I2P router	No (directories only)	*.onion services	Metadata-resistant
Darknet	Invite / restricted	No	Private I2P peers	Trust-based, small

Onion Routing — The Cryptographic Foundation

This is the part most people skip, and it’s the part that determines whether you can reason about Tor’s guarantees. If you don’t understand the crypto, you’ll misconfigure the client, leak your identity, and blame the software.

Layered Encryption, Cell by Cell

The “onion” metaphor is accurate but oversimplified. Tor doesn’t encrypt a message and then wrap it three times like a Russian doll. It uses fixed-size cells — 514 bytes in the current spec — and each relay in the circuit peels exactly one layer of encryption.

Why fixed size? Because variable-size packets leak information. If a relay can see that your packets are 1,200 bytes versus 80 bytes, it can start guessing whether you’re loading a webpage or sending a chat message. Fixed-size cells force everything into the same shape, which is a traffic analysis defense.

What each relay knows:

• Guard (entry) relay: Your real IP address. Not your destination.
• Middle relay: Neither your IP nor your destination. Just that traffic is passing through.
• Exit relay: Your destination. Not your real IP.

No single relay in a three-hop circuit knows both ends. That’s the entire point.

Circuit Construction with Diffie-Hellman

Modern Tor circuits use the ntor handshake, which replaced the older TAP protocol. ntor uses Curve25519 ephemeral Diffie-Hellman to establish a shared secret with each relay in the circuit, one hop at a time.

The key property here is forward secrecy: the ephemeral keys are discarded after the circuit is built. If someone later compromises a relay’s long-term key, they still can’t decrypt traffic from circuits that have already closed. This is why you should never trust a system that uses static keys for session establishment — one breach and every historical session is exposed.

The ntor handshake also authenticates the relay’s identity, which prevents a malicious middleman from impersonating a relay during circuit construction.

Why This Isn’t Just “VPN But More Hops”

I’ve had this argument a hundred times. The “just use a VPN bro” crowd fundamentally misunderstands the trust model.

A VPN is a single point of trust. You pay a provider, they terminate your traffic, and they can see everything — your real IP, your destinations, your traffic patterns. You’re trusting them not to log, not to sell data, not to be compromised. That’s a business relationship, not a cryptographic guarantee.

Tor distributes trust across three independently operated relays. A malicious guard doesn’t know your destination. A malicious exit doesn’t know your IP. To deanonymize you, an adversary needs to control both ends of your circuit and correlate timing — which is possible for a global passive adversary, but out of reach for most attackers.

Here’s what onion layer construction looks like in pseudocode, adapted from the Tor spec:

# Pseudocode: building the layered payload for a 3-hop circuit.
# Each relay peels one layer, learns the next hop, forwards the rest.
# Real Tor uses fixed 514-byte cells; this is the conceptual shape.

def build_onion(payload, circuit_keys):
    # circuit_keys = [K_guard, K_middle, K_exit] from ntor handshakes
    layer = payload
    # Innermost layer first (exit), then middle, then guard.
    for relay_addr, key in reversed(circuit_keys):
        layer = encrypt(key, {
            "next_hop": relay_addr,
            "payload": layer,
        })
    return layer

Each relay decrypts its layer, reads next_hop, and forwards the inner payload. The exit relay gets the raw payload with no next_hop field. That’s the whole trick.

Property	VPN	Tor (3-hop)	Multi-hop VPN Chain
Trust model	Single provider	Distributed across 3+ relays	Distributed across N providers
Latency overhead	Low (~5-15ms)	High (~200-800ms typical)	Medium-High
Adversary resistance	Provider compromise = total	Needs both ends + correlation	Provider collusion needed
Best use case	Geo-shifting, ISP bypass	Anonymity, censorship circumvention	Layered trust, less studied

Q: Is Tor illegal? No, in most jurisdictions. Running a Tor client, a relay, or even an exit relay is legal in the US and most of the EU. Some countries (China, Russia, Iran, Belarus) block or criminalize it. Running an exit relay is the part that gets legally interesting — see the legal section below.

The Tor Network in Production — Relays, Bridges, and Directory Authorities

Understanding the network topology matters because it determines what you can contribute and what risks you’re taking on. If you’re going to run infrastructure, you need to know what each role exposes you to.

Relay Types and What They See

• Guard relays: The first hop. They see your real IP. They’re chosen by clients and rotated slowly (months) to prevent guard discovery attacks.
• Middle relays: Pass-through. They see neither end. Low legal risk, low bandwidth cost, easy to run.
• Exit relays: The last hop. They see your destination traffic in cleartext unless it’s end-to-end encrypted. High legal risk, high bandwidth cost. Complaints will arrive.
• Bridges: Unlisted relays used by censored users. They don’t appear in the public consensus.
• Snowflakes: A newer pluggable transport that uses WebRTC to look like a video call. Useful in heavily censored environments.

Running an exit in Germany is legally risky. Running one in the US is legal but you’ll get abuse complaints. Running one on your home connection without understanding the consequences is a bad idea.

Directory Authorities and Consensus

Tor has nine hardcoded directory authorities. Yes, nine. Yes, that’s a centralized trust point. Yes, it’s a known trade-off.

The dir-auths vote on a consensus document every hour that lists every relay in the network, its flags, its bandwidth, and its exit policy. Clients download this consensus and use it to build circuits. The alternative — a DHT-based discovery system — was rejected because it’s vulnerable to Sybil attacks. Nine authorities you can name and audit is a smaller attack surface than a permissionless DHT.

Bridges and Censorship Circumvention

If the Tor network is blocked at your ISP, you need a bridge. Bridges aren’t listed in the consensus, so they’re harder to block. But they need to look like normal traffic to survive deep packet inspection.

• obfs4: The workhorse. Obfuscates traffic so it doesn’t look like Tor. Still works well in most environments.
• meek: Routes traffic through a CDN (historically Google or Azure). It was clever in 2014 but it’s basically dead in 2024+ — CDNs have become better at detecting it, and the latency is atrocious.
• Snowflake: Uses WebRTC and volunteer browsers as proxies. Good for short-lived censorship circumvention, bad for stable connections.
• WebTunnel: Disguises Tor as a standard HTTPS website. Newer, promising, worth checking the current docs on.

Here’s a torrc for a middle relay — the lowest-risk way to contribute bandwidth:

# /etc/tor/torrc — middle relay config
# Runs a relay that carries traffic but never exits to the clearnet.
# Zero abuse complaints, minimal legal exposure.

Nickname        myrelay01
ContactInfo     admin [at] example [dot] com
ORPort          9001
DirPort         9030
ExitPolicy      reject *:*
RelayBandwidthRate  1 MB
RelayBandwidthBurst 2 MB
AccountingMax   500 GB
AccountingStart month 1 00:00

ExitPolicy reject *:* is the critical line. It tells the network this relay will never be an exit. You carry traffic for other people but you never originate connections to the clearnet, which means no abuse complaints and no legal exposure.

If you want to run a bridge instead:

# /etc/tor/torrc — obfs4 bridge
# Not listed in the public consensus. Used by censored users.

BridgeRelay     1
ORPort          9001
ServerTransportPlugin obfs4 exec /usr/bin/obfs4proxy
ServerTransportListenAddr obfs4 0.0.0.0:9002
ExtORPort       auto
ContactInfo     bridge-admin [at] example [dot] com
Nickname        mybridge01

The ServerTransportPlugin line is what makes this a bridge — obfs4proxy wraps the Tor traffic so it doesn’t look like Tor. You’ll need the obfs4proxy package installed separately on most distros.

Relay Type	What It Sees	Legal Risk	Bandwidth Cost	Beginner-Friendly
Middle	Neither end	Very low	Low–Medium	Yes
Guard	Client IPs	Low	Medium	Yes
Exit	Destinations	High	High	No
Bridge	Client IPs (censored)	Low	Low	Yes
Snowflake	Minimal	Very low	Minimal	Yes

Q: Can I run a Tor relay at home? Yes, but run a middle relay or a bridge, not an exit. Middle relays generate zero abuse complaints because they never touch the clearnet. Exit relays will get your ISP calling you within weeks. If you want to run an exit, do it on a VPS with a provider that explicitly allows it — and read the legal section first.

Inside the Tor Client — What Actually Happens When You Open a .onion

This is where the abstractions come off. If you’re going to use Tor for anything serious, you need to understand what the client is actually doing — because misconfiguration is how people get owned.

The SOCKS5 Handshake and Stream Isolation

The tor daemon exposes a SOCKS5 proxy on port 9050 (or 9150 for Tor Browser). Applications connect to that proxy, and Tor builds circuits on their behalf.

The critical concept here is stream isolation. By default, Tor will reuse circuits across different applications and connections. If you’re logged into two different accounts through the same circuit, the exit relay can correlate them as coming from the same source. That’s a deanonymization vector.

IsolateSOCKSAuth forces Tor to build a separate circuit for each unique SOCKS username/password pair. If your application supports SOCKS auth (many do), this is how you keep identities separate.

Hidden Service Rendezvous (v3 Onion Services)

A v3 onion address is 56 characters of base32-encoded ed25519 public key, plus .onion. That’s it. The address is the public key. There’s no DNS, no CA, no registration. The cryptographic identity is the address.

Rendezvous flow, simplified:

1. The service picks a few introduction points and publishes a descriptor to the hash ring.
2. The client fetches the descriptor, learns the intro points.
3. The client picks a rendezvous point and tells the service (via an intro point) to meet there.
4. Both client and service build circuits to the rendezvous point.
5. The rendezvous point stitches the two circuits together.

Neither side ever learns the other’s IP. The intro point knows the service’s location but not the client’s. The rendezvous point knows both circuits but not the identities.

v2 onion services were deprecated in 2021 and fully killed off. If you’re still running v2, you’re not just insecure — you’re offline. v2 had a 80-bit address space and was vulnerable to brute-force. v3 uses 256-bit ed25519. There’s no excuse for v2 in 2026.

Client Configuration That Won’t Get You Owned

Most torrc advice on Reddit is cargo cult. Here’s what actually matters:

# /etc/tor/torrc — hardened client config
# Isolates streams per SOCKS credential. Prevents cross-identity correlation.

SocksPort 9050 IsolateSOCKSAuth
SocksPort 9150 IsolateSOCKSAuth
ControlPort 9051
CookieAuthentication 1
CookieAuthFileGroupReadable 1

# Log to syslog, not to disk. Logs are forensic evidence.
Log notice syslog

# Don't use bridges unless you're in a censored environment.
# Bridges slow you down and reduce your anonymity set.

IsolateSOCKSAuth is the one that matters. CookieAuthentication 1 prevents any local process from controlling your Tor instance without reading the cookie file. Don’t use ExcludeNodes to geo-restrict your entry guards — that shrinks your anonymity set and is a known deanonymization risk.

Here’s a small Python script using stem to inspect your circuits:

# Requires: pip install stem
# Inspects current Tor circuits via the control port.
# Useful for verifying stream isolation is actually working.

from stem import Signal
from stem.control import Controller

with Controller.from_port(port=9051) as controller:
    controller.authenticate()  # uses cookie auth by default
    for circ in controller.get_circuits():
        if circ.status != "BUILT":
            continue
        print(f"Circuit {circ.id} ({circ.purpose}):")
        for i, hop in enumerate(circ.path):
            fp, nickname = hop
            print(f"  Hop {i}: {nickname} ({fp[:8]}...)")

Run this while you have two applications hitting different SOCKS credentials. If they’re sharing a circuit, stream isolation isn’t working.

Q: How do I visit a .onion site? Download Tor Browser from torproject.org and use it as-is. Don’t add extensions. Don’t change the security slider below “Safer” unless you have a specific reason. The browser is hardened against fingerprinting in ways that a vanilla Firefox with a SOCKS proxy is not.

Beyond Tor — I2P, Freenet, and the Also-Rans

Tor isn’t the only game in town, and the differences matter if you’re picking infrastructure for a specific use case.

I2P — Garlic Routing and the “Darknet” Mode

I2P uses garlic routing — multiple messages bundled into a single encrypted packet. Where Tor is optimized for client-server traffic (browsing), I2P is optimized for peer-to-peer. Its internal sites (“eepsites”) are reachable via .i2p addresses, but I2P was never designed to exit to the clearnet efficiently.

I2P’s threat model is different: it assumes peers may be adversarial and builds in more redundancy. It’s slower than Tor for browsing but better suited to torrenting, IRC, and long-lived peer connections.

Freenet and the DHT Approach

Freenet is fully distributed — no directory authorities, no consensus, no central trust. Content is stored in a distributed hash table and replicated across peers. The latency cost is severe: fetching a piece of content can take seconds to minutes. This is why nobody uses Freenet for anything interactive.

The upside is content persistence. Once something is published to Freenet, it tends to stay there. That’s a feature if you’re publishing censored material and a bug if you’re trying to delete something.

ZeroNet, Lokinet, and the Graveyard

• ZeroNet: Effectively abandoned. The original developer stopped maintaining it years ago. Don’t build on it.
• Lokinet / Session: Uses LLARP (Low Latency Anonymous Routing Protocol) with a blockchain-based incentive layer. Pivoted to a messaging product (“Session”). Interesting crypto, small user base.
• Various academic mixnets: Nym, Loopix, and others. Promising research, minimal production deployment.

The lesson here: overlay networks live or die on their user base, not their cryptography. Tor has the anonymity set. Everything else is playing catch-up.

Network	Routing	Latency	Threat Model	Active Dev	Primary Use Case
Tor	Onion (3-hop)	High	Metadata-resistant	Yes	Browsing, onion services
I2P	Garlic	Medium-High	P2P-adversarial	Yes	Internal sites, torrents
Freenet	DHT	Very High	Fully distributed	Slow	Censorship-resistant publishing
Lokinet	LLARP	Medium	Blockchain-incentivized	Yes	Messaging (Session)

Threat Modeling — What Tor Does and Doesn’t Protect Against

If you take one thing from this article, take this section. Tor is a network-layer anonymity tool. It is not a security tool, a magic cloak, or a substitute for operational discipline.

What Tor Actually Protects

• Network-level metadata: Your ISP can’t see your destinations. Your destination can’t see your IP.
• Traffic analysis resistance (partial): Fixed-size cells and cover traffic make timing correlation harder, though not impossible.
• Censorship circumvention: With bridges, you can reach the open internet from behind most national firewalls.

What Tor Does Not Protect

• Application-layer leaks: JavaScript, WebRTC, DNS, browser fingerprinting. Tor Browser mitigates these. A vanilla browser with a SOCKS proxy does not.
• Global passive adversary (GPA): An adversary that can observe both ends of your traffic — think NSA-class — can correlate timing and deanonymize you. Tor is not designed to defeat this.
• Endpoint compromise: If your box is owned, the overlay is irrelevant. Malware reads your screen, not your packets.
• Correlation attacks: The 2014 CMU attack on hidden services used a combination of traffic analysis and relay fingerprinting. It’s been mitigated but the class of attack remains.
• User OPSEC failures: The most common cause of deanonymization by a wide margin.

Threat	Protected?	Notes
ISP surveillance	Yes	ISP sees only Tor traffic to a guard
Destination logging	Yes	Exit IP is not your IP
Global passive adversary	No	Requires timing correlation defense beyond Tor
Endpoint malware	No	Overlay can’t help if the box is owned
User OPSEC failure	No	The #1 cause of deanonymization

Here’s the classic mistake — forgetting torsocks and leaking your real IP:

# WRONG: this leaks your real IP to the destination.
curl https://check.torproject.org/api/ip

# RIGHT: route through Tor's SOCKS proxy.
torsocks curl https://check.torproject.org/api/ip

# Or explicitly, without torsocks:
curl --socks5-hostname 127.0.0.1:9050 https://check.torproject.org/api/ip

The first command connects directly. If you’re on a machine where you think you’re using Tor, that’s the leak that ends the investigation. torsocks wraps the syscall layer and forces everything through the SOCKS proxy — but it doesn’t cover statically-linked binaries or anything that bypasses libc. Verify, don’t assume.

Real-World OPSEC Failures

• Ross Ulbricht / Silk Road: Caught via a StackOverflow post under his real name that linked to his Gmail. Tor worked fine.
• Hansa / AlphaBay: The Dutch police took over Hansa and ran it as a honeypot, logging everything for weeks. The lesson is about server-side compromise, not network-level deanonymization.
• Alexandre Cazes / AlphaBay: Caught because his personal email was in the welcome message of a compromised server. Again — not a Tor failure.

The pattern is consistent: people don’t get caught by breaking Tor. They get caught by being sloppy everywhere Tor doesn’t cover.

Q: Is Tor safe? Against what? Against your ISP seeing your traffic? Yes. Against a nation-state adversary with global visibility? No. Against you pasting your real email into a form? Absolutely not. “Safe” is meaningless without a threat model.

Running Onion Services in Production — The Boring Reality

Onion services get a bad reputation because the press only covers the criminal ones. In reality, SecureDrop, whistleblower platforms, and legitimate privacy-preserving services run on the same infrastructure. The engineering is identical.

What People Think It Is vs. What It Is

An onion service is a TCP service that’s reachable only via the Tor network. That’s it. It’s not magic, it’s not inherently criminal, and it’s not hard to run. The hard part is doing it without leaking your location.

Hardening an Onion Service

• Dedicated host: Not your laptop, not your dev box, not anything that touches your personal identity.
• No clearnet exposure: The service should not be reachable via a public IP. No DNS. No outbound traffic except what’s strictly required.
• Logging discipline: Log what you need to operate. Never log client IPs (you can’t see them anyway), and never log anything that could be correlated with a specific user.

Here’s a working torrc for a v3 onion service:

# /etc/tor/torrc — v3 onion service
# Exposes a local service on port 8080 as a .onion.

HiddenServiceDir /var/lib/tor/myservice/
HiddenServiceVersion 3
HiddenServicePort 80 127.0.0.1:8080

# Optional: client authorization (restricts access to known keys)
# HiddenServiceAuthorizeClient stealth client1,client2

The HiddenServiceDir contains your private key (hs_ed25519_secret_key). Back it up. If you lose it, you lose the address permanently — there’s no recovery. If it leaks, someone else can impersonate your service.

Here’s a systemd unit for the backend, hardened:

/etc/systemd/system/myservice.service

[Unit]
Description=Onion service backend
After=network.target tor.service

[Service]
Type=simple
User=myservice
Group=myservice
ExecStart=/usr/local/bin/myservice --listen 127.0.0.1:8080
Restart=on-failure
PrivateTmp=true
NoNewPrivileges=true
ProtectSystem=strict
ProtectHome=true
ReadWritePaths=/var/lib/myservice
CapabilityBoundingSet=
AmbientCapabilities=

[Install]
WantedBy=multi-user.target

ProtectSystem=strict makes the entire filesystem read-only except for explicitly allowed paths. NoNewPrivileges=true blocks setuid escalation. CapabilityBoundingSet= drops all capabilities. This is the baseline for anything exposed to an anonymity network — assume the backend will eventually be probed.

The Operational Cost

Tor is not a CDN. Expect:

• Latency: 200–800ms typical round-trip, worse under load.
• Throughput: A few hundred KB/s per circuit is realistic. Large file transfers are painful.
• Uptime monitoring: You can’t ping your onion service from the outside without leaking its location. Monitor from a separate Tor client, or monitor the backend service health directly.

Q: Can I host a website on the dark web? Yes. Install Tor, configure HiddenServiceDir and HiddenServicePort, run your web server on localhost, and you’re done. The engineering is trivial. The operational discipline — not leaking your identity through the backend — is the hard part.

Q: How do I take down a dark web site? You don’t, not by attacking the network. Tor is designed so that you can’t find the server’s location from the outside. Real takedowns come from OPSEC failures, server-side compromise, or legal pressure on the operator’s real-world identity. If someone claims to have “hacked” a .onion, they almost certainly compromised the backend, not Tor.

The Legal and Ethical Minefield

Running an exit relay is legal in the US. It’s risky in Germany, where courts have been inconsistent. It’s actively prosecuted in some jurisdictions. The Tor Project maintains a legal FAQ at community.torproject.org/relay/ — read it before you commit.

Don’t run an exit on your home connection. You will get abuse complaints, and depending on where you live, you may get a knock on the door. If you want to run an exit, do it on a VPS with a provider that explicitly permits it, and have a lawyer’s number on file.

The “I was just curious” defense doesn’t work when the FBI shows up with a warrant. If you’re going to run anonymity infrastructure, understand the legal exposure before you deploy, not after.

Common Mistakes and How to Avoid Them

1. Running Tor Browser with extensions. Extensions break the fingerprinting defenses that make Tor Browser safe. Every extension you add makes you more unique. If you need a feature, ask why — the answer is usually “you don’t.”

2. Using ExcludeNodes to geo-restrict entry guards. This shrinks your anonymity set and creates a predictable pattern. Don’t do it. Let Tor pick your guards.

3. Forgetting torsocks for CLI tools. curl, wget, git, and most CLI tools don’t use the SOCKS proxy by default. Wrap them with torsocks or configure the proxy explicitly. Verify with check.torproject.org.

4. Running an exit relay without legal preparation. Middle relays are safe. Exits are not. If you don’t understand the difference, run a middle relay.

5. Losing your onion service private key. Back it up. Store it offline. If you lose it, your address is gone forever. If you leak it, someone else can impersonate your service.

FAQ

Q: Is the dark web illegal? No. The networks themselves — Tor, I2P, Freenet — are legal in most jurisdictions. What’s illegal is what people do on them, which is true of the clearnet too.

Q: Can my ISP see that I’m using Tor? Yes. Your ISP can see that you’re connecting to a Tor guard relay. They can’t see what you do after that. If you need to hide the fact that you’re using Tor, use a bridge with obfs4 or WebTunnel.

Q: Is Tor slower than a VPN? Yes, significantly. Three hops with layered encryption adds latency. Typical browsing is usable; large downloads are painful. If you just need to bypass geo-restrictions, use a VPN. If you need anonymity, use Tor.

Q: How many relays does Tor have? The count fluctuates. As of this writing, it’s typically in the range of 7,000–8,000 relays with a few thousand bridges. Check metrics.torproject.org for current numbers.

Q: Can I run Tor and a VPN together? Yes, and there are legitimate reasons to do so — Tor-over-VPN hides Tor usage from your ISP; VPN-over-Tor hides your VPN usage from the exit. Both have trade-offs. Don’t do it because a YouTube video told you to.

Key Takeaways

Key Takeaways

• The dark web isn’t a place — it’s a set of overlay networks with specific threat models. Understand the model before you use the tool.
• Onion routing came from US Naval Research Laboratory work in the 1990s, open-sourced as Tor in 2002. Read the 2004 USENIX paper.
• Tor protects network metadata. It does not protect against application leaks, endpoint compromise, or your own OPSEC failures.
• Run a middle relay or bridge if you want to contribute. Don’t run an exit without legal preparation.
• Read the specs at spec.torproject.org and the relay docs at community.torproject.org/relay/. Stop getting your information from thumbnails.