Snowflake and Tor: What Censorship Circumvention Looks Like in 2026
How bridges, pluggable transports and a browser plugin keep the open net reachable
Contents
Censorship circumvention used to be a simple arms race: you’d point your traffic at a proxy, the censor would block the proxy’s address, you’d find another. By 2026 the censor has graduated. Modern national firewalls don’t just block known addresses — they fingerprint the shape of your traffic, and they’ll happily throttle or drop a connection that merely looks like Tor even if they can’t read it. The interesting story now is how Tor has evolved from “hide the destination” to “don’t even look like Tor in the first place”, and Snowflake is the most elegant piece of that puzzle.
I don’t live behind a serious firewall, so my stake in this is that of a homelabber who runs a Snowflake proxy on a spare browser tab and has spent an unreasonable number of evenings reading Tor Project design docs for fun. What follows is the mechanics as they actually stand this year, minus the marketing gloss — where each layer works, where it breaks, and what the honest advice is for someone who genuinely needs it.
Why plain Tor isn’t enough behind a serious firewall
Vanilla Tor connects to one of a published list of relays. That list is the problem: if the relay addresses are public, a censor downloads them and blocks the lot. Worse, the Tor handshake has a recognisable signature, so even an unlisted relay can be spotted by deep packet inspection.
Deep packet inspection is the shift that made the old game unwinnable. A firewall that only checks addresses is beaten by finding a new address. A firewall that inspects the bytes of your handshake — the size and timing of packets, the presence of a TLS record that doesn’t quite look like a browser’s — beats you no matter what address you use, because the traffic itself confesses what it is. This is the same class of problem I sketched in what actually happens when a pod looks up a name: the wire tells a story, and someone downstream is reading it.
The answer Tor settled on years ago is the pluggable transport: a shim that takes your Tor traffic and disguises it as something innocuous before it leaves your machine. The relays you connect through aren’t in the public list — they’re bridges, unlisted entry points handed out in limited batches so a censor can’t simply enumerate them all. The bridge list is deliberately doled out in small pieces through different channels precisely so that no single leak burns all of them at once.
obfs4: making Tor look like nothing
The workhorse pluggable transport has long been obfs4. It doesn’t tunnel through another protocol; instead it makes the traffic look like uniformly random bytes with no recognisable handshake, no fixed packet sizes, nothing for a DPI box to latch onto. You get an obfs4 bridge line — address, port, and a key — and configure Tor to use it:
| |
The design goal of obfs4 is subtle: not to imitate a specific protocol, but to look like nothing at all — a stream of high-entropy bytes a DPI engine can’t classify. It also authenticates the bridge, so an active censor can’t probe an address, get a valid obfs4 response, and thereby confirm it’s a bridge worth blocking. That probing defence is why obfs4 outlasted its predecessors.
obfs4 works well where the censor blocks by signature. It fails where the censor is aggressive enough to block unrecognised random-looking traffic by default — a “block everything we can’t positively identify” posture that some firewalls now adopt during sensitive periods — or where they’ve discovered and blocked the specific bridge. Which is exactly the gap Snowflake fills.
Snowflake: bridges made of strangers’ browsers
Snowflake is the clever one. Instead of connecting to a fixed bridge, your Tor client connects to a temporary, ephemeral proxy running inside some volunteer’s web browser, on the other side of the world, using WebRTC — the same peer-to-peer protocol that powers video calls.
This matters for two reasons. First, the proxies are disposable: a Snowflake proxy is just a browser tab a volunteer left open, here for minutes then gone, so there’s no stable address for a censor to block. Second, the traffic looks like a WebRTC video call, which censors are extremely reluctant to block wholesale because doing so breaks every legitimate video conference in the country — and in 2026, blocking video calls wholesale is politically expensive in a way it wasn’t a decade ago.
Running a proxy yourself is genuinely a one-click affair — there’s a browser extension, and a webpage that turns any open tab into a proxy:
| |
The rendezvous step — how your client finds a volunteer — has historically leaned on domain fronting, where the connection appears to go to a large cloud provider that the censor doesn’t dare block. As cloud providers have grown twitchy about fronting over the years, the Tor Project has kept several rendezvous methods alive (an AMP-cache path, a couple of fronts) precisely so that losing one doesn’t kill the whole channel. This redundancy is the quiet engineering that keeps Snowflake alive: the censor has to defeat every rendezvous method simultaneously, not just one.
There’s a subtlety worth naming. Snowflake separates signalling (finding a peer, done through the censorship-resistant rendezvous) from the data channel (the actual WebRTC tunnel to the volunteer). The censor might see one and not the other, and defeating Snowflake means attacking both — a meaningfully harder job than blocking a static bridge address.
The volunteer side is worth understanding too, because it’s the part anyone can contribute to. A Snowflake proxy doesn’t relay to the wider Tor network directly; it only ferries a censored user’s traffic to the Snowflake bridge, which then enters Tor. That’s deliberate: it means running a proxy carries almost none of the legal exposure of running a Tor exit node, because the proxy never sees the user’s actual destination and never emits traffic to arbitrary sites. You’re a disposable stepping-stone, not an exit. That distinction is why the Tor Project can credibly ask ordinary people to run a proxy in a browser tab, where they’d never ask them to run an exit.
Connection Assist and just making it work
The other quiet improvement of recent years is that you no longer need to understand any of the above. Tor Browser’s Connection Assist will, when it detects you’re being censored, automatically try bridges and transports for your location and pick what works — fetching fresh bridges over a censorship-resistant channel (Moat) if the built-in ones are blocked. For most people in most blocked regions, the honest 2026 instruction is: open Tor Browser, let it sort itself out, only reach for manual bridge lines if it can’t.
This is a genuine usability shift, and it’s the right one. Every manual step — pasting a bridge line, choosing a transport, editing torrc — is a step where a non-technical user under real pressure makes a mistake or gives up. Moving that logic into the browser, so it fetches location-appropriate bridges and tries them automatically, is worth more to the median censored user than any individual clever transport. The clever transports still matter; they’re just now something the software selects rather than something the human has to.
Troubleshooting: when it won’t connect
If Tor Browser sits at “Establishing a connection” and never completes, the failure is almost always at one of three points, and they’re worth distinguishing before you start swapping bridges at random.
Connection Assist can’t fetch fresh bridges. If even Moat is blocked, the browser can’t pull new bridge lines, and you’re stuck with whatever’s built in. The fix is out-of-band: get a bridge line from the Tor Project’s Telegram bot or the email autoresponder (email [email protected] from a Gmail or Riseup address), then paste it manually. Keep one working obfs4 line saved somewhere offline for exactly this moment.
Snowflake connects but is unusably slow or drops constantly. That’s not a misconfiguration — it’s the nature of routing through a stranger’s home connection. Let it re-negotiate; Snowflake will cycle to a different volunteer proxy, and some are far better than others. If every proxy is bad, the local network may be throttling WebRTC specifically, in which case fall back to an obfs4 bridge.
Everything worked yesterday and nothing works today. Either your specific bridge got discovered and blocked (switch to a fresh one), or the censor tightened the rules during a sensitive event. During elections and unrest, firewalls get more aggressive on a schedule; if a whole transport dies overnight, try a different one rather than assuming your setup broke.
The honest limits
None of this is magic. A determined censor with enough resources can still degrade Snowflake by attacking the rendezvous, and very aggressive firewalls have at times throttled WebRTC itself. Performance is also real: Snowflake routes you through a stranger’s home connection and then the Tor network, so it’s slow and jittery — fine for reading and messaging, painful for anything heavy. And bridges are a finite resource; the more publicly a batch is shared, the faster it burns.
There’s also a threat-model caveat that gets lost in the “just install Tor Browser” advice. Circumvention gets you reach — the ability to load a page the firewall would block. It does not, on its own, make you invisible to a censor who is watching that you use Tor at all. In places where merely running circumvention software is itself dangerous, the calculus is different and heavier than “which transport is fastest”, and no browser plugin resolves it.
Is it worth it, and who is this for?
If you’re not behind censorship, you don’t need any of this — plain Tor, or just your normal connection, is fine. This whole machinery exists for people in places where the open internet is actively walled off: journalists, activists, ordinary people who want to read something their government would rather they didn’t.
For them, the practical 2026 answer is short. Install Tor Browser and trust Connection Assist first. If you can keep a browser tab open somewhere uncensored, run a Snowflake proxy — it costs you nothing and it’s one of the few acts of genuine, low-effort solidarity the modern net still offers. That solidarity connects to a broader point I keep coming back to about running your own infrastructure: the open net stays open because individuals keep small pieces of it running, and a spare Snowflake tab is about the lowest-effort version of that there is.
The technology is mature, it’s clever, and it works often enough to matter. That’s not nothing in a year when more of the world is behind a firewall than the year before.
Related Content
