Tor Circuit Isolation in Practice: Segregating Market Sessions to Stop Cross-Tab Correlation

Two tabs. Two logins. One Tor process. That is the default setup most people run, and it is a correlation gift if anyone is watching both destinations at once.

This is not a browser-fingerprint lecture. It is circuit hygiene. Onion routing builds a random path of three relays: a guard, a middle, and (for clearnet) an exit. Traffic is wrapped in layers so each hop only knows who sent it the cell and where to send it next. Your ISP can see that you connected to a guard. It cannot see the destination. That property is real. It does not make two of your sessions strangers to each other.

For .onion research the last hop stays inside Tor. There is no public exit to snoop. The client still has a long-lived guard. Streams can still share a circuit. Timing still lines up if you hammer two services from the same process in the same minute. Market operators, compromised relays, and anyone doing traffic confirmation care about that overlap. You should too. Research only. No access instructions, no live links.

What a circuit actually isolates (and what it does not)

A circuit is a temporary tunnel, not an identity. The client picks the path, layers the encryption, and reuses that path for multiple streams until it expires or you force a rebuild. Reuse is the point. Building a fresh three-hop path for every HTTP request would be slow and would burn through guards.

Shared circuit means shared first hop. Anyone who can see both destinations and the timing of your cells has a pairing problem they can actually work. Same client, same guard, two onion services lighting up in lockstep. That is cheaper than breaking Tor.

Browser state is worse. Cookies, cached images, logged-in sessions, and any JavaScript you left enabled sit above the network. Circuit isolation does not wipe those. If two research identities share a profile, the network layer can be clean and you still glued them together yourself.

Guards persist across restarts. That is by design, to stop an adversary from cycling you onto a malicious entry node. Isolation of streams does not give you a new guard. Do not pretend it does.

Where Tor Browser draws the line

Tor Browser already isolates circuits by first-party domain. Different onion hosts should not share a circuit in a healthy session. Click the site information / circuit display and look. If two unrelated hosts show the same path, something is wrong with your build or your isolation flags.

Same host, two accounts: no isolation. Forum tab and vendor tab on one market: no isolation. That is the usual failure. People open a second login “just to check a listing” and reuse the same first-party circuit plus the same cookie jar.

New Circuit for this Site rebuilds the path for that first party. It does not clear cookies. It does not close other tabs. It does not give you a new guard. Treat it as a retry button when a circuit is slow or a relay is broken. Not as a new persona.

New Identity is heavier. It closes tabs, wipes session state in that window, and builds new circuits. Use it between research tasks, not between every click. It still runs inside one installation, one set of bookmarks, one set of about:config scars you made last month. If you customized the browser, New Identity does not un-customize it.

Set the security level to Safest before any of this matters. Default Tor Browser allows JavaScript. Malicious pages have used that to de-anonymize clients and recover real IPs. The shield control is in the toolbar. Safest is the only setting I run for untrusted onions. Sites will look broken. That is the cost.

Cross-tab correlation in practice

Think like someone with logs, not like a slogan.

A market admin sees login A from circuit fingerprint X at 14:02. Login B from the same X at 14:03, same user-agent, same window size, same language header. They do not need your name. They need to know A and B are one operator. Vendors colluding with staff get the same pairing. So does anyone who later seizes the server.

A global passive adversary is a high bar. Two of your own tabs, same process, same second, is not. You did the correlation for them.

Related services are the trap. Directory, market, wallet explorer, forum. Even with first-party circuit isolation, the timing of your fetches is a signature. Stagger sessions. Do not keep four research identities “warm” in one window.

Never download PDFs, office files, or random binaries from search results or market pages. Documents carry macros and tracking pixels that phone home the moment you open them on the host. If you need a file, that is a different machine, a different workflow, and usually a decision to walk away.

Segregating sessions without lying to yourself

One research identity per browser profile. Not per tab. Copy the Tor Browser folder, or use a separate user account. Do not sync anything. Bookmarks that exist in both profiles are a human fingerprint. I keep a paper note of which profile is which. Ugly. Works.

SOCKS isolation is the lever under the browser. Tor can give a distinct circuit to each SOCKS username (IsolateSOCKSAuth). Tor Browser uses that for first-party isolation. If you point another application at Tor, set a unique SOCKS user per task and keep DNS inside that proxy. System-wide proxies leak. Background apps will resolve DNS on the real network while your “anonymous” client thinks it is clean. Verify with a leak test before you care about the destination. If the test shows your real IP, stop. Do not proceed on a leaking path.

I do not run chat, wallets, and a market viewer through one SOCKS port with empty credentials. That is how streams collapse onto one circuit again.

Multiple Tor daemons are possible. They are also how people burn a second guard and make their Tor usage look twice as large to the ISP. For most research, multiple browser profiles on one correctly configured client is enough. Extra daemons are for when you already know why you need them.

When a second VM is the actual fix

If the work is untrusted enough that a browser bug is in scope, stop stacking tabs and move the identity into another machine.

Whonix is two virtual machines: a gateway and a workstation. The workstation can only talk to the gateway. The gateway is the only thing that speaks Tor. Both are VirtualBox appliances, so the host can be whatever already runs VirtualBox. The pair uses a private internal network. An exploited browser on the workstation does not get a raw socket to your real NIC. That is the point.

Put one research identity in one workstation. Clone the workstation for a second identity. Do not copy the gateway’s keys around as a souvenir. Do not share clipboards as a habit. Snapshot before you open anything ugly, revert after.

Qubes OS pushes the same idea further. Applications live in sandboxed VMs. Running Whonix inside Qubes forces workstation traffic through the Whonix Tor gateway, so an exploited app or malicious JavaScript stays off the host and off other AppVMs. That is the strongest practical split I will recommend for this problem.

It is also annoying. Qubes does not perform well (or at all) nested in a virtual machine, so you cannot casually “try it” on a throwaway hypervisor. There is an unsupported Live CD. It may not boot on your hardware, and it does not give you a honest preview of a full install. You are looking at an all-or-nothing disk install to find out if your machine even likes it. Factor that in before you preach Qubes at people with one laptop.

None of this is a Tails-versus-Whonix beauty contest. Tails is a different threat model (amnesia, USB). Circuit isolation is about keeping identity A from sitting on the same process, disk, and timing window as identity B. Pick the box that actually enforces that split on hardware you will use.

Operational rules I actually follow

One identity, one window, one task. Finish. New Identity or shut the profile. Then the next task.

Do not log into two markets, or two accounts on one market, from the same profile. Ever. If you need a second view, it costs you a second workstation or a second copy of the browser. Convenience is how pairing happens.

Warming a session by browsing the homepage first is fraud-shop folklore. For research it is still a timing pattern. Keep movements boring and short. Do not build a ritual that only you perform on every site.

Directories and search engines are hostile. Verify PGP signatures on any onion you will type a password into. A directory can be swapped if its host is compromised. The signature is the check, not the URL you memorized. Do not use a surface-web proxy or a clearnet “mirror helper” as your path to those directories. Your ISP sees that visit, and it is a neat flag that you are about to use Tor for something specific.

Leave no balance sitting behind a login you might need to reopen in a hurry. Escrow protects you from a vendor. It does not protect you from the operators. They hold the keys. An exit scam is them using those keys. Treat any funds you parked in an account as money you already chose to gamble. That stance also stops you from frantically reusing a stale profile the day a site vanishes and the phishing mirrors bloom.

Never trust a single isolation control. Circuit display plus separate profile plus Safest plus no downloads. If you skip one, assume the others are decorative.

What still burns you after you did this right

The guard is still shared across all profiles that use the same Tor data directory. Separate daemons or separate VMs if that bothers you more than the extra Tor-on-the-wire signal.

Clock skew, window size, and installed fonts are still there if you broke Tor Browser’s defaults. I leave the browser ugly on purpose. Customization is how you become unique.

Human pace. If you only appear on Tor between 22:00 and 23:00 local, circuit isolation will not save you from a schedule. Shift the work or accept that metadata.

Compromised destination. Isolation stops you from linking your own sessions. It does not stop a market from logging that the same PGP key, the same writing tics, or the same withdrawal pattern showed up under two usernames. Admins are not your friends. Neither is the seizure team that inherits the database.

JavaScript you re-enabled “just for this site.” Don’t. If the page is unusable on Safest, you do not need that page.

I have watched people do the VM work and then paste a screenshot from workstation A into a chat running on the host. The network was clean. The operator was not. Isolation is a habit, not a hypervisor checkbox.

Run leak tests when you change anything: proxy, VM, or browser copy. Confirm the circuit display matches the identity you think you are using. Then do the research, close the box, and leave the other identity off. That is the whole trick. Everything else is people trying to save a reboot.