Introduction

Fire For The Wall is a project made in the hope of helping people to resist internet censorship. It is an ongoing and maintained guide on censorship-resistant tools, protocols, and networks, as well as the ways that censorship firewalls such as the GFW work.

The guide is organized into these sections:

• Censorship Circumvention Tools
• Censorship Circumvention Protocols
• Censorship-Resistant Networks
• Censorship Techniques
• Censorship Analysis Tools

Each document within these sections will consist of how the protocol, tool, or technique works, what the privacy and security precautions are, what implementations exist for it, and how you can set up and use them.

This guide is under the CC BY-NC 4.0 license, meaning it allows anyone to share, copy, and modify the content as long as they give appropriate credit to the original guide and do not use it for profit.

All contributions to this guide are welcome, but before making any contributions, make sure to read the contribution guidelines first. This will help you structure your documents and provide some rules so the guide stays consistent, even with multiple contributors working on it.

Censorship Circumvention Tools

Circumvention Tools are applications, services, plugins, or websites that implement networks or protocols to bypass censorship. These tools can include VPNs, proxies, websites that provide VPNs, etc.

Because these tools may overlap significantly with the Networks and Protocols sections, only the tools that are not mentioned in the Protocols or Networks sections will be fully explained. For the rest, they will be linked to the original content in their respective sections.

Censorship Circumvention Protocols

A protocol is a set of rules and standards that determine how data is transmitted or received across a network. Protocols define the format of the messages and data, timing, sequencing, and error checking of the data transferring on a network. A censorship circumvention protocol is a set of rules and standards for communication (usually between a server and a client) that are meant to be harder to identify and censor. This is usually done by making the traffic resemble another common protocol. For example, a censorship circumvention protocol might make all traffic look like normal HTTPS traffic, making it harder to block the protocol as it would break most of the internet and be extremely costly to perform. Alternatively, they might make the traffic look like random noise and thus undetectable.

As censorship firewalls like the GFW evolve, new protocols emerge as well. Because of that, something that might have worked yesterday might not work today.

This section will cover protocols, how they can be set up for use as a server and a client, and what privacy measures should be taken for each of them.

Pluggable Transports

Pluggable Transports are technologies used to make internet traffic more difficult to detect and, as a result, more difficult to block. Pluggable transports aren't meant to be used as VPNs or proxies to directly route traffic to the internet; instead, they need to be plugged into another protocol. For example, they might be used with SSH to make its traffic undetectable or used along with Tor to make it harder to detect.

This section will cover these pluggable transports, explain how they work, and show how you can run your own transport and use them with protocols other than just the Tor network.

Obfs3

obfs3 is the precursor to the obfs4 protocol, both developed by the Tor Project to help lift restrictions placed on the Tor Network by countries such as China, Iran, Russia, and more.

Obfs3 is a pluggable transport meant to make traffic look random and not like any other protocol. Although Obfs3 is no longer supported, and its successor, obfs4, does a much better job, it can be used to obfuscate other traffic such as SSH traffic or VPN traffic, and it is still highly effective at bypassing censorship as a standalone obfuscation protocol.

How it works to bypass censorship

obfs3 is a pluggable transport designed to help Tor users bypass internet censorship by disguising Tor traffic as random data, making it harder for censorship systems to detect and block. It achieves this through two main phases:

• Key Exchange Phase: obfs3 employs a custom version of the Diffie-Hellman key exchange ¹ called UniformDH. Unlike traditional Diffie-Hellman, where public keys have a recognizable structure, UniformDH generates public keys that appear as random strings. This randomness prevents censors using Deep Packet Inspection (DPI) from identifying the handshake as part of a Tor connection.

• Data Obfuscation Phase ²: After the client and server establish a shared secret key through UniformDH, obfs3 uses this key to encrypt the Tor traffic. This process, often referred to as "superencipherment," transforms the Tor traffic, which typically relies on TLS and has identifiable patterns, into what looks like random data. By blending in with other internet traffic, it becomes harder for censorship firewalls to pinpoint and block it.

But the traffic does not have to be Tor traffic; the obfs3 protocol can be used as a standalone pluggable transport to do the same thing for protocols like OpenVPN, SSH, and more. And although it is not supported by Tor anymore, it is still a very good option for obfuscating VPN protocol traffic.

However, obfs3 has limitations. It does not modify packet sizes or timing (unlike obfs4), which means advanced censorship systems can still analyze these metadata patterns to detect Tor usage. In addition, obfs3 is vulnerable to active probing attacks, where censors actively attempt to connect to suspected Tor bridges and confirm their identity by completing the obfs3 handshake.

Privacy and Security Measures

Because obfs3 does not alter packet sizes or timing, advanced censors can analyze these metadata patterns. However, this does not mean they can open the packets or see the contents inside.

obfs3 is susceptible to active probing, where a server owned by the censorship firewall tests a suspected Tor bridge by attempting to connect to it. If the connection handshake succeeds in a way consistent with obfs3, the firewall can confirm the bridge’s identity and block it.

obfs3 itself does not ensure the integrity or security of the data it transports and depends entirely on the underlying protocol, such as OpenVPN.

obfs3 is no longer supported or updated, meaning any newly discovered vulnerabilities will remain unpatched. This increases the risk of exploitation by attackers, putting users’ security at greater risk over time.

Always use obfs3 alongside a protocol that provides authentication and data integrity, such as OpenVPN and SSH. This ensures that even though obfs3 lacks these features, the underlying connection remains secure against MitM attacks ³ and data tampering.

The most effective privacy mitigation is to stop using obfs3 and upgrade to obfs4, its successor. obfs4 is designed to resist both flow analysis and active probing attacks.

Implementations

obfsproxy is effectively the only complete and usable standalone obfs3 implementation. Any other references to obfs3 are typically either embedded in legacy versions of Tor software or exist as unmaintained forks or stubs.

How to Use and Set Up

Using obfs3 as a Standalone Wrapper for SSH

This setup allows you to obfuscate your SSH traffic using obfs3, which helps hide the fact that you’re using SSH from censorship or deep packet inspection systems. obfs3 does not replace SSH’s encryption; it only disguises the traffic patterns so they do not resemble SSH.

Server Setup

1. Install obfsproxy

If you don’t have it installed yet, you can usually get it via pip:

pip install obfsproxy

2. Run obfsproxy in server mode

Use this command to start obfsproxy listening for obfs3 connections and forwarding them to the local SSH server:

obfsproxy obfs3 --dest=127.0.0.1:22 server 0.0.0.0:<obfs3_port>

Replace <obfs3_port> with the port you want obfs3 to listen on (for example, 9999). Make sure this port is open in your firewall.

Client Setup

1. Install obfsproxy on your local machine.

2. Run obfsproxy in client mode

This command sets up a local obfs3 proxy that connects to the server’s obfs3 port and forwards traffic to a local port on your machine:

obfsproxy obfs3 --dest=<server_ip>:<obfs3_port> client 127.0.0.1:<local_port>

Replace <server_ip> with your server’s IP address, <obfs3_port> with the port the server is listening on, and <local_port> with a free port on your local machine (for example, 5000).

3. Connect your SSH client through the local obfsproxy

Use your SSH client to connect to the local port:

ssh -p <local_port> [email protected] -D 2080

This connection is tunneled through obfs3 and opens a SOCKS5 proxy on 127.0.0.1:2080 which you can set on different applications to bypass censorship and mask the traffic from simple protocol detection.

The same principles and steps can be applied for protocols like OpenVPN as well.

Important Note: obfs3 only obfuscates the traffic; use it with protocols that provide strong encryption and proper authentication.

[1^]: Further Information: https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange [2^]: obfs3's protocol specs: https://github.com/isislovecruft/obfsproxy/blob/master/doc/obfs3/obfs3-protocol-spec.txt [3^]: Further Information: https://en.wikipedia.org/wiki/Man-in-the-middle_attack

Obfs4

obfs4 is a Tor Project pluggable transport designed to make encrypted traffic look completely random, helping users evade censorship. It is the successor to obfs3 and like obfs3, it disguises Tor traffic, but it also serves as a generic tunnel for other protocols (e.g. SSH or OpenVPN). ¹

Obfs4 can be used by anyone with basic command-line skills on common platforms (Windows, Linux, macOS, Android), requiring only a pluggable-transport proxy. It does not itself provide anonymity or encryption beyond obfuscation - it relies on the underlying protocol (Tor, SSH, VPN, etc.) for security.

How it works to bypass censorship

obfs4 disguises network traffic as random, unstructured data. It is specifically designed to resist both passive inspection and active probing ², making it harder for censors to detect and block. By hiding handshake patterns, encrypting all frames, and optionally obfuscating traffic flow, obfs4 effectively masks protocols like Tor, SSH, or VPNs so they blend into background internet noise. Its design builds on obfs3 but adds critical improvements, especially in preventing active scanning and resisting metadata analysis.

• Authenticated Handshake (Key Exchange): obfs4 uses a strong, one-way handshake (the “ntor” key exchange) with all public keys hidden by the Elligator2 ³ method. In practice, both client and server generate Curve25519 public keys, but those keys are mapped to random-looking strings via Elligator2 so they appear as pure noise. This means a censor’s Deep Packet Inspection (DPI) cannot recognize the key exchange as Tor or any known protocol. For example, Elligator’s mapping allows you to turn random public keys into actual random bytes, which hides metadata. As a result, the obfs4 handshake looks like a harmless stream of random data, not a recognizable cryptographic handshake.

• Encrypted Data Framing: After the handshake, obfs4 derives a shared secret which is expanded into cipher keys. All subsequent traffic is encrypted and authenticated using NaCl’s secretbox (XSalsa20 stream cipher with Poly1305 MAC). Each data frame is individually encrypted and tagged, so the payload appears random. For instance, the obfs4 spec describes splitting data into frames and encrypting them with crypto_secretbox_xsalsa20poly1305. Because of this strong encryption, an observer cannot decipher contents or identify specific protocol markers. The protocol also XOR-obfuscates each frame’s length using a SipHash-derived mask, further hiding packet sizes.

• Traffic Polymorphism: obfs4 inherits and extends the ScrambleSuit idea of protocol polymorphism. It can insert random padding and shape traffic bursts to mask timing and volume patterns. By default it obfuscates burst sizes and (optionally, at some performance cost) can randomize packet lengths. In practical terms, obfs4 can vary how much data is sent in each chunk and even add delays, so that Tor or VPN usage fingerprints (fixed-size cells, byte patterns) are hidden. This ScrambleSuit-like flow obfuscation makes it much harder for statistical traffic analysis to detect Tor or VPN behavior.

• Versatile Wrapping of Traffic: Although designed for Tor bridges, obfs4 is a generic TCP wrapper. The same obfs4proxy software can tunnel any TCP-based protocol. This means you can run obfs4proxy to wrap SSH or OpenVPN connections: your application speaks to a local obfs4 proxy instead of directly to the Internet. The proxy then performs the obfs4 handshake with the remote end and relays encrypted data, making the entire connection look like random noise.

Privacy and Security Measures

Obfs4 only obfuscates traffic; it does not provide full encryption, authentication, or integrity protection for the underlying data. Its job is to disguise your connection so it looks like random noise, not to secure the content itself. For that reason, you must always use obfs4 together with a protocol that provides strong security features, such as Tor, SSH, or a VPN (e.g., OpenVPN or WireGuard). This ensures that even if someone detects or interferes with your obfs4 tunnel, the data inside remains encrypted and protected against tampering.

To maintain your privacy and security when using obfs4:

• Pair it with a secure protocol like Tor, SSH, or OpenVPN for end-to-end encryption and authentication.

• Keep obfs4proxy up to date to patch vulnerabilities that could be exploited to detect or block your connection.

• Protect your bridge information (especially the cert parameter) to prevent censors from probing and blocking your bridge.

• Ensure all traffic flows through the obfs4 tunnel by configuring applications and firewall rules to block any direct connections.

• Use traffic shaping options if needed in high-risk environments to make traffic analysis harder.

• Replace bridges if they become blocked or compromised.

Implementations

The official obfs4 implementation is obfs4proxy, a Go-based pluggable-transport proxy by the Tor Project.

How to Use and Set Up

Obfs4proxy can be used as a standalone wrapper for services like SSH or OpenVPN. The general approach is to run one proxy on the server side forwarding to the local service, and another on the client side forwarding your local traffic to the remote obfs4 endpoint.

Below is an SSH example:

Server Setup

• First install obfs4proxy on the server (e.g. sudo apt install obfs4proxy on Debian/Ubuntu). Create a dedicated state directory (e.g. /var/lib/tor/pt_state/obfs4/).

• Then start obfs4proxy in server mode with environment variables specifying the transport.

• For example, to listen on port 2222 and forward to a local SSH daemon (port 22), you might run something like:

TOR_PT_MANAGED_TRANSPORT_VER="1"  
TOR_PT_STATE_LOCATION="/var/lib/tor/pt_state/obfs4"  
TOR_PT_SERVER_TRANSPORTS="obfs4"  
TOR_PT_SERVER_BINDADDR="obfs4-0.0.0.0:2222"  
TOR_PT_ORPORT="127.0.0.1:22"  
obfs4proxy -enableLogging -logLevel INFO

This tells obfs4proxy to bind (0.0.0.0:2222) for obfs4 connections and forward them to SSH on (127.0.0.1:22).

The proxy will output a generated “cert=” token (its bridge fingerprint) which you will need to use on the client. Make sure firewall allows incoming traffic on the chosen port.

Client Setup

• On your local machine, also install obfs4proxy. Then run it in client mode, pointing to the server’s IP and obfs4 port. For example:

TOR_PT_MANAGED_TRANSPORT_VER="1" \
TOR_PT_STATE_LOCATION="/var/lib/tor/pt_state/obfs4" \
TOR_PT_CLIENT_TRANSPORTS="obfs4" \
obfs4proxy -enableLogging -logLevel INFO

• The above will launch a client obfs4proxy that connects to the server’s obfs4 endpoint. It will open a local SOCKS5 port (printed as “CMETHOD obfs4 socks5 127.0.0.1:xxxxx” in the output) listening for application traffic.

• Finally, configure your SSH client (or other application) to use this proxy. For instance, you could use ssh -o 'ProxyCommand ncat --proxy 127.0.0.1:<socks-port> --proxy-type socks5' user@destination (using ncat from the nmap package) to route SSH through the obfs4 proxy.

• In simpler cases, you could point SSH directly at 127.0.0.1:<socks-port> if it supports it. The client’s traffic will then be wrapped by obfs4 and sent to the server’s obfs4proxy.

The steps above can similarly wrap OpenVPN, HTTPS, or any TCP traffic: just run obfs4proxy on both ends and route the protocol through the local proxy port.

Meek

Meek is a pluggable transport developed by the Tor Project to help users bypass internet censorship in restrictive environments such as China, Iran, and Russia. It builds on earlier obfuscation techniques like obfs3 and obfs4 but introduces domain fronting ¹, making Tor traffic appear as connections to popular web services like Microsoft Azure or Amazon CloudFront. While meek is still supported and integrated into Tor, its effectiveness has diminished in some regions due to major providers like Google and Amazon disabling domain fronting in 2018. However, meek-azure continue to function reliably on Microsoft Azure.

Meek is designed to make Tor traffic indistinguishable from ordinary HTTPS requests to high-profile domains, Using content delivery networks (CDNs) to route data without revealing the true destination. Although primarily built for Tor, meek can be used as a standalone transport to obfuscate other protocols like SSH or VPN traffic, providing an additional layer of camouflage against deep packet inspection (DPI) and blocking.

How it works to bypass censorship

Meek is a blocking-resistant pluggable transport that tunnels Tor traffic through HTTPS using domain fronting, a technique that hides the true destination of the connection by using different domain names at various protocol layers. This makes the traffic appear as if it's directed to a permitted web service (e.g., a Microsoft or Amazon domain) rather than a Tor bridge. ²

Domain Fronting Phase

In domain fronting, the client specifies an "allowed" front domain (e.g., ajax.aspnetcdn.com for Azure) in the visible parts of the connection, such as the DNS query and the TLS Server Name Indication (SNI) extension. However, the actual forbidden destination (the Tor bridge's domain) is placed in the HTTP Host header, which is encrypted under HTTPS and only readable after the TLS handshake by the intermediate CDN. The censor sees a connection to a popular domain. The CDN decrypts the request, reads the Host header, and forwards it to the hidden Tor bridge.

Data Tunneling Phase

Once the connection is established, meek encodes the data stream (e.g., Tor cells) as a sequence of HTTPS requests and responses. The client sends data in HTTP POST request bodies, and the server responds with data in response bodies. To handle bidirectional communication, the client periodically sends polling requests to fetch any pending server-to-client data.

However, meek has limitations. It does not alter packet timings or sizes significantly, leaving it potentially vulnerable to advanced traffic analysis. Also, its reliance on domain fronting means it's only effective where CDNs still support it, and it can be slower due to the overhead of HTTPS polling and intermediary routing.

Privacy and Security Measures

Because meek relies on HTTPS encryption, censors cannot easily inspect packet contents, but they may detect patterns through metadata analysis, such as consistent polling intervals or chunk sizes that differ from typical web traffic. However, this does not allow decryption of the underlying data, which remains protected by the transported protocol (e.g., Tor's encryption).

Meek is susceptible to TLS fingerprinting, where censors identify non-browser-like TLS handshakes. To mitigate this, implementations often use browser extensions (e.g., for Chrome or Firefox) to camouflage the TLS signature as a standard web browser.

Active probing attacks are resisted because probing the front domain would require interacting with a major CDN, but if the censor controls a trusted certificate authority, they could perform man-in-the-middle (MitM) ³ attacks to inspect Host headers - though certificate pinning in modern clients helps defend against this.

Meek itself does not provide authentication or integrity for the transported data; it depends on the underlying protocol, such as SSH or OpenVPN, to handle encryption and MitM resistance.

As meek is still maintained, newly discovered vulnerabilities are addressed, but its dependency on third-party CDNs introduces risks if providers like Microsoft disable domain fronting.

Always use meek with protocols that offer strong authentication and integrity, like SSH or OpenVPN with TLS. This ensures security even if meek's transport layer is compromised.

The most effective privacy mitigation is combining meek with other transports if needed, or migrating to newer alternatives like WebTunnel (which also supports domain fronting) for better resistance to traffic analysis and probing.

Implementations

Meek's primary implementation is in Go which makes it portable across platforms. It is integrated into Tor Browser and available as standalone tools via the official repository.

How to Use and Set Up

Using meek as a Standalone Wrapper for SSH

This setup obfuscates SSH traffic using meek's domain fronting, disguising it as HTTPS to a major web service. Meek does not encrypt the data itself, it only hides the protocol patterns and security relies on SSH's encryption and authentication.

Server Setup

1. Install meek-server

Clone the repository and build (requires Go):

git clone https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/meek.git

cd meek/meek-server

go build

2. Run meek-server

Start it to listen for fronted connections and forward to local SSH:

./meek-server --port=443 --disable-tls

You also need a reflector on a CDN (e.g., Azure). Deploy a PHP or App Engine reflector as per the repo docs, pointing to your server's domain.

Client Setup

1. Install meek-client on your local machine (build similarly from repo).

2. Run meek-client in client mode

This sets up a local SOCKS proxy that fronts through a CDN to the server:

./meek-client --url=https://your-reflector-url/ --front=ajax.aspnetcdn.com --log=meek.log

Replace with your reflector URL (e.g., for meek-azure) and front domain.

3. Connect your SSH client through the meek proxy

Use SSH with the SOCKS proxy (meek-client listens on 1080 by default):

ssh -o ProxyCommand="nc -x 127.0.0.1:1080 %h %p" username@server_ip -D 2080

This tunnels SSH through meek, opening a SOCKS5 proxy on 127.0.0.1:2080 for applications to route traffic and bypass censorship.

The same principles apply to protocols like OpenVPN: configure OpenVPN to use the meek-provided SOCKS proxy.

Important Note: Meek only obfuscates via domain fronting; pair it with encrypted protocols and verify CDN availability, as some (e.g., Google) no longer support it.

References:

Snowflake

Snowflake is a pluggable transport protocol developed by the Tor Project to help bypass censorship imposed on Tor in heavily restricted countries like China, Iran, Russia, and more.

Snowflake works by routing your traffic through volunteer-operated WebRTC proxies to make it look like you are on a video call instead of using Tor.

How it works to bypass censorship

Snowflake hides Tor traffic inside encrypted WebRTC connections, making it appear like ordinary real-time web communication such as video or voice calls. It achieves this by using volunteer-run Snowflake proxies and a central broker, combined with domain fronting and NAT traversal techniques. ¹

The process follows these steps:

• Bootstrapping:
  The Tor client (such as Tor Browser or Orbot) is configured to use Snowflake as a bridge. It first contacts the Snowflake broker using domain-fronted HTTPS - the request appears to target a large, unblockable CDN domain (e.g., google.com), while the actual broker hostname is hidden inside the encrypted TLS headers.

• Proxy Discovery:
  The broker assigns the client an available volunteer Snowflake proxy and sends the proxy’s WebRTC “offer” back to the client. Because the broker communication is domain-fronted, a censor only sees an HTTPS request to a major domain, not the broker’s actual address.

• WebRTC Connection Setup:
  The client and proxy exchange ICE candidates (through the broker) to find a direct communication path, even if both are behind NAT or firewalls. This uses public STUN servers, and TURN servers if direct UDP fails. Once a path is found, a WebRTC DataChannel is established.

• Traffic Relay:
  The volunteer proxy forwards the encrypted traffic into the Tor network. To outside observers, this appears as generic DTLS-encrypted WebRTC traffic, indistinguishable from online conferencing or real-time multiplayer games.

• Ephemeral Proxies:
  Because Snowflake proxies are short-lived and run inside volunteers’ browsers or standalone apps, their IP addresses change constantly. This makes IP-based blocking nearly impossible without over-blocking huge swaths of the Internet.

Snowflake’s design uses both the ubiquity of major CDN domains (for broker communication) and the difficulty of distinguishing WebRTC flows from normal interactive traffic, making it extremely resistant to censorship.

Privacy and Security Measures

Snowflake tunnels traffic over WebRTC DataChannels, which use DTLS and SRTP for encryption. This ensures that the traffic between the client and the proxy remains confidential and integrity-protected. However, this encryption only covers the connection to the proxy; Tor itself provides end-to-end encryption within the network.

Snowflake disguises Tor traffic as normal WebRTC and HTTPS requests. This makes the traffic look like a generic video call and hides Tor fingerprints from DPI, but the obfuscation layer does not authenticate the client or proxy beyond the WebRTC handshake. As a result, malicious proxies could potentially observe traffic metadata if Tor’s end-to-end encryption is not used.

Because Snowflake proxies are operated by volunteers, users implicitly trust that proxies will forward traffic correctly. Tor’s layered encryption protects the actual user data, preventing proxies from seeing decrypted Tor traffic, though they can still infer metadata such as connection timing and volume.

Implementations

Snowflake is available on all major operating systems. Both volunteers and censored users can run Snowflake in various forms:

How to Use and Set Up

Snowflake clients (the Tor user side) can run anywhere Tor Browser or Orbot runs. Volunteers have two main options:

• Browser Extension (Proxy): Desktop users (Windows/Linux/macOS) can install the Snowflake add-on in Chrome, Firefox, or Edge. Once enabled, keeping the browser tab open turns it into an ephemeral proxy that serves blocked users.

• Standalone Snowflake Proxy: For higher bandwidth, you can run the Snowflake proxy application outside the browser. This Go program is provided by the Tor Project. Official guides show how to deploy it on servers (e.g., via Docker or building from source). On Debian/Ubuntu, for example:

sudo apt install golang

git clone https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake.git

cd snowflake/proxy

go build

nohup ./proxy &

(This sets up a Snowflake proxy listening on all UDP ports. The Tor Project’s documentation and scripts handle any additional configuration.)

• Orbot: On Android (and iOS), Orbot integrates Snowflake as a bridge. Users can enable Snowflake in Orbot’s settings and route apps through Tor. Orbot essentially provides a VPN interface that can include Snowflake as a transport.

Clients and proxies are cross-compatible: any Snowflake client can connect to any Snowflake proxy regardless of OS, since the handshake uses WebRTC and standard HTTPS. The only requirement is that the system supports WebRTC/STUN.

Using Snowflake with Tor (end users):

The easiest method is via the Tor Browser or Orbot UI. For Tor Browser (desktop/mobile), go to Settings → Tor → Bridges, enable bridges, and select “snowflake” as the transport. Connect normally to Tor – if the network is blocked, Tor will automatically use Snowflake. No bridge address is needed, as the Snowflake broker’s URL is built into the client.

For Tor daemon or non-GUI setups, add the following to your torrc:

UseBridges 1

ClientTransportPlugin snowflake exec /path/to/snowflake-client \

-url https://snowflake-broker.torproject.net.global.prod.fastly.net/ \

-front cdn.sstatic.net \

-ice stun:stun.voip.blackberry.com:3478,stun:stun.antisip.com:3478,...

Bridge snowflake 192.0.2.3:1

(Replace /path/to/snowflake-client with the actual binary path.) The placeholder 192.0.2.3:1 is required syntactically but is not a real proxy address. After restarting Tor, it will bootstrap via Snowflake.

Other Protocols:

Snowflake is designed as a Tor-only transport. It provides a SOCKS interface into Tor, not a generic VPN for arbitrary services. You cannot directly use Snowflake as an SSH or OpenVPN proxy. If needed, you would first connect to Tor via Snowflake and then route other applications through Tor (e.g., using ssh -o ProxyCommand or Orbot’s VPN mode). In practice, Snowflake is intended solely to reach Tor.

WebTunnel

WebTunnel is a pluggable transport protocol developed by the Tor Project to help bypass censorship in countries like China, Iran, Russia, and others.

WebTunnel works by routing your Tor traffic through standard HTTPS or WebSocket connections, making it look like ordinary web traffic rather than Tor traffic. This allows Tor users to bypass deep packet inspection (DPI) and simple IP blocking without requiring specialized proxy software on the client side.

How it works to bypass censorship

WebTunnel’s design is centered around making Tor traffic appear as standard HTTPS or WebSocket connections. ¹ This is done using a client-server tunneling architecture with the following steps:

• Bootstrapping: The Tor client selects WebTunnel as a bridge. The client then initiates a standard HTTPS/WebSocket connection to a WebTunnel server. The server address can be embedded in the client or obtained via a bridge broker.

• Connection Wrapping: Tor traffic is encapsulated inside WebSocket frames or HTTPS requests/responses. This makes the traffic indistinguishable from normal web browsing. For example, each Tor cell is wrapped in an HTTP POST body or WebSocket message, then unwrapped by the server and forwarded into the Tor network.

• Traffic Encryption: While the outer WebSocket or HTTPS layer provides confidentiality and integrity (TLS encryption), Tor handles end-to-end encryption of actual user data. This ensures that even if the WebTunnel server is untrusted, the Tor traffic content remains confidential.

• Server Relay: The WebTunnel server forwards the unwrapped Tor traffic into the Tor network. To a censor, all that is visible is a normal TLS/WebSocket session to a web server. Any attempt to block these connections would require disrupting widely used web infrastructure, making censorship more costly.

By using ubiquitous web protocols, WebTunnel takes advantage of “collateral freedom”, blocking WebTunnel means blocking normal web traffic. Also TLS protects the transport from eavesdropping and tampering.

WebTunnel servers can be run on ordinary web hosts, including cloud services. This reduces the need for static IP bridges, which are easily blocked.

Privacy and Security Measures

WebTunnel encrypts traffic over TLS, ensuring confidentiality and integrity between client and server. However, this protects only the tunnel to the WebTunnel server, not the Tor network itself since Tor provides the end-to-end encryption.

WebTunnel disguises Tor traffic as normal HTTPS or WebSocket traffic, hiding Tor fingerprints from DPI. The TLS/WebSocket layer does not authenticate the client beyond standard TLS certificates. Malicious servers could see metadata (e.g., timing, volume), but Tor’s end-to-end encryption prevents them from accessing user data.

Users implicitly trust WebTunnel servers to relay traffic correctly. Tor’s layered encryption prevents content leakage, but metadata such as connection timing and size may still be observable by the server.

Implementations

How to Use and Set Up

• Clients: Tor Browser and Orbot can use WebTunnel as a bridge. In the Tor Browser, go to Settings → Tor → Bridges, enable bridges, and select "webtunnel" as the transport.

• Servers/Relays: WebTunnel servers can be run on any host supporting Go. For example, on Debian/Ubuntu:

sudo apt install golang

git clone https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/webtunnel.git

cd webtunnel/server

go build

nohup ./server &

WebTunnel itself is designed primarily to tunnel Tor traffic.

Censorship-Resistant Networks

A network is a group of interconnected devices (like computers, servers, or routers) that communicate with each other using one or multiple protocols. Censorship-resistant networks are networks that implement features like P2P connections, layered routing, and decentralization techniques to make them harder to control or block.

This section covers all the networks that are either censorship-resistant on their own and are separate from the clearnet or can be used to bypass internet censorship.

Tor Network

Tor, or "The Onion Router," is an overlay network (meaning it's a network built on top of another network, which in this case is the internet). The Tor Network isn't meant to be a censorship circumvention tool, but its design allows it to be used to bypass censorship as well. The main usage of this network is to enable its users to communicate anonymously within the network through layered routing and encryption. ¹

Tor works by routing traffic through a series of volunteer nodes. This series of nodes is called a circuit in the Tor network. In a circuit, your data is encrypted to a random node called the entry node, then your data is encrypted to another random node called the middle node, and finally, your data is passed to a random node called the exit node. The encrypted data is peeled to reveal its content and destination, but because of this routing, the source of the traffic is unknown. ²

How it works to bypass censorship

Because of the Tor network's layered routing and exit nodes (which route the Tor network's traffic to the clearnet), Tor can act as a 3-layered VPN, meaning you will send your data to an entry node, and the data will be sent to the clearnet by an exit node that is very likely to have free access to the internet.

The problem is that the Tor network's traffic is detectable by firewalls and can be censored. Also, the entry nodes are known and can be censored using IP filtering or DNS Spoofing techniques. Because of this problem, Tor features some circumvention tools to bypass blocked access to the Tor network.

These circumvention tools are called "pluggable transports" or "bridges." They cannot usually be used directly to obfuscate normal traffic, and they must be used along with the Tor network (they can be used to obfuscate other traffic by some tweaks and modifications). ³

Privacy and Security Measures

Tor network's communications are encrypted and secure, meaning your ISP (Internet Service Provider) cannot decrypt the content of the messages and data passing through. But they can detect that you are using Tor if it is not used with a pluggable transport such as Obfs4 or Snowflake, due to a few reasons:

• Traffic analysis can be used to detect and block Tor connections based on unique characteristics of Tor network's packets, such as packet sizes (Tor has a fixed length for its cell sizes), timing, and encrypted patterns.
• Deep Packet Inspection (DPI) can be used to inspect the fully encrypted data and find specific patterns associated with Tor network's communications.
• Tor has a public list of its entry nodes and exit nodes, which can be easily blocked by firewalls.

Also, if the Tor network is used to access the clearnet, meaning the destination of requests is not inside the Tor network (for example, duckduckgo.com is a clearnet, or normal internet website, and duckduckgogg42xjoc72x3sjasowoarfbgcmvfimaftt6twagswzczad.onion is a Tor network website), the exit node will be able to see the data that it is passing to the destination. But this is less of a problem now that most websites use HTTPS for encryption, leaving only some small metadata for exit nodes to see. And also, when they see the data, they cannot know where it came from.

Implementations

There are two official core implementations of Tor: one is the Tor implemented in the C programming language, and the other is Arti⁴ implemented in Rust. The Rust implementation is not fully ready yet, and it is suggested to use the C implementation for actual privacy reasons.

Also, there are clients built based on these core implementations for different operating systems:

How to Use and Set Up

Tor Network can be used in several ways, including as a client, in which you will only be using the Tor network to communicate anonymously, as a server, in which you will run an onion address that other Tor network users can connect to and communicate with anonymously, and you can run volunteer nodes, in which you will be passing the network's data to other nodes and helping the network become faster, more secure, and more stable.

This guide covers the client side and ways to retrieve Tor bridges (or pluggable transports), because that is what you need in order to bypass censorship.

Getting Pluggable Transports

Public Tor bridges are available on BridgeDB, a website run by the Tor team to provide users with free pluggable transports. These pluggable transports are mainly run by volunteers.

To obtain some bridges, you can go to https://bridges.torproject.org, select the type of pluggable transport you need, and BridgeDB will provide you with a few bridges of that type.

But the problem is that the BridgeDB website is likely to be censored as well. To address this issue, the Tor team has come up with alternative ways to get bridges from BridgeDB, one of which is through email.

To get bridges via email, you need to send an email with an empty subject and a message body of get transport obfs4 to [email protected]. Note that your email provider should be either Riseup or Gmail; otherwise, you won't receive any bridges.

Another way to get bridges is through their Telegram bot. The Tor team has recently launched a Telegram bot that gives users fresh bridges every time they start it. The bot is available at @GetBridgesBot on Telegram.

C Tor

To connect to the Tor network using C Tor, you will need to download and install it first along with the obfs4proxy client to obfuscate the traffic and bypass the restrictions on Tor network communications.

Linux

In most Linux distributions, it will probably be available in the package managers under the name of the tor package. But if it doesn't exist in your repo, you may find a guide on building and installing it from the source code on Tor's community documents: https://community.torproject.org/onion-services/setup/install/.

After installing Tor, you need to install obfs4proxy in order to make Tor capable of using obfs4 bridges.

Obfs4proxy might not be available in all package managers under the same name, or at all:

If you can't find the obfs4proxy package for your distribution, you can compile and install it from its source:

1. Install dependencies: go and git packages are needed.

2. Clone the repository:

   git clone https://gitlab.com/yawning/obfs4.git
   

3. Switch directory to the cloned repository:

   cd obfs4
   

4. Build and install from the source code:

   go build -o obfs4proxy/obfs4proxy ./obfs4proxy
   cp obfs4proxy /usr/bin/obfs4proxy
   

Now you can configure C Tor to use obfs4proxy as its pluggable transport:

1. C Tor's configuration file is usually located at /etc/tor/torrc, and that is the file you want to edit. Open the file /etc/tor/torrc with any editor you have, and make sure to open it with root permission to be able to write on it:

   # For example gedit editor:
   sudo gedit /etc/tor/torrc
   

2. Go to the end of the file and add these lines. Make sure to replace the Bridge <Bridge You Retrieved from BridgeDB> with the actual bridge you retrieved, for example: obfs4 141.95.106.58:19053 4283C0BA9294F931BE3B274C1DF6A7C1B67CD36A cert=TajDhn51Jd3NeF0azqY8oFYCeA/oha/UWod9pqiV9igDbwqfV1fO2uLC8Sa9Xa+3qZEcLA iat-mode=0:

   UseBridges 1
   Bridge <Bridge You Retrieved from BridgeDB 1>
   Bridge <Bridge You Retrieved from BridgeDB 2>
   Bridge <Bridge You Retrieved from BridgeDB 3>
   ClientTransportPlugin obfs4 exec /usr/bin/obfs4proxy
   

3. Start the Tor service:

   systemctl start tor
   

After starting Tor, it will create a SOCKS5 and SOCKS4 proxy on the address 127.0.0.1 and port 9050 (by default), which can be set as proxies on the system, different apps, etc., to bypass censorship.

Windows

To use C Tor on Windows, it would be easier to use Tor's Expert Bundle ⁷, as it contains other pluggable transports like Snowflake and Lyrebird, along with the geoip files needed for Tor to operate.

You can download the Tor Expert Bundle package for Windows using the link below:

https://www.torproject.org/download/tor/

Then extract the downloaded ZIP file to a directory, for example: C:\Tor

For the obfs4proxy, since Windows doesn’t have package managers like Linux, you'll need to manually build obfs4proxy. For that, you'd need to install Go and Git first:

After you install the Go and Git packages, you can build and install obfs4proxy using PowerShell:

git clone https://gitlab.com/yawning/obfs4.git
cd obfs4
go build -o obfs4proxy.exe ./obfs4proxy
move obfs4proxy.exe C:\Tor\obfs4proxy.exe

Now that you have everything ready, it's time to move on to configuring Tor:

1. The torrc file is located in the directory where you extracted the Tor Expert Bundle. Open it using any editor you like.

2. Add the following lines at the end of the file, replacing <Bridge You Retrieved from BridgeDB> with actual obfs4 bridges from Tor BridgeDB:

   UseBridges 1
   Bridge <Bridge You Retrieved from BridgeDB 1>
   Bridge <Bridge You Retrieved from BridgeDB 2>
   Bridge <Bridge You Retrieved from BridgeDB 3>
   ClientTransportPlugin obfs4 exec C:\Tor\obfs4proxy.exe
   

3. To start the Tor service, use PowerShell and navigate to the Tor directory:

   cd C:\Tor
   

4. Start the Tor process:

   tor.exe -f "C:\Tor\Data\Tor\torrc"
   

   Once Tor is running, it will create a SOCKS5 proxy at 127.0.0.1:9050. You can configure your system or applications to use this proxy to route traffic through Tor.

macOS

The installation process for C Tor on macOS is quite similar to Linux; it should be installed using a package manager:

If you don't have the Homebrew package manager, install it using the command below:

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

The obfs4proxy package is also available in Homebrew, and you can install it using the command below:

brew install obfs4proxy

After you have both C Tor and obfs4proxy installed, you can configure the torrc file, which is typically located at /usr/local/etc/tor/torrc:

1. Open the file with root permission using any editor you like:

   sudo nano /usr/local/etc/tor/torrc
   

2. Add the following lines at the end of the file, replacing <Bridge You Retrieved from BridgeDB> with your actual obfs4 bridges from BridgeDB. Then save the file and exit the editor.

   UseBridges 1
   Bridge <Bridge You Retrieved from BridgeDB 1>
   Bridge <Bridge You Retrieved from BridgeDB 2>
   Bridge <Bridge You Retrieved from BridgeDB 3>
   ClientTransportPlugin obfs4 exec /usr/local/bin/obfs4proxy
   

3. Restart the Tor service:

   brew services start tor
   

   Alternatively, you can start Tor manually by running the command tor.

Once Tor is running, it will create a SOCKS5 and SOCKS4 proxy at 127.0.0.1:9050. You can configure your system or applications to use this proxy to bypass censorship.

Tor Browser

To install Tor Browser for your operating system, go to Tor's download page and download it for your OS:

https://www.torproject.org/download/

For Windows, macOS, and Android, it would be a .exe, .dmg, and .apk file, which can be installed easily. However, for Linux, it is a compressed .tar.xz file, which you need to extract and run the executable file inside.

After opening the Tor Browser, you will see a browser like this:

Here, you can click on the "Configure a Connection" button and add your bridges. Bridges can be added from the built-in bridges:

Or from custom bridges retrieved from BridgeDB:

When you have added your bridges, you can return to the start page and click on "Connect." After a successful connection, you can either use it as a censorship-free browser or use a SOCKS proxy outside the browser at 127.0.0.1:9150. Note that this SOCKS proxy is only available as long as your Tor Browser is open, running, and connected.

Orbot

Orbot is a project by the Guardian Project, fully open source and released under the BSD-3-Clause License, which is a free license. Orbot is a VPN and Proxy app that tunnels network traffic through the TOR Network.

To use Orbot, you first need to download and install it for your device architecture. Here is a list for downloading and installing on Android Devices:

Note: Be aware that to install Orbot from F-Droid, you will need to add the Guardian Project's repository to your F-Droid. For more information, check Guardian Project's guide.

Here is a list for installing Orbot on iOS Devices:

After installing Orbot, the usage is fairly straightforward: you add your bridges if needed and tap "Connect."

If you have created your own bridges and want to use those instead of public bridges, consider the option "Custom bridges" and paste the bridge lines there. Otherwise, the app will provide you bridges from BridgeDB if you use other options.

Censorship Techniques

Every censorship system must apply some techniques in order to detect traffic and block it. These techniques might be old and simple, such as IP filtering, or very complicated, like deep packet inspection or active probing.

This section is focused on explaining how these techniques work and what the circumvention methods are for each of them.

DPI (Deep Packet Inspection)

DPI (Deep Packet Inspection) is a network traffic analysis technique that goes beyond simple packet headers. Instead of just reading metadata like source/destination IP addresses or port numbers, DPI inspects the payload (the actual data inside the packet).

DPI can:

• Identify the application or protocol in use (e.g., HTTPS, SSH, OpenVPN, WireGuard, etc.).

• Detect specific content or keywords inside communications.

• Monitor, filter, or block traffic based on patterns even in fully encrypted traffic.

DPI requires significant computational resources and sophisticated algorithms, meaning it is typically employed by large ISPs or government entities. Making it a tool of state or corporate control, often deployed with little transparency or accountability.

How Does It Enable Censorship?

DPI can detect protocols like VPNs, Tor, or encrypted messaging apps and selectively block or throttle them to prevent circumvention.

DPI can interfere with connections by injecting TCP reset packets or slowing down traffic to degrade service quality for certain content.

Rather than outright blocking, DPI can prioritize or degrade certain content, enabling subtle censorship that’s harder to detect.

Unlike simple IP or DNS blocking, DPI examines content inside the packet, allowing censorship of specific messages or content even within allowed domains. And because DPI inspects packet contents, simple workarounds like changing IP addresses or domains don’t work well. It can also detect encrypted VPN traffic by patterns or protocol signatures.

DPI inherently enables mass surveillance, since inspecting payloads means potentially capturing private communications.

Increasing use of HTTPS and other encryption protocols limits DPI's effectiveness. But even encrypted traffic has characteristic patterns (packet sizes, timing, sequence of packet lengths, handshake patterns). Also, DPI systems identify what protocol or application is being used (e.g., VPN type, Tor, HTTPS) by these signatures. For example, OpenVPN and WireGuard have distinctive packet sizes and timing patterns, making them easy for DPI to throttle or outright prevent handshakes and connection establishment using these protocols.

Also, TLS handshakes send some unencrypted information (like the list of cipher suites, extensions). DPI can use these to guess which protocols or websites might be involved.

On top of that, DPIs can perform SNI (Server Name Indication) inspection. In the TLS handshake, the SNI field reveals the hostname the client wants to connect to; this part is usually unencrypted. DPI systems can easily block access based on this hostname.

Note: TLS 1.3 with Encrypted SNI (ESNI), now called Encrypted Client Hello (ECH), aims to prevent this. But DPI systems can prevent ECH connections if they're desperate.

How to Circumvent It?

DPI systems rely on analyzing packets, headers, payloads, or traffic metadata to:

• Detect certain keywords, signatures, or protocols.

• Identify applications or user behaviors.

• Enforce blocking, throttling, or modification.

Circumvention means preventing DPI from accurately detecting or classifying your traffic or content.

Expensive Protocols

Expensive protocols are those protocols whose blocking entirely breaks almost all modern web services.

These are protocols like TLS, HTTPS, QUIC, WebSocket, SSH, etc. Firewalls usually avoid full blocking and instead use targeted DPI or traffic analysis to identify specific forbidden content inside these protocols.

Using these protocols can and will help bypass firewalls unless they're willing to break everything for the sake of preventing the flow of information.

Protocol Obfuscation

Use of obfuscation protocols like obfs3, obfs4, etc., can help make the underlying traffic look like random noise and prevent attacks through timings and active probing (in the case of obfs4).

Camouflage Protocols

Camouflage protocols are protocols that make your traffic look like another protocol or look like legitimate traffic. For example, Snowflake makes your traffic look like a normal WebRTC meeting call; Trojan protocol can make your traffic look like normal HTTPS website traffic; or VLESS protocol can make your traffic look like normal WebSocket/QUIC/gRPC connections.

DNS Spoofing

DNS spoofing (also called DNS poisoning) is a type of man-in-the-middle attack commonly used by censorship firewalls to block access to specific domains. DNS translates human-readable addresses (like fireforthewall.org) into the IP addresses that machines use. By tampering with this process, authorities can redirect, block, or manipulate user connections.

Unlike deep packet inspection (DPI), which alters traffic payloads directly, DNS spoofing corrupts only the mapping between domain names and their intended servers, making it a lighter but effective method of censorship.

How Does It Enable Censorship?

Authorities can use DNS spoofing to enforce censorship by manipulating how domain names resolve. Instead of returning a normal “site not found” error, requests to banned domains may be redirected to government-controlled portals, error pages, or simply made to fail. This allows authorities not just to block access, but also to spread propaganda or misinformation through the redirect.

Unlike deep packet inspection (DPI), DNS spoofing does not require tampering with encrypted traffic. Control is exerted at an earlier stage, before any connection is established. Because DNS requests are small, automatic, and largely invisible to end users, most people don’t immediately notice when spoofing is taking place.

Technically, DNS spoofing is simpler but less precise than DPI. It operates only at the domain level, meaning authorities can block or redirect entire sites but cannot filter specific content within them. Usual methods include:

• Cache poisoning: inserting forged DNS replies into a resolver’s cache so that all subsequent queries resolve incorrectly.

• Race interception: replying to DNS queries faster than the legitimate DNS server to force acceptance of a fake response.

• Resolver manipulation: directly altering DNS records on ISP-controlled resolvers, enabling censorship at scale.

How to Circumvent It?

Circumvention involves preventing DNS queries from being tampered with while in transit. Since the standard DNS protocol is unencrypted, censors can easily detect and manipulate requests. Encrypting DNS traffic is therefore a key defense.

Encrypted DNS Protocols

• DNS over HTTPS (DoH), DNS over TLS (DoT), and DNSCrypt encrypt DNS queries, preventing on-path injectors from modifying responses.

• However, authoritarian regimes may detect and block DoH/DoT endpoints entirely, limiting their effectiveness.

Tunneling & VPNs

• When using a VPN, DNS queries are resolved by the VPN provider rather than the local network or ISP, rendering local DNS spoofing ineffective.

• If VPNs themselves are blocked (e.g., via DPI), DNS circumvention may be disrupted as a side effect.

• The Tor Network can also be used for DNS resolution, offering a similar protection layer against local manipulation.

WIP

WIP

Censorship Analysis Tools

Censorship Analysis Tools are specialized software or methods designed to detect, measure, and analyze censorship activities across different platforms and regions. These tools help researchers, activists, and organizations understand how much of the internet is censored, what content is blocked, how these censorship firewalls are evolving, and based on this data, develop strategies to circumvent these restrictions.

This section will cover tools that can be run by users, including the risks and safety measures that need to be taken before performing any analysis tests, as well as the organizations that focus on monitoring the behavior of censorship firewalls.

Contribution Guidelines

If you want to contribute, please follow these simple rules to help keep everything clear and useful:

Licensing and Credit

1. License: All content is under the CC BY-NC 4.0 license. You can share, copy, and modify the content as long as you give proper credit and don’t use it for commercial purposes.

2. Credit: You can credit yourself for sections you write by using markdown footnotes. For example:
   [^C1]: This section was written by [Author Name]((Webpage/Email/Or Donation Address))

Content Creation

1. No AI-Generated Content: Please write the content yourself. AI can only be used for fixing grammar and spelling errors, not for creating or generating information. If moderators suspect content is AI-generated, it may not be approved.

2. Link Additional Resources: If there are other helpful resources related to your content, link to them using markdown footnotes. For example:
   [^R1]: Find more details: [link](link).

3. Screenshots: If you need to add screenshots, make sure they are clear and of good quality. Reduce the size or use formats like JPG to keep them manageable.

Formatting and Consistency

1. Follow the Guide Format: Match the structure of the existing guide. Each section should have a similar format and provide clear explanations, just like the rest of the guide.

2. Content Structure: Each document should include:

   • How It Works: Explain the protocol, tool, or technique.
   • Privacy and Security Measures: Cover any important privacy and security considerations.
   • Implementations: Describe existing implementations.
   • Setup and Use: Provide instructions on how to set up and use it.

By following these guidelines, you help maintain the quality and consistency of the guide, making it easier for everyone to use and understand. Thank you for your contributions comrade *salutes*!

Clearnet

Clearnet is the publicly available portion of the internet. It is the part of the web that is easily accessible using standard web browsers and does not require any special configurations or tools to access. Unlike the deep web or dark web, the clearnet is open and not hidden behind special configurations.