Below is a clean, high‑level system design for a Tor bridge distribution
model where the user never sees the bridge, yet can use new pluggable
transports (PTs). This stays architectural (not exploit‑level), which is
how Tor itself discusses these ideas.
------------------------------
Goal
Design a bridge distribution system that:
1.
Hides bridge details from the Tor Browser user
2.
Supports new / experimental pluggable transports
3.
Reduces bridge enumeration by censors
4.
Works under heavy DPI and HTTPS‑only regimes
5.
Fits Tor’s existing trust and threat model
------------------------------
Core idea: Brokered, capability-based bridge access
Instead of giving users bridge addresses, give them temporary access
capabilities that let Tor connect without the user ever knowing where.
Think:
“I have permission to use Tor right now”
not
“Here is a bridge IP:port”
------------------------------
1. High-level architecture
Tor Browser
|
| (Capability request)
v
PT Broker (trusted, rotating)
|
| (Ephemeral routing info)
v
Hidden Bridge Network
|
v
Tor Network
The user:
-
Never sees IPs, domains, fingerprints
-
Just toggles “Censorship Mode” or “Transport X”
------------------------------
2. Step-by-step flow
Step 1: Capability request (not a bridge request)
Tor Browser requests:
“I support PT-X, need access”
This request:
-
Looks like normal HTTPS
-
Is indistinguishable from other web API calls
-
Contains no identifying Tor metadata
------------------------------
Step 2: Broker returns a capability, not a bridge
Instead of:
bridge 1.2.3.4:443 fingerprint=...
The broker returns:
Signed capability token:
- Valid for N minutes
- Bound to PT-X
- One-time or rate-limited
The user cannot:
-
Reuse it
-
Share it
-
Inspect it meaningfully
------------------------------
Step 3: PT resolves bridges internally
The pluggable transport:
-
Uses the capability to:
-
Discover a relay internally
-
Or connect via indirection (proxy mesh, rendezvous, relay lottery)
-
Bridge details exist only inside the PT process
Tor Browser:
-
Never logs
-
Never stores
-
Never displays bridge info
------------------------------
3. Why this defeats mass bridge enumeration
China can:
-
Request capabilities ✔
-
Use them ✔
But they cannot:
-
Bulk harvest bridge IPs
-
Build blocklists
-
Learn topology
-
Distinguish user vs censor requests reliably
Blocking becomes:
-
Reactive
-
Noisy
-
Collateral-heavy
------------------------------
4. Enabling new pluggable transports
This model is PT‑agnostic.
A new transport just needs:
-
Capability verification
-
Broker interface support
Examples of future PTs this enables:
A. HTTPS semantic PTs (Webtunnel++)
-
PT pretends to be:
-
REST API
-
WebSocket app
-
Video streaming backend
-
Broker rotates semantics, not just IPs
------------------------------
B. Relay lottery PT
-
Capability unlocks:
-
One of many hidden bridges
-
Randomly chosen
-
Short-lived
-
Censor can’t predict which bridge they’ll hit next
------------------------------
C. Multi-hop PT
-
Capability allows:
-
Entry via CDN → hop → hop → Tor
-
No single blocking point
------------------------------
5. Why hiding bridges from users is important
Today:
-
Users copy/paste bridges
-
Bridges leak via screenshots, logs, malware
-
Support forums leak them
-
Censors scrape everything
With this design:
-
No bridge strings exist
-
Nothing human-readable
-
Nothing stable to leak
This is zero-knowledge bridge usage from the user’s perspective.
------------------------------
6. Trust and failure model (important)
This does not require trusting the broker with identity.
Broker knows:
-
“Someone asked for PT-X access”
-
Nothing about browsing
-
Nothing about destination
Even if broker is:
-
Monitored
-
Partially blocked
-
Compromised
Worst case:
-
Access degrades
-
Tor safety remains intact
------------------------------
7. Why Tor hasn’t fully done this (yet)
Real constraints:
-
Backward compatibility
-
PT ecosystem maturity
-
Operational cost
-
Risk of centralisation
-
Need for multiple independent brokers
But Snowflake is already halfway there:
-
User doesn’t see proxies
-
Dynamic routing
-
Indirection-based access
This proposal generalises that model.
------------------------------
8. One-sentence summary
Replace “bridge distribution” with “capability distribution”, and let
pluggable transports resolve bridges invisibly and ephemerally.
------------------------------
Next we can:
-
Map this design onto existing Tor components
-
Show how Snowflake already approximates it
-
Design a concrete PT using this model
-
Explain how this resists China specifically
-
Discuss centralisation vs censorship trade-off.
