Decoy routing and refraction networking

Most circumvention designs work from the endpoints: client and server are both circumvention software; the network in between is hostile. Refraction networking (originally "decoy routing") inverts this: the censorship circumvention is provided by cooperative infrastructure positioned on ordinary network paths between the client and arbitrary destinations. The client connects to a normal-looking decoy site; somewhere along the path, a cooperative router recognizes a covert signal in the traffic and diverts the connection to a hidden backend service.

The architectural insight is that a censor cannot easily block what they cannot enumerate. Bridge-based circumvention (obfs4, REALITY) requires fixed bridge endpoints that censors can discover and block over time. Refraction networking puts the circumvention in routers along arbitrary paths — there's no enumerable list of "circumvention IPs" because any traffic to any decoy might be circumvention traffic, depending on whether a cooperating router intervenes.

This module covers the design family: Telex (the originating proposal), TapDance (the practical follow-up), Slitheen (the censorship-resistant browsing variant), and Conjure (the most recent deployable form). Each addresses limitations of its predecessors. The whole family shares the strength — and the central weakness — that deployment requires cooperation from network-path infrastructure operators.

Prerequisites

• network-level-traffic-analysis — refraction operates at the network layer.
• active-probing-methodology — the threat model refraction addresses differently from bridge designs.
• pluggable-transports-the-obfs-lineage — the bridge-based alternatives refraction complements.

Learning objectives

1. Explain what refraction networking is and how it differs from bridge-based circumvention.
2. Describe the Telex/TapDance/Slitheen/Conjure design lineage and what each contributed.
3. Identify the strategic strengths (non-enumerable cover, infrastructure leverage) and weaknesses (deployment dependency, ISP cooperation requirements) of refraction designs.
4. Evaluate when refraction networking is the right tool versus when bridge-based or other approaches fit better.

What refraction networking does

A normal HTTPS connection looks like:

[Client] ──── encrypted bytes ──── [Decoy Site]

The client opens TLS to a decoy site (a real, popular HTTPS website). Encrypted bytes flow back and forth; the destination is decoy.example.com.

A refraction-networking connection looks like:

[Client] ──── encrypted bytes ──── [Refraction Router] ──── encrypted bytes ──── [Decoy Site]
                                       │
                                       └─── covertly redirected ──── [Hidden Backend]

The client still opens what looks like a normal HTTPS connection to the decoy site. The connection traverses normal network paths. Somewhere in the path, a cooperating refraction router recognizes a covert signal in the traffic. The router intercepts the connection and diverts it to a hidden backend service — but the client and the decoy site both see it as a normal HTTPS connection (the decoy site receives some traffic; the client receives responses that look like decoy responses).

For a censor:

• Blocking refraction means blocking the decoy site (collateral damage).
• Detecting refraction is hard because the traffic looks like normal HTTPS to the decoy.
• Enumerating refraction proxies is impossible — the proxies are routers in cooperative networks; there's no list to enumerate.

For the user:

• The connection looks like ordinary HTTPS to a popular site.
• The decoy can be different per session (so behavioral patterns don't repeat).
• The hidden backend is reached without ever connecting to it directly.

Telex (2011): the originating proposal

Telex (Wustrow et al., USENIX Security 2011) introduced the refraction-networking concept. The mechanism:

Setup. The Telex station is a router operated by a cooperative ISP. The station has a public-private keypair.

Connection. Client opens TLS to a decoy site, including a covert signal embedded in the TLS handshake (a specific tag in the ClientHello, derived from the Telex public key). The handshake completes normally with the decoy site.

Detection. As packets flow through the Telex-equipped network, the Telex station inspects them. When it recognizes the covert tag, it knows this is a refraction-targeted connection.

Diversion. The Telex station intercepts the connection: it decrypts the TLS using a key it can derive from the covert tag (the client and Telex share material via the public-key crypto), reads the actual destination request from the encrypted payload, and forwards traffic to the hidden backend instead of to the decoy. Responses come back through the same path.

Decoy traffic. The decoy site sees some initial traffic but doesn't see the bulk of the user's actual activity. The Telex station maintains a fake conversation with the decoy to keep the appearance plausible.

The Telex paper demonstrated the concept worked. The deployment never reached production because of operational issues — coordinating with ISPs to deploy Telex stations was hard, and the technical complexity of the station was substantial.

TapDance (2014): asynchronous diversion

TapDance (Wustrow et al., USENIX Security 2014) addressed Telex's deployment difficulties. Key change: the diversion is asynchronous and one-directional. The TapDance station observes traffic going through the cooperative ISP but doesn't need to be on the bidirectional return path.

The mechanism:

Setup. TapDance stations sit at ISP-level vantage points where they can passively observe outbound traffic from the censored region.

Connection. Client sends an HTTPS request to a decoy site. The request includes a covert signal — but unlike Telex, the request body itself is the channel. The client uses a TapDance-specific HTTP request format that embeds proxy data as the request body.

Detection. The TapDance station observes outbound HTTPS connections; for connections matching the TapDance-specific signal, the station claims the connection from the decoy site (sends an injected response to the client; the decoy site doesn't notice this side-channel happening — the station essentially impersonates the decoy for the client).

Communication. Client and TapDance station now have a covert channel. The decoy site is essentially out of the loop; the station handles the proxy logic.

The TapDance contribution was making refraction practical to deploy: stations could be added without modifying ISP infrastructure as deeply as Telex required. The asynchronous design avoided needing bidirectional path control.

TapDance had limited deployments (some research-prototype installations) but didn't reach mass scale.

Slitheen (2016): browsing-traffic-shaped responses

Slitheen (Bocovich and Goldberg) extended the refraction model to make the proxy traffic look like normal browsing traffic. The previous designs sometimes had distinctive flow patterns that could be detected; Slitheen tried to shape proxy responses to match what the decoy site would actually send for a normal browsing session.

The mechanism: when the refraction station diverts a connection, instead of replacing all the decoy's responses with proxy responses, it keeps some real decoy responses (images, fonts, irrelevant resources) flowing through and only replaces the meaningful payload with proxy data. The combined traffic shape is closer to a normal browsing session than the proxy data alone.

The cost: more complex station logic; need to coordinate with decoy site behavior; bandwidth overhead from real decoy traffic mixed with proxy data.

Slitheen advanced the conceptual design. Real-world deployment remained limited.

Conjure (2019+): deployable refraction

Conjure (Frolov et al., USENIX Security 2019) is the most recent deployable variant. The architectural changes:

Phantom hosts. Instead of diverting traffic to a hidden backend the client knows about, Conjure creates "phantom" virtual hosts — IP addresses that don't actually exist as real hosts but that the cooperative ISP's routers will respond for. Client traffic goes to a phantom IP; the cooperative router intercepts and proxies.

Better covert signaling. Conjure improved the covert-signal embedding in the client's traffic, making it harder for adversaries to detect the signal even with traffic inspection.

Better deployment story. Conjure was designed to be deployable on real ISPs without requiring the deeper infrastructure changes of earlier systems.

Conjure has had production deployments through the Refraction Networking project, including operation by some commercial circumvention services. It remains the most operationally viable refraction design.

Why infrastructure cooperation is the strength

The refraction architecture's central strength: there's no list of refraction proxies to enumerate. Any IP could be a "decoy" for refraction traffic; the censor can't tell which traffic is normal and which is being diverted without seeing the covert signal (which is designed to be hard to detect).

Compare to bridge-based circumvention (obfs4, REALITY): every bridge is a fixed IP that censors can discover and block over time. Refraction has no such enumerable target.

The collateral-damage argument: blocking refraction requires blocking entire networks. Even if a censor knows that a specific ISP runs refraction stations, blocking that ISP's traffic affects all the ISP's legitimate destinations. The economic and political cost is high.

This is the same general pattern as domain fronting — using infrastructure economics to constrain the censor's choices. Domain fronting used cloud CDNs; refraction uses ISP cooperation.

Why infrastructure cooperation is also the weakness

The same property that gives refraction strength gives it deployment fragility:

ISP cooperation requirement. Refraction needs cooperating ISPs to install and maintain stations. ISPs face risks: their relationship with cloud providers, their relationship with governments, their commercial model. Few ISPs have stepped forward to operate refraction stations at scale.

Geographic limitation. Refraction stations need to be on paths the censored users actually traverse. If the cooperating ISPs aren't on those paths, refraction doesn't work for those users.

Operational expertise. Running a refraction station is non-trivial — keep up with protocol changes, handle traffic spikes, integrate with the ISP's existing routing. Most ISPs don't have the expertise.

Censor pressure on ISPs. Censors can pressure ISPs not to cooperate. A national-level pressure campaign against an ISP that hosts refraction stations could shut down the deployment.

Coverage limitations. Even with multiple cooperating ISPs, refraction may not cover all users in a censored region. If most of a country's traffic doesn't traverse the cooperating ISPs, refraction reaches only a fraction of users.

The trade-off is clear: refraction has stronger structural properties than bridge-based circumvention but harder operational deployment requirements. As of 2026, refraction remains a research-grade and limited-production option rather than a mass-deployment circumvention technique.

Where refraction fits in the toolkit

For a circumvention strategist, refraction occupies a specific niche:

• For high-value, low-volume use cases (journalists, activists, researchers in highly-censored regions), refraction's structural strength may justify the deployment effort.
• For mass-volume use cases (consumer VPN services, general internet access), bridge-based circumvention or commercial VPN approaches scale better operationally.
• As a complement to other techniques. A user might use refraction for some specific endpoints and bridge-based circumvention for others.

The bridge-vs-refraction choice is fundamentally about deployment-difficulty vs. censor-resistance trade-offs:

• Bridges are operationally simpler (you just need a server somewhere) but each is enumerable.
• Refraction is operationally harder (needs ISP cooperation) but is non-enumerable.

For most users, bridge-based circumvention is the right choice; for some specific high-stakes users, refraction's structural advantages matter. The deployment ecosystem has not converged on either as the default.

Hands-on exercise

High-level diversion pseudocode.

client_initiates_refraction_connection(decoy_site, hidden_backend_request):
  # Construct a TLS ClientHello that includes the covert refraction signal
  clienthello = construct_tls_clienthello(decoy_site)
  add_covert_signal_to_clienthello(clienthello, refraction_pubkey, hidden_backend_request)

  # Open TCP to decoy site
  conn = open_tcp(decoy_site, port=443)
  send(conn, clienthello)

  # Either:
  # (a) The traffic traverses a refraction-equipped network. The station detects
  #     the covert signal, intercepts the response from the decoy site, and substitutes
  #     proxy responses. Bidirectional proxy session ensues.
  # (b) The traffic doesn't traverse a refraction-equipped network. The decoy site
  #     responds normally. The client falls back to retrying via a different decoy
  #     or via a different transport.

  serverhello_or_proxy_response = receive(conn)

  if is_proxy_response(serverhello_or_proxy_response):
    proceed_as_refraction_session(conn)
  else:
    # No refraction station on this path; fall back
    close(conn)
    try_alternative_path()

The covert signal embedding is the key cryptographic challenge — it must be invisible to censors observing the traffic but recognizable to refraction stations.

Deployment comparison table.

The trend: each generation reduced station-logic complexity to make deployment easier; Conjure is the most deployable.

Common misconceptions and traps

"Refraction networking is a Tor replacement." It's not — it's a transport architecture. The hidden backend can be a Tor relay or a regular proxy or anything else. Refraction provides the hidden-from-censor connection; what's at the other end is independent.

"Refraction is undetectable." The covert signaling is designed to be hard to detect, but censors can still attempt classification. Behavioral patterns of refraction-using users may be distinguishable from non-using users over time.

"Refraction needs cooperation from US ISPs only." Refraction needs cooperation from ISPs on the paths the censored users actually traverse. For a user in country X, refraction stations need to be in or near country X — preferably in upstream networks the country's traffic must cross.

"Conjure works in any country." Conjure works wherever there are deployed refraction stations on user paths. Coverage is limited; many regions have no deployment.

"Refraction makes blocking impossible." Censors can block by attacking the cooperating ISPs (legal, political, technical pressure). The mechanism is structurally strong but operationally fragile.

Wrapping up

Refraction networking — Telex, TapDance, Slitheen, Conjure — is an architectural alternative to bridge-based circumvention. Instead of running circumvention proxies that censors can enumerate and block, refraction puts the circumvention in cooperative routers along ordinary network paths.

The structural property is powerful: censors can't enumerate refraction proxies because there's no list — any traffic to any decoy might be diverted by an in-path station. The collateral-damage argument is strong: blocking refraction requires blocking entire ISPs, which censors generally won't do.

The operational property is challenging: deployment requires ISP cooperation, technical expertise, and infrastructure investment. Few ISPs have stepped forward at scale, leaving refraction as a research-grade and limited-production option.

For specific high-stakes users, refraction's structural advantages may justify the deployment effort. For mass-volume use cases, bridge-based circumvention scales better. The right tool depends on the specific user, threat, and available infrastructure.

The next module (traffic-shaping-for-camouflage — coming soon) covers traffic shaping at the proxy level — making proxied traffic look like benign traffic by reshaping its observable patterns.

Further reading

• Telex: Anticensorship in the Network Infrastructure — Wustrow et al., 2011 — the originating paper.
• TapDance: End-to-Middle Anticensorship — Wustrow et al., 2014 — the practical refinement.
• Slitheen: Perfectly Imitated Decoy Routing — Bocovich and Goldberg, 2016 — the browsing-traffic-shaped variant.
• Conjure: Summoning Proxies from Unused Address Space — Frolov et al., 2019 — the most deployable design.