Anonymity on the internet is not a default, it is something you have to engineer deliberately. Dark web browsers like Tor and I2P exist precisely because the open web was never designed with privacy in mind. Every packet you send carries metadata, every connection logs an IP, and every ISP sits between you and the sites you visit. Understanding how these tools actually work, not just that they "hide you," is fundamental knowledge for any security practitioner, researcher, or privacy-conscious user.
This guide breaks down the architecture, threat models, and real operational practices behind Tor and I2P, along with the commands and configurations that separate functional anonymity from a false sense of security.
The term "dark web" is frequently misused. To be precise, it refers to overlay networks that require specific software, configurations, or authorization to access. It is a subset of the deep web, which simply means content not indexed by standard search engines.
The dark web is not inherently criminal. It hosts whistleblower platforms like SecureDrop, privacy-focused communications, censorship-resistant publishing, and legitimate research infrastructure. Security professionals working in threat intelligence, OSINT, or incident response regularly interact with dark web resources as part of their work. If you want to formalize that skill set, the courses at Redfox Cybersecurity Academy cover dark web OSINT and threat intelligence in structured, hands-on modules.
The reason standard browsers cannot access .onion or .i2p addresses is architectural: these are not DNS-resolvable domains. They exist only within their respective overlay networks.
Tor, short for The Onion Router, routes your traffic through a series of three volunteer-operated relays: a guard node (entry), a middle relay, and an exit node. Each relay knows only the node immediately before it and the node immediately after it. No single relay knows both the origin and the destination of traffic.
Encryption is layered like an onion. Your Tor client fetches the consensus document from directory authorities and builds a circuit by encrypting the payload three times, once for each relay's public key. Each relay peels one layer of encryption, learns the next hop, and forwards the remaining ciphertext. The exit node decrypts the final layer and sends the plaintext request to the destination.
This means:
Hidden services (now called onion services) never route traffic through an exit node. Instead, both the client and the server build circuits to a mutually agreed-upon relay called a rendezvous point. The server publishes introduction points to a distributed hash table. The client fetches those introduction points, picks a rendezvous point, and sends a message through an introduction point asking the server to connect to that rendezvous point.
The result is that neither party learns the other's IP address. The .onion address itself is derived from the server's public key, making it both an identifier and a cryptographic authenticator.
A v3 onion address looks like this:
duckduckgogg42xjoc72x3sjasowoarfbgcmvfimaftt6twagswzczad.onion
[cta]
That 56-character string is a base32-encoded representation of the service's Ed25519 public key. Connecting to it is proof of identity by design.
The Tor Browser is the reference implementation for Tor-based browsing. On Debian/Ubuntu systems:
sudo apt update && sudo apt install -y tor torbrowser-launcher
torbrowser-launcher
[cta]
For server-side Tor configuration, edit /etc/tor/torrc:
# Basic hidden service configuration
HiddenServiceDir /var/lib/tor/my_hidden_service/
HiddenServicePort 80 127.0.0.1:8080
HiddenServiceVersion 3
# Enforce strict node selection
StrictNodes 1
ExcludeExitNodes {US},{GB},{AU},{CA},{NZ}
# Disable exit traffic if running only a hidden service
SocksPort 0
[cta]
After restarting Tor (sudo systemctl restart tor), your onion address is generated automatically:
cat /var/lib/tor/my_hidden_service/hostname
# Output: youraddress.onion
[cta]
Tor is not magic. It protects against traffic analysis and IP disclosure, but it does not protect against:
The FBI's takedown of Silk Road was not a Tor break. It was an OPSEC failure. Ross Ulbricht linked his real email address to forum posts in the early days of the site's operation. The network held. The human did not.
I2P is a fundamentally different design. Where Tor is primarily an anonymizing proxy for accessing the regular internet, I2P is designed as a self-contained darknet, a network within a network where services communicate with other services inside I2P.
I2P uses a concept called garlic routing, which bundles multiple encrypted messages together (like a garlic bulb), making traffic analysis harder than Tor's single-stream onion routing. Traffic flows through unidirectional tunnels: separate inbound and outbound tunnels for each participant. This means an adversary watching your traffic sees inbound and outbound packets that are not obviously correlated.
Key structural differences from Tor:
FeatureTorI2PPrimary use caseClearnet proxy + hidden servicesInternal darknet servicesRoutingOnion (3-hop)Garlic (tunnel-based)DirectoryCentralized directory authoritiesDistributed DHT (NetDB)Traffic modelBidirectional circuitsUnidirectional tunnelsExit nodeYes (for clearnet)Minimal (outproxies)LatencyModerateHigherTypical address.onion.i2p
I2P calls its hidden services "eepsites," and their addresses end in .i2p. Installation on Debian/Ubuntu:
sudo apt-add-repository ppa:i2p-maintainers/i2p
sudo apt update
sudo apt install i2p i2p-keyring
sudo systemctl enable i2p
sudo systemctl start i2p
[cta]
Once running, the I2P router console is accessible at http://127.0.0.1:7657. You configure your browser to proxy HTTP traffic through 127.0.0.1:4444 and HTTPS through 127.0.0.1:4445.
To verify your I2P tunnel status from the command line:
# Check router status
curl http://127.0.0.1:7657/routerInfo
# List active tunnels (via the API)
curl "http://127.0.0.1:7657/tunnels"
[cta]
I2P also exposes a SAM (Simple Anonymous Messaging) bridge for programmatic access:
import socket
# Connect to SAM bridge
sam = socket.create_connection(("127.0.0.1", 7656))
sam.sendall(b"HELLO VERSION MIN=3.1 MAX=3.1\n")
response = sam.recv(1024)
print(response.decode())
[cta]
I2P is stronger against traffic analysis within the network because of its unidirectional tunnels and garlic routing. However, it has its own limitations:
For researchers wanting to explore these properties in depth, Redfox Cybersecurity Academy includes hands-on labs covering network anonymization, traffic analysis, and darknet threat modeling as part of its advanced practitioner tracks.
Both Tor and I2P protect your network layer. Neither of them protects your application layer behavior. This distinction is critical. The following are the most common failure patterns observed in real deanonymization cases:
Browser fingerprinting. Even through Tor, websites can fingerprint your browser via canvas, WebGL, audio context, font enumeration, and timezone disclosure. Tor Browser mitigates this with aggressive fingerprint normalization, but any deviation from defaults, installing plugins, resizing the window, enabling JavaScript on untrusted sites, reintroduces uniqueness.
Account linkage. Logging into any account that has real-world associations, Gmail, social media, even a forum you've used under your real IP, immediately links your session to your identity regardless of what network you are using.
File metadata. Documents downloaded over Tor and then opened while connected to the clearnet can phone home or expose metadata. Always strip metadata before opening or sharing files.
DNS leaks. If your DNS queries bypass your anonymizing proxy, your ISP (and anyone watching) knows what you are trying to resolve. Test this with:
# Test for DNS leaks using torsocks
torsocks curl https://check.torproject.org/api/ip
# Or use a dedicated DNS leak test
torsocks curl https://dnsleaktest.com/
[cta]
For serious operational use, a properly configured Tor Browser running on a standard OS is not sufficient. Whonix is a two-virtual-machine architecture designed to enforce anonymization at the OS level.
The Whonix-Gateway routes all traffic through Tor and knows the user's IP address. The Whonix-Workstation is isolated on a separate internal network with no direct internet access. It can only communicate through the Gateway. Even if the Workstation is fully compromised by malware, the attacker cannot learn the user's real IP because the Workstation does not have it.
Setting up Whonix on a KVM/QEMU host:
# Download Whonix KVM images
wget https://download.whonix.org/linux/17.2.3.7/Whonix-Gateway-XFCE-17.2.3.7.Intel_AMD64.qcow2.libvirt.xz
wget https://download.whonix.org/linux/17.2.3.7/Whonix-Workstation-XFCE-17.2.3.7.Intel_AMD64.qcow2.libvirt.xz
# Verify signatures (never skip this step)
gpg --verify Whonix-Gateway*.libvirt.xz.asc
# Extract and import
tar -xvf Whonix-Gateway*.libvirt.xz
virsh define Whonix-Gateway*.xml
virsh define Whonix-Workstation*.xml
[cta]
Tails OS is another strong option for ephemeral use, it routes all traffic through Tor and leaves no trace on the host machine.
For command-line tools that need to route through Tor, torsocks is the standard approach:
# Route a single command through Tor
torsocks wget https://check.torproject.org
# Verify Tor is working
torsocks curl -s https://check.torproject.org/api/ip | python3 -m json.tool
[cta]
For tools that do not support SOCKS5 natively, proxychains-ng provides a transparent proxy wrapper:
# /etc/proxychains4.conf
strict_chain
proxy_dns
[ProxyList]
socks5 127.0.0.1 9050
# Run any tool through Tor
proxychains4 -f /etc/proxychains4.conf nmap -sT -Pn -p 80,443 target.example.com
[cta]
Note that proxychains with nmap has significant limitations for accurate scanning. UDP and raw socket scans will not be proxied correctly. For network reconnaissance through Tor, use TCP-connect scans only, and understand that latency will be substantial.
Security researchers often need to host controlled infrastructure on the dark web, for canary traps, honeypots, or secure drop points. A minimal nginx-based onion service:
# Install nginx and tor
sudo apt install nginx tor -y
# Configure torrc
sudo tee -a /etc/tor/torrc <<EOF
HiddenServiceDir /var/lib/tor/research_hs/
HiddenServicePort 80 127.0.0.1:80
HiddenServiceVersion 3
EOF
# Harden nginx to localhost only
sudo tee /etc/nginx/sites-available/onion-research <<EOF
server {
listen 127.0.0.1:80;
server_name localhost;
root /var/www/html;
index index.html;
# Disable version disclosure
server_tokens off;
# No logging for operational security
access_log off;
error_log /dev/null;
}
EOF
sudo ln -s /etc/nginx/sites-available/onion-research /etc/nginx/sites-enabled/
sudo systemctl restart nginx tor
[cta]
After a few minutes, Tor will have built the introduction points and your .onion address will be available:
sudo cat /var/lib/tor/research_hs/hostname
For threat intelligence purposes, you can run a Tor relay or bridge and collect metadata (not content) about network conditions and circuit patterns. The stem Python library provides programmatic access to the Tor control port:
import stem
from stem.control import Controller
with Controller.from_port(port=9051) as controller:
controller.authenticate()
# Get current circuit information
for circuit in controller.get_circuits():
if circuit.status == stem.CircStatus.BUILT:
print(f"Circuit {circuit.id}:")
for i, (fingerprint, nickname) in enumerate(circuit.path):
prefix = "Guard" if i == 0 else ("Exit" if i == len(circuit.path)-1 else "Middle")
print(f" {prefix}: {nickname} ({fingerprint})")
[cta]
This kind of relay telemetry is used by researchers at organizations like the Tor Project and academic institutions to study network health, detect malicious relays, and model anonymity properties.
The right tool depends entirely on your threat model and operational requirements.
Use Tor when:
Use I2P when:
In practice, experienced researchers often run both, using Tor for external access and I2P for internal research infrastructure.
Tor and I2P are serious cryptographic infrastructure, not toys or tools for casual browsing. Each operates on a distinct architectural philosophy, and each has a distinct threat model that practitioners need to understand before trusting their anonymity to it. Tor's three-hop onion routing and mature ecosystem make it the default choice for most dark web access scenarios. I2P's garlic routing and internal darknet architecture make it the stronger choice for intranet-style services that should never touch the clearnet.
What both networks share is this: they protect the network layer and nothing else. Operational security, browser hygiene, file metadata, account discipline, and host security are entirely the user's responsibility.
If you want to build real expertise in dark web operations, network anonymization, and threat intelligence methodology, the practitioner-focused curriculum at Redfox Cybersecurity Academy is built precisely for professionals who need depth, not just surface-level familiarity. The network can only do so much. The rest is on you.
Redfox Cyber Security Inc.
8 The Green, Ste. A, Dover,
Delaware 19901,
United States.
.avif)
