OPSEC52 / Week 19 — Tor circuits: your guard sees you, your exit sees your traffic, and neither should see both

Tor is not a magic cloak. It is three relays in a row, each seeing a different, deliberately incomplete slice of you. The guard knows your IP and that you use Tor; the exit knows where you are going and can read whatever you did not encrypt. The whole model is that no single relay sees both ends. Almost every real Tor deanonymization is a user who broke that rule themselves.

Threat model: your ISP (which sees you reach a Tor guard unless you use a bridge), a malicious or logging exit node, a global adversary correlating guard-side and exit-side timing — and, most often, you, cross-contaminating a Tor identity with a real-name login, a resized window, an extension, or a file that calls home when opened.

The three hops, and what each one actually knows

A standard Tor circuit is guard → middle → exit.

• The guard (entry node) sees your real IP address and the fact that you are speaking Tor. It does not see your destination — the traffic is wrapped in two more layers of encryption. This is why Tor pins your guard for months: rotating entry nodes constantly would eventually route you through a hostile one. A stable guard is a feature, not a bug.
• The middle relay sees nothing useful — only that it is passing encrypted cells between a guard and an exit. It is the buffer that keeps the two ends apart.
• The exit node decrypts the final layer and talks to the destination on your behalf. It sees where you are going and anything you did not encrypt yourself. It does not see your IP. A logging exit that watches you POST a username and password in cleartext has your identity for that site — and Tor did exactly what it promised, because you handed the exit plaintext.

The takeaway: guard-side knows who, exit-side knows what, and your job is to make sure they never learn each other’s half.

Hide Tor usage from your ISP: bridges

By default, your ISP can see you connect to a known Tor guard. In most places that is merely conspicuous; in censored or hostile networks it is dangerous. Bridges are unlisted entry relays, and pluggable transports disguise the traffic itself:

• obfs4 — makes Tor look like random noise. The default first choice.
• snowflake — routes you through volunteer browser proxies; good where obfs4 is blocked.
• meek — tunnels through a big CDN (looks like normal HTTPS to a major cloud). Slow, last-resort, for the most aggressive censors.

If your adversary is your ISP or your government, a bridge is not optional.

The exit is the danger zone — or skip it entirely with .onion

Everything you send through an exit in cleartext is readable by that exit. Rules:

• Never send anything over an exit you would not put on a postcard unless it is end-to-end encrypted (HTTPS, and verify the certificate).
• Never log into a real-name / KYC account over Tor and then reuse that same circuit or identity for anything pseudonymous.
• Prefer .onion services. An onion connection has no exit node — the encryption runs all the way to the service, and the address itself is the service’s public key. There is no exit to log you, no exit to MITM you, no DNS lookup to leak (see Week 17). This is why xmr.club and every serious privacy service publish an onion mirror: the onion path removes the single most exposed hop from the circuit.

Circuit isolation and rotation

Tor Browser already isolates circuits by first-party domain — two sites open in two tabs travel different exits, so they cannot be trivially linked by a shared exit IP. Use that:

• New Circuit for this Site — swaps the relays for the current tab. Use it when an exit is slow or blocked.
• New Identity — closes every tab, wipes state, and builds fresh circuits. Use it between distinct personas — never carry one identity’s cookies into another’s session.
• Do not manually pin or fast-rotate your guard. Tor’s default guard behavior is deliberately sticky for your protection.

The mistakes that actually deanonymize people

Tor’s cryptography rarely fails. Users do:

1. Mixing Tor and clearnet for the same identity — checking a pseudonymous account over Tor, then the same account over your home IP “just once.” Correlation done.
2. Resizing the Tor Browser window or maximizing it — window dimensions are a fingerprint. Leave it at the default letterboxed size.
3. Installing extensions or changing settings — every deviation makes you more unique. A stock Tor Browser is anonymous because it looks like every other stock Tor Browser.
4. Opening a downloaded file while online — a PDF or document can fetch a remote resource and reveal your real IP outside Tor. Open untrusted downloads offline, in a VM or Tails (and mind the metadata — see Week 18).
5. Torrenting over Tor — BitTorrent leaks your real IP in the protocol itself and crushes the network. Never.
6. Enabling JavaScript on the low-security slider when the threat model doesn’t allow it — set the slider to Safer or Safest for sensitive work.

This week’s move

Open Tor Browser, click the circuit display (the icon left of the address bar), and look at your three hops for a site you use. Notice the guard’s country, the exit’s country. Now visit the same service’s .onion address instead and watch the exit disappear from the circuit. Then set your security slider to Safer by default, confirm your window is the default size, and — if your network is hostile — switch to an obfs4 bridge in settings. Three clicks, and you have gone from “using Tor” to “using Tor correctly.”

Curated by Cyber Satoshi. Part of OPSEC52 — 52 weeks, 52 privacy pillars, threat-model first. See also Week 17 (DNS leakage) and Week 18 (file metadata).