Goal

Go past the basics of Tor: when a VPN helps and when it doesn’t, how bridges get you around censorship, how to give back by running a relay, how to send SSH through Tor and publish it as an onion service, and when Tor is the wrong tool.

Prerequisites: Week 7a (Tor Fundamentals)

This is Part 2 of 2 - Covers advanced configuration and limitations.

🌱 New to this? For a gentler take on VPNs—what they do, what they don’t, and how to pick one—Privacy 101 covers it without the command line: Privacy 101 Week 7: VPNs Done Right →

1. Tor and VPNs - When to Combine

Tor Over VPN (VPN → Tor → Internet)

Setup: Connect to VPN, then launch Tor Browser

Advantages:

  • Hides Tor usage from ISP
  • Useful in countries that block Tor

Disadvantages:

  • VPN provider can see you’re using Tor (not your traffic)
  • Adds a trusted third party
  • Slower

Use case: If ISP/government blocks Tor or criminalizes Tor usage.

VPN Over Tor (Tor → VPN → Internet)

Setup: Configure VPN client to route through Tor (advanced)

Advantages:

  • VPN provider doesn’t know your real IP

Disadvantages:

  • Complex setup
  • Very slow
  • VPN must accept Tor exits (many don’t)

Use case: Rare - accessing services that block Tor exit IPs.

When NOT to Use VPN with Tor

Default recommendation: Just use Tor alone.

  • VPN adds complexity and potential points of failure
  • Tor already provides strong anonymity
  • VPN is a single point of trust (you’re trusting the provider)

Exception: If Tor is blocked in your region, VPN → Tor can bypass censorship.

2. Tor Bridges - Bypassing Censorship

What Are Bridges?

Bridges are Tor relays that aren’t listed in the main public directory. You use them to connect when Tor is censored or blocked.

Types of bridges:

  • obfs4 - Obfuscates traffic (looks like random data, not Tor)
  • meek (formerly meek-azure; renamed in Tor Browser 15) - Tunnels traffic through a CDN front so it looks like ordinary HTTPS to a large website. It no longer runs on Azure. It is slow and bandwidth-limited, so use it as a last resort after obfs4 and Snowflake.
  • Snowflake - Uses temporary proxies from volunteers’ browsers
  • WebTunnel - Looks like a WebSocket/HTTPS connection to an ordinary web server. It is not a built-in option; request it from bridges.torproject.org.

Getting Bridges

Method 1: Tor Browser built-in

Settings (≡ menu) → Connection → Bridges → Find more bridges → Request bridges → solve CAPTCHA → Submit
(On first launch: Configure Connection, then the same Bridges section)

Method 2: bridges.torproject.org

# Visit in regular browser
firefox https://bridges.torproject.org/

# Complete CAPTCHA
# Receive bridge addresses like:
obfs4 192.0.2.3:1234 [fingerprint] cert=[cert] iat-mode=0

Method 3: Email request

Send email to: [email protected]
From: Gmail or Riseup only (anti-spam)
Body: "get bridges"

Configuring Bridges

In Tor Browser:

Settings → Connection → Bridges
→ Add a bridge manually (or Enter bridge addresses you already know)
→ Add new bridges → paste one bridge per line → OK

Or choose a built-in transport (obfs4, Snowflake, meek) from "Choose a built-in bridge"

3. Running a Tor Relay

Running a relay is how you give back to the Tor network, and every relay helps everyone’s anonymity.

Types of Relays

1. Guard (Entry) Relay

  • High bandwidth, stable
  • Listed in public directory
  • Sees user IPs (but not destinations)

2. Middle Relay

  • Safest to run (no legal risk)
  • Doesn’t see source or destination
  • Just passes encrypted traffic

3. Exit Relay

  • Highest legal risk (your IP = Tor traffic source to outside world)
  • Can receive DMCA notices, abuse complaints
  • Not recommended unless you understand the legal implications

4. Bridge Relay

  • Helps users bypass censorship
  • Not publicly listed
  • Lower bandwidth requirements

Requirements:

  • Stable internet connection
  • At least 10 Mbit/s upload AND download (16 Mbit/s recommended)
  • At least 100 GB in and 100 GB out per month (2 TB or more is better; unmetered is ideal)
  • At least 512 MB RAM
  • Linux server (VPS or home server)

If you have less than 10 Mbit/s but at least 1 Mbit/s, run an obfs4 bridge instead, and below that, run a Snowflake proxy. A home consumer router may not cope with the 7000+ concurrent connections a relay needs. Tor’s full list: https://community.torproject.org/relay/relays-requirements/

Install Tor:

sudo apt update
sudo apt install tor

Configure as Middle Relay:

sudo nano /etc/tor/torrc

Add these lines:

Nickname YourRelayNickname    # Choose a unique name
ContactInfo [email protected]    # Your contact (abuse reports)
ORPort 9001                   # Relay port (must allow incoming)
ExitPolicy reject *:*         # This makes it a MIDDLE relay (no exits)

# Optional: Bandwidth limits
# Limits below the 10 Mbit/s minimum defeat the point of running a relay
RelayBandwidthRate 2 MBytes    # ~16 Mbit/s sustained
RelayBandwidthBurst 4 MBytes   # ~32 Mbit/s burst
# On a metered plan, use AccountingMax to cap monthly traffic instead

Restart Tor:

sudo systemctl restart tor

Verify relay is working:

sudo journalctl -u tor@default | grep -E "Bootstrapped 100%|Self-testing indicates your ORPort is reachable"
# The ORPort self-test line can take up to ~20 minutes to appear
# Daemon status: sudo systemctl status tor@default

Check metrics:

Middle relays:

  • Very low legal risk
  • EFF Tor Legal FAQ: Generally safe

Exit relays:

  • High legal risk - abuse complaints directed to your IP
  • Requires dedicated IP, legal understanding, abuse response plan
  • Only run if you fully understand implications

4. Tor + SSH Integration

Tor can anonymize SSH connections, which is useful when you need to reach a server without revealing your location.

SSH Over Tor (Using Tor as SOCKS5 Proxy)

Step 0: Install the Tor service (if you skipped the relay section)

sudo apt install tor

It listens on 127.0.0.1:9050. Tor Browser uses 9150, and only while it is open. If nc -X is not recognized, install netcat-openbsd.

Step 1: Ensure Tor is running

sudo systemctl status tor@default
# Debian/Ubuntu: should show active (running). Plain `tor` shows "active (exited)" there,
# which is normal because it is only a wrapper.
# Other distros (Arch, Fedora): use `sudo systemctl status tor`.
# Any distro: `ss -ltn | grep 9050` shows the SOCKS port listening.

Step 2: SSH through Tor

ssh -o ProxyCommand="nc -X 5 -x 127.0.0.1:9050 %h %p" [email protected]

Or connect to clearnet server:

ssh -o ProxyCommand="nc -X 5 -x 127.0.0.1:9050 %h %p" [email protected]

Add to ~/.ssh/config for convenience:

Host myserver-tor
    Hostname example.com
    User myuser
    ProxyCommand nc -X 5 -x 127.0.0.1:9050 %h %p

Now just:

ssh myserver-tor

SSH to .onion Hidden Services

If the server is a hidden service:

ssh [email protected]
# Through Tor SOCKS proxy as above

Useful for:

  • Anonymous shell access
  • Remote server management without IP exposure

Hosting Your Own Onion Service (SSH)

Everything above connects to an onion address someone else set up. This part runs on your server and gives it an .onion address of its own. Tor builds the connection outward, so the server needs no open inbound port and no public IP for this to work.

Step 1: Install Tor on the server

sudo apt install tor

Step 2: Tell Tor which port to publish

Add these two lines to /etc/tor/torrc:

HiddenServiceDir /var/lib/tor/ssh/
HiddenServicePort 22 127.0.0.1:22

The first line is where Tor keeps this service’s keys. The second says: traffic arriving on port 22 of the .onion address goes to sshd on this machine.

Step 3: Restart Tor and read your address

sudo systemctl restart tor
sudo cat /var/lib/tor/ssh/hostname
# prints something like: abc...xyz.onion (56 characters before .onion)

If Tor doesn’t come back up, check sudo journalctl -u tor@default -n 30. A typo in torrc or wrong directory permissions are the usual causes.

Step 4: Connect from your own machine

ssh -o ProxyCommand="nc -X 5 -x 127.0.0.1:9050 %h %p" [email protected]

Or put it in ~/.ssh/config the same way as the myserver-tor example above, with the .onion address as the Hostname.

Keep it safe:

  • The other files in /var/lib/tor/ssh/ are the service’s private keys. Anyone who copies them can impersonate your address. Back them up encrypted if you want to keep the same address after a rebuild.
  • Anyone who learns the address can reach your sshd. Keep key-only login (PasswordAuthentication no, Week 5). For a private service, add client authorization so only clients holding a key can even see it: https://community.torproject.org/onion-services/advanced/client-auth/
  • To make the onion address the only way in, set ListenAddress 127.0.0.1 in /etc/ssh/sshd_config. Do this last, after you’ve logged in over the onion address at least once, and keep your provider’s web console handy. Otherwise one typo locks you out of your own VPS.

Full official guide: https://community.torproject.org/onion-services/setup/

5. When NOT to Use Tor

Tor Is Not the Right Tool For:

❌ Downloading large files

  • Torrents (leaks IP, congests network)
  • OS ISOs (use direct download or VPN)

❌ Streaming video

  • Too slow for HD video
  • Unfair to other Tor users (bandwidth)

❌ Banking and financial transactions

  • Banks may flag Tor IPs as suspicious
  • Use VPN instead for banking privacy

❌ Logging into personal accounts

  • Defeats anonymity purpose
  • Use separate browser for social media

❌ Real-time gaming

  • Too high latency
  • Tor is for asynchronous communication

Tor Limitations

Tor does NOT protect against:

  • Malware on your device
  • Bad OpSec (logging into personal accounts)
  • Correlation attacks if adversary controls entry + exit
  • Traffic confirmation attacks (advanced)
  • Browser fingerprinting (if you customize Tor Browser)

Tor DOES protect against:

  • ISP seeing what sites you visit
  • Websites knowing your real IP/location
  • Network surveillance (if used correctly)
  • Censorship (with bridges)

6. Tor Alternatives

I2P (Invisible Internet Project)

Similar to Tor but:

  • Optimized for hidden services (not clearnet access)
  • Garlic routing (bundles multiple messages)
  • Fully distributed (no central directory)

Use case: Anonymous file sharing, messaging, hosting

Hyphanet (formerly Freenet)

Decentralized, censorship-resistant platform (renamed from Freenet in 2023; see hyphanet.org)

  • Stores encrypted data across network
  • No central servers
  • Designed for publishing, not browsing

Nym Mixnet (Advanced)

Next-generation mix network

  • Metadata resistance beyond Tor
  • Covered in Advanced Modules

7. Journal & Git Commit

echo "Week 7: Completed Tor deep dive - installed Tor Browser, tested circuits, accessed .onion sites, learned OpSec practices. Key insight: Tor is for anonymity, not speed." >> notes/week07_journal.md

git add .
git commit -S -m "Week 7 - Tor, onion routing, bridges, relays"

Week 7 Checklist

  • Installed Tor Browser from official source
  • Verified GPG signature (recommended)
  • Tested Tor Browser with check.torproject.org
  • Configured security level (tried Safer or Safest)
  • Accessed at least 2 .onion sites
  • Tested New Circuit functionality
  • Reviewed Tor OpSec do’s and don’ts
  • Understood when NOT to use Tor
  • (Optional) Configured Tor bridges
  • (Optional) Set up SSH over Tor
  • (Advanced) Published SSH as your own onion service
  • (Advanced) Installed Tor relay as middle node
  • Updated journal with Tor learnings

Additional Resources

Official Documentation:

Learning Resources:

Technical Deep Dives:

Key Takeaways

  • VPN + Tor is usually unnecessary - Tor alone provides strong anonymity
  • Bridges bypass censorship - obfs4 recommended for blocked regions
  • Running a middle relay is safe and helpful - Contributes to network anonymity
  • SSH over Tor hides your location - Useful for anonymous server access
  • Tor is not for everything - Don’t torrent, stream, or use for banking
  • Know Tor’s limitations - It’s not magic, OpSec still required