There are many different transports which address a wide variety of blocking strategies. At a very high-level standpoint, they can be grouped into three categories:


Fronting approaches leverage cloud platforms which are socially or economically difficult to block - for example, allowing access to any Google services allows access to all Google services, including their app engine. The same goes for Amazon Web Services and Azure. To effectively block an app using fronting requires blocking the entire cloud provider – and every other service hosted by it.

  • Where it works best: Anywhere where blocking significant online platforms would be not tenable long-term due to desires to support innovation, economic linkages, or simply social expectations of access.

  • Downsides: Using these services can quickly become very costly, and while powerful, still not a guarantee that the connections will not be throttled, interefered with, or blocked either temporarily or over longer terms.

  • Implementations

Name Description Status
meek Meek is the gold standard and supports “fronting” through Google App Engine, Amazon Web Services and Microsoft Azure. In use. Evaluation
SnowFlake SnowFlake uses WebRTC to turn website visitors into ephemeral proxies. See also alpha Evaluation
FlashProxy Flashproxy leverages javascript running in uncensored browsers to provide short-lived proxies to censored content. Firewall traversal causes challenges for this, which are being addressed in SnowFlake, above. Deprecated Evaluation
Refraction Networking This approach involves intercepting traffic going to “safe” addresses and redirecting it to user-requested, blocked content. It increases the cost of censorship, by preventing censors from selectively blocking only those servers used to provide Internet freedom. For an example, see Tapdance In Development.

Other options include using short-lived VPS servers and even dividing traffic among multiple, low-cost fronting options.


This approach seeks to disguise the traffic in ways that are not identifiable as any specific type of traffic. This forces an adversary to only allowed whitelisted traffic (which can be easily defeated by fronting) or to expend significant resources to re-identify the scrambled traffic.

  • Where it works best: Scrambling tends to work best where there is not only a willingness to outright block large platform providers, but also DPI analysis of internet traffic

  • Downsides: While the infrastructure costs are not as large as fronting, using scrambling still relies on having clients being able to know or discover unblocked IP addresses, and an active censor will work to discover and block these addresses. Modern implementations (such as obfs4) implement defenses against this attack.

  • Implementations

Name Description Status
obfs4 Obfs4 is the current state of the art deployed “look-like nothing” obfuscation protocol from The Tor Project. It builds off of ScrambleSuit, below. NOTE: Obfs4 is being successfully blocked in Kazakhstan Actively used, Evaluation
ScrambleSuit ScrambleSuit combines difficult to fingerprint unique traffic while also defending against “active probing” by adversaries Superseded by Obfs4 Evaluation
Obfs3 Obfs3 provides basic obfuscation but without the active probing defenses of Obfs4. Obfs3 Evaluation
Obfs2 Obfs2 was developed as an early protection against simple traffic identification, and does not defend against DPI analysis. To quote the evaluation, Obfs2 “is considered trivially breakable by most adversaries and is deprecated and has been evaluated as a historical reference only.” Deprecated Obfs2 Evaluation


“Shapeshifting” hide the traffic in non-objectional formats, making it look like a VOIP call, web traffic, online games, or statistically sampled “normal” traffic.

  • Where it works best: This approach defeats whitelisted traffic limitations

  • Downsides: Shape-Shifting is almost impossible to do “perfectly” – even if the traffic is indistinguishable from “real” traffic, the client and server will generally behave differently from a “real” server - meaning that advanced adversaries can choose to expend resources to do follow-up scans on every suspected connection to verify the server acts “correctly,” and block it if not.

  • Implementations

Dust2 Dust transforms traffic to statistically match a pattern of “allowed” traffic Evaluation
FTEProxy Format-Transforming Encryption Proxy uses regular expressions to transform blocked traffic (e.g. tor, https, VOIP) into traffic that appears to be allowed traffic (e.g. plain http) Evaluation
Lampshade An obfuscated encrypted network protocol for Lantern  

Visit The Tor Project for a list that includes additional theoretical transports and whitepapers.

Now that you know what transports are available, let’s look at how to make sure they’re working)

< Previous Next >