1.1 Scope

Censorship is a big topic, and even adding the “Internet” qualifier makes it hardly less so. In order to deal with the subject in detail, I must limit the scope. The subject of this work is an important special case of censorship, which I call the “border firewall.” See Figure 1.1.

A client resides within a network that is entirely controlled by a censor. Within the controlled network, the censor may observe, modify, inject, or block any communication along any link. The client’s computer, however, is trustworthy and not controlled by the censor. The censor tries to prevent some subset of the client’s communication with the wider Internet, for instance by blocking those that discuss certain topics, that are destined to certain network addresses, or that use certain protocols. The client’s goal is to evade the censor’s controls and communicate with some destination that lies outside the censor’s network; successfully doing so is called circumvention. Circumvention means somehow safely traversing a hostile network, eluding detection and blocking. The censor does not control the network outside its border; it may send messages to the outside world, but it cannot control them after they have traversed the border.

This abstract model is a good starting point, but it is not the whole story. We will have to adapt it to fit different situations, sometimes relaxing and sometimes strengthening assumptions. For example, the censor may be weaker than assumed: it may observe only the links that cross the border, not those that lie wholly inside; it may not be able to fully inspect every packet; or there may be deficiencies or dysfunctions in its detection capabilities. Or the censor may be stronger: while not fully controlling outside networks, it may perhaps exert outside influence to discourage network operators from assisting in circumvention. The client may be limited, for technical or social reasons, in the software and hardware they can use. The destination may knowingly cooperate with the client’s circumvention effort, or may not. There are many possible complications, reflecting the messiness and diversity of dealing with real censors. Adjusting the basic model to reflect real-world actors’ motivations and capabilities is the heart of threat modeling. In particular, what makes circumvention possible at all is the censor’s motivation to block only some, but not all, of the incoming and outgoing communications—this assumption will be a major focus of the next chapter.

It is not hard to see how the border firewall model relates to censorship in practice. In a common case, the censor is the government of a country, and the limits of its controlled network correspond to the country’s borders. A government typically has the power to enforce laws and control network infrastructure inside its borders, but not outside. However this is not the only case: the boundaries of censorship do not always correspond to the border of a country. Content restrictions may vary across geographic locations, even within the same country—Wright et al. [202] identified some reasons why this might be. A good model for some places is not a single unified regime, but rather several autonomous service providers, each controlling and censoring its own portion of the network, perhaps coordinating with others about what to block and perhaps not. Another important case is that of a university or corporate network, in which the only outside network access is through a single gateway router, which tries to enforce a policy on what is acceptable and what is not. These smaller networks often differ from national- or ISP-level networks in interesting ways, for instance with regard to the amount of overblocking they are willing to tolerate, or the amount of computation they can afford to spend on each communication.

Here are examples of forms of censorship that are in scope:

• blocking IP addresses
• blocking specific network protocols
• blocking DNS resolution for certain domains
• blocking keywords in URLs
• parsing application-layer data (“deep packet inspection”)
• statistical and probabilistic traffic classification
• bandwidth throttling
• active scanning to discover the use of circumvention

Some other censorship-related topics that are not in scope include:

• domain takedowns (affecting all clients globally)
• server-side blocking (servers that refuse to serve certain clients)
• forum moderation and deletion of social media posts
• anything that takes place entirely within the censor’s network and does not cross the border
• deletion-resistant publishing in the vein of the Eternity Service [10] (what Köpsell and Hillig call “censorship resistant publishing systems” [120 §1]), except insofar as access to such services may be blocked

Parts of the abstract model are deliberately left unspecified, to allow for the many variations that arise in practice. The precise nature of “blocking” can take many forms, from packet dropping, to injection of false responses, to softer forms of disruption such as bandwidth throttling. Detection does not have to be purely passive. The censor may to do work outside the context of a single connection; for example, it may compute aggregate statistics over many connections, make lists of suspected IP addresses, and defer some analysis for offline processing. The client may cooperate with other parties inside and outside the censor’s network, and indeed almost all circumvention will require the assistance of a collaborator on the outside.

It is a fair criticism that the term “Internet censorship” in the title overreaches, given that I am talking only about one specific manifestation of censorship, albeit an important one. I am sympathetic to this view, and I acknowledge that far more topics could fit under the umbrella of Internet censorship. Nevertheless, for consistency and ease of exposition, in this document I will continue to use “Internet censorship” without further qualification to mean the border firewall case.

1.2 My background

This document describes my research experience from the past five years. The next chapter, “Principles of circumvention,” is the thesis of the thesis, in which I lay out opinionated general principles of the field of circumvention. The remaining chapters are split between the topics of modeling and circumvention.

One’s point of view is colored by experience. I will therefore briefly describe the background to my research. I owe much of my experience to collaboration with the Tor Project, producers of the Tor anonymity network. whose anonymity network has been the vehicle for deployment of my circumvention systems. Although Tor was not originally intended as a circumvention system, it has grown into one thanks to pluggable transports, a modularization system for circumvention implementations. I know a lot about Tor and pluggable transports, but I have less experience (especially implementation experience) with other systems, particularly those that are developed in languages other than English. And while I have plenty of operational experience—deploying and maintaining systems with real users—I have not been in a situation where I needed to circumvent regularly, as a user.

2.1 Collateral damage

What prevents the censor from shutting down all connectivity within its network, trivially preventing the client from reaching any destination? The answer is that the censor derives benefits from allowing network connectivity, other than the communications which it wants to censor. Or to put it another way: the censor incurs a cost when it overblocks: accidentally blocks something it would have preferred to allow. Because it wants to block some things and allow others, the censor is forced to run as a classifier. In order to avoid harm to itself, the censor permits some measure of circumvention traffic.

The cost of false positives is of so central importance to circumvention that researchers have a special term for it: collateral damage. The term is a bit unfortunate, evoking as it does negative connotations from other contexts. It helps to focus more on the “collateral” than the “damage”: collateral damage is any cost experienced by the censor as a result of incidental blocking done in the course of censorship. It must trade its desire to block forbidden communications against its desire to avoid harm to itself, balance underblocking with overblocking. Ideally, we force the censor into a dilemma: unable to distinguish between circumvention and other traffic, it must choose either to allow circumvention along with everything else, or else block everything and suffer maximum collateral damage. It is not necessary to reach this ideal fully before circumvention becomes possible. Better obfuscation drives up the censor’s error rate and therefore the cost of any blocking. Ideally, the potential “damage” is never realized, because the censor sees the cost as being too great.

Collateral damage, being an abstract “cost,” can take many forms. It may come in the form of civil discontent, as people try to access web sites and get annoyed with the government when unable to do so. It may be reduced productivity, as workers are unable to access resources they need to to their job. This is the usual explanation offered for why the Great Firewall of China has never blocked GitHub for for more than a few days, despite GitHub’s being used to host and distribute circumvention software: GitHub is so deeply integrated into software development, that programmers cannot get work done when it is blocked.

Collateral damage, as with other aspects of censorship, cannot be understood in isolation, but only in relation to a particular censor. Suppose that blocking one web site results in the collateral blocking of a hundred more. Is that a large amount of collateral damage? It depends. Are those other sites likely to be visited by clients in the censor’s network? Are they in the local language? Do professionals and officials rely on them to get their job done? Is someone in the censorship bureau likely to get fired as a result of their blocking? If the answers to these question is yes, then yes, the collateral damage is likely to be high. But if not, then the censor could take or leave those hundred sites—it doesn’t matter. Collateral damage is not just any harm that results from censorship, it is harm that is felt by the censor.

Censors may take actions to reduce collateral damage while still blocking most of what they intend to. (Another way to think of it is: reducing false positives without increasing false negatives.) For example, Winter and Lindskog [199], observed that the Great Firewall preferred to block individual ports, entire IP addresses, probably in a bid to reduce collateral damage. Local circumstances may serve to reduce collateral damage: for example if a domestic replacement exists for a foreign service, the censor may block the foreign service more easily.

The censor’s reluctance to cause collateral damage is what makes circumvention possible in general. (There are some exceptions, discussed in the next section, where the censor can detect but for some reason cannot block.) To deploy a circumvention system is to make a bet: that the censor cannot field a classifier that adequately distinguishes the traffic of the circumvention system from other traffic which, if blocked, would result in collateral damage. Even steganographic circumvention channels that mimic some other protocol ultimately derive their blocking resistance from the potential of collateral damage. For example, a protocol that imitates HTTP can be blocked by blocking HTTP—the question then is whether the censor can afford to block HTTP. And that’s in the best case, assuming that the circumvention protocol has no “tell” that enables the censor to distinguish it from the cover protocol it is trying to imitate. Indistinguishability is a necessary but not sufficient condition for blocking resistance: that which you are trying to be indistinguishable from must also have sufficient collateral damage. It’s no use to have a perfect steganographic imitation of a protocol that the censor doesn’t mind blocking.

In my opinion, collateral damage provides a more productive way to think about the behavior of censors than do alternatives. It takes into account different censors’ differing resources and motivations, and so is more useful for generic modeling. Moreover, it gets to the heart of what makes traffic resistant to blocking. There are other ways of characterizing censorship resistance. Many authors—Burnett et al. [25], and Jones et al. Jones2014a, for instance—call the essential element “deniability,” meaning that a client can plausibly claim to have been doing something other than circumventing when confronted with a log of their network activity. Khattak, Elahi, et al. [113 §4] consider “deniability” separately from “unblockability.” Houmansadr et al. [103, 104, 105] used the term “unobservability,” which I feel fails to capture the censor’s essential function of distinguishing, not only observation. Brubaker et al. [23] used the term “entanglement,” which I found enlightening. What they call entanglement I think of as indistinguishability—keeping in mind that that which you are trying to be indistinguishable from must be valued by the censor. Collateral damage provides a way to make statements about censorship resistance quantifiable, at least in a loose sense. Rather than saying, “the censor cannot block X,” or even, “the censor is unwilling to block X,” it is better to say “in order to block X, the censor would have to do Y,” where Y is some action bearing a cost for the censor. A statement like this makes it clear that some censors may be able to afford the cost of blocking and others may not; there is no “unblockability” in absolute terms. Now, actually quantifying the value of Y is a task in itself, by no means a trivial one. A challenge for future work in this field is to assign actual numbers (e.g., in dollars) to the costs borne by censors. If a circumvention system becomes blocked, it may simply mean that the circumventor overestimated the collateral damage or underestimated the censor’s capacity to absorb it.

We have observed that the risk of collateral damage is what prevents the censor from shutting down the network completely—and yet, censors do occasionally enact shutdowns or daily “curfews.” Shutdowns are costly—West [191] looked at 81 shutdowns in 19 countries in 2015 and 2016, and estimated that they collectively cost $2.4 billion in losses to gross domestic product. Deloitte [40] estimated that shutdowns cost millions of dollars per day per 10 million population, the amount depending on a country’s level of connectivity. This does not necessarily contradict the theory of collateral damage. It is just that, in some cases, a censor reckons that the benefits of a shutdown outweigh the costs. As always, the outcome depends on the specific censor: censors that don’t benefit as much from the Internet don’t have as much to lose by blocking it. The fact that shutdowns are limited in duration shows that even censors that can afford to a shutdown cannot afford to keep it up forever.

Complicating everything is the fact that censors are not bound to act rationally. Like any other large, complex entity, a censor is prone to err, to act impetuously, to make decisions that cause more harm than good. The imposition of censorship in the first place, I suggest, is exactly such an irrational action, retarding progress at the greater societal level.

2.2 Content obfuscation strategies

There are two general strategies to counter content-based detection. The first is to mimic some content that the censor allows, like HTTP or email. The second is to randomize the content, making it dissimilar to anything that the censor specifically blocks.

Tschantz et al. [182] call these two strategies “steganography” and “polymorphism” respectively. It is not a strict categorization—any real system will incorporate a bit of both. The two strategies reflect they reflect differing conceptions of censors. Steganography works against a “whitelisting” or “default-deny” censor, one that permits only a set of specifically enumerated protocols and blocks all others. Polymorphism, on the other hand, fails against a whitelisting censor, but works against a “blacklisting” or “default-allow” censor, one that blocks a set of specifically enumerated protocols and allows all others.

This is not to say that steganography is strictly superior to polymorphism—there are tradeoffs in both directions. Effective mimicry can be difficult to achieve, and in any case its effectiveness can only be judged against a censor’s sensitivity to collateral damage. Whitelisting, by its nature, tends to cause more collateral damage than blacklisting. And just as obfuscation protocols are not purely steganographic or polymorphic, real censors are not purely whitelisting or blacklisting. Houmansadr et al. [103] exhibited weaknesses in “parrot” circumvention systems that imperfectly mimic a cover protocol. Mimicking a protocol in every detail, down to its error behavior, is difficult, and any inconsistency is a potential feature that a censor may exploit. Wang et al. [186] found that some of the proposed attacks against parrot systems would be impractical due to high false-positive rates, but offered other attacks designed for efficiency and low false positives. Geddes et al. [95] showed that even perfect imitation may leave vulnerabilities due to mismatches between the cover protocol and the carried protocol. For instance, randomly dropping packets may disrupt circumvention more than normal use of the cover protocol. It’s worth noting, though, that apart from active probing and perhaps entropy measurement, most of the attacks proposed in academic research have not been used by censors in practice.

Some systematizations (for example those of Brubaker et al. [23 §6]; Wang et al. [186 §2]; and Khattak, Elahi, et al. [113 §6.1]) further subdivide steganographic systems into those based on mimicry (attempting to replicate the behavior of a cover protocol) and tunneling (sending through a genuine implementation of the cover protocol). I do not find the distinction very useful, except when discussing concrete implementation choices. To me, there is no clear division: there are various degrees of fidelity in imitation, and tunneling only tends to offer higher fidelity than does mimicry.

I will list some circumvention systems that represent the steganographic strategy. Infranet [62], way back in 2002, built a covert channel within HTTP, encoding upstream data as crafted requests and downstream data as steganographic images. StegoTorus [190] uses custom encoders to make traffic resemble common HTTP file types, such as PDF, JavaScript, and Flash. SkypeMorph [139] mimics a Skype video call. FreeWave [105] modulates a data stream into an acoustic signal and transmits it over VoIP. Format-transforming encryption, or FTE [58], force traffic to conform to a user-specified syntax: if you can describe it, you can imitate it. Despite receiving much research attention, steganographic systems have not been as used in practice as polymorphic ones. Of the listed systems, only FTE has seen substantial deployment.

There are many examples of the randomized, polymorphic strategy. An important subclass of these comprises the so-called look-like-nothing systems that encrypt a stream without any plaintext header or framing information, so that it appears to be a uniformly random byte sequence. A pioneering design was the obfuscated-openssh of Bruce Leidl [122], which aimed to hide the plaintext packet metadata in the SSH protocol. obfuscated-openssh worked, in essence, by first sending an encryption key, and then sending ciphertext encrypted with that key. The encryption of the obfuscation layer was an additional layer, independent of SSH’s ordinary encryption. A censor could, in principle, passively detect and deobfuscate the protocol by recovering the key and using it to decrypt the rest of the stream. obfuscated-openssh could optionally incorporate a pre-shared password into the key derivation function, which would protect against this attack. Dust [195], similarly randomized bytes (at least in its v1 version—later versions permitted fitting to distributions other than uniform). It was not susceptible to passive deobfuscation because it required an out-of-band key exchange to happen before each session. Shadowsocks [170] is a lightweight encryption layer atop a simple proxy protocol.

There is a line of successive look-like-nothing protocols—obfs2, obfs3, ScrambleSuit, and obfs4—which I like because they illustrate the mutual advances of censors and circumventors over several years. obfs2 [110], which debuted in 2012 in response to blocking in Iran [43], uses very simple obfuscation inspired by obfuscated-openssh: it is essentially equivalent to sending an encryption key, then the rest of the stream encrypted with that key. obfs2 is detectable, with no false negatives and negligible false positives, by even a passive censor who knows how it works; and it is vulnerable to active probing attacks, where the censor speculatively connects to servers to see what protocols they use. However, it sufficed against the keyword- and pattern-based censors of its era. obfs3 [111]—first available in 2013 but not really released to users until 2014 [152]—was designed to fix the passive detectability of its predecessor. obfs3 employs a Diffie–Hellman key exchange that prevents easy passive detection, but it can still be subverted by an active man in the middle, and remains vulnerable to active probing. (The Great Firewall of China had begun active-probing for obfs2 by January 2013, and for obfs3 by August 2013—see Table 4.2.) ScrambleSuit [200], first available to users in 2014 [29], arose in response to the active-probing of obfs3. Its innovations were the use of an out-of-band secret to authenticate clients, and traffic shaping techniques to perturb the underlying stream’s statistical properties. When a client connects to a ScrambleSuit proxy, it must demonstrate knowledge of the out-of-band secret before the proxy will respond, which prevents active probing. obfs4 [206], first available in 2014 [154], is an incremental advancement on ScrambleSuit that uses more efficient cryptography, and additionally authenticates the key exchange to prevent active man-in-the-middle attacks.

There is an advantage in designing polymorphic protocols, as opposed to steganographic ones, which is that every proxy can potentially have its own characteristics. ScrambleSuit and obfs4, in addition to randomizing packet contents, also shape packet sizes and timing to fit random distributions. Crucially, the chosen distributions are consistent within each proxy, but vary across proxies. That means that even if a censor is able to build a profile for a particular proxy, it is not necessarily useful for detecting other instances.

2.3 Address blocking resistance strategies

The first-order solution for reaching a destination whose address is blocked is to instead route through a proxy. But a single, static proxy is not much better than direct access, for circumvention purposes—a censor can block the proxy just as easily as it can block the destination. Circumvention systems must come up with ways of addressing this problem.

There are two reasons why resistance to blocking by address is challenging. The first is due to the nature of network routing: the client must, somehow, encode the address of the destination into the messages it sends. The second is the insider attack: legitimate clients must have some way to discover the addresses of proxies. By pretending to be a legitimate client, the censor can learn those addresses in the same way.

Compared to content obfuscation, there are relatively few strategies for resistance to blocking by address. They are basically five:

• sharing private proxies among only a few clients
• having a large population of secret proxies and distributing them carefully
• having a very large population of proxies and treating them as disposable
• proxying through a service with high collateral damage
• address spoofing

The simplest proxy infrastructure is no infrastructure at all: require every client to set up and maintain a proxy for their own personal use, or for a few of their friends. As long as the use of any single address remains low, it may escape the censor’s notice [49 §4.2]. The problem with this strategy, of course, is usability and scalability. If it were easy for everyone to set up their own proxy on an unblocked address, they would do it, and blocking by address would not be a concern. The challenge is making such techniques general so they are usable by more than experts. uProxy [184] is now working on just that: automating the process of setting up a proxy on a server.

What Köpsell and Hillig call the “many access points” model [120 §5.2] has been adopted in some form by many circumvention systems. In this model, there are many proxies in operation. They may be full-fledged general-purpose proxies, or only simple forwarders to a more capable proxy. They may be operated by volunteers or coordinated centrally. In any case, the success of the system hinges on being able to sustain a population of proxies, and distribute information about them to legitimate users, without revealing too many to the censor. Both of these considerations pose challenges.

Tor’s blocking resistance design [49], based on secret proxies called “bridges,” was of this kind. Volunteers run bridges, which report themselves to a central database called BridgeDB [181]. Clients contact BridgeDB through some unblocked out-of-band channel (HTTPS, email, or word of mouth) in order to learn bridge addresses. The BridgeDB server takes steps to prevent the easy enumeration of its database [124]. Each request returns only a small set of bridges, and repeated requests by the same client return the same small set (keyed by a hash of the client’s IP address prefix or email address). Requests through the HTTPS interface require the client to solve a captcha, and email requests are honored only from the domains of email providers that are known to limit the rate of account creation. The population of bridges is partitioned into “pools”—one pool for HTTPS distribution, one for email, and so on—so that if an adversary manages to enumerate one of the pools, it does not affect the bridges of the others. But even these defenses may not be enough. Despite public appeals for volunteers to run bridges (for example Dingledine’s initial call in 2007 [44]), there have never been more than a few thousand of them, and Dingledine reported in 2011 that the Great Firewall of China managed to enumerate both the HTTPS and email pools [45 §1, 46 §1].

Tor relies on BridgeDB to provide address blocking resistance for all its transports that otherwise have only content obfuscation. And that is a great strength of such a system. It enables, to some extent, content obfuscation to be developed independently, and rely on an existing generic proxy distribution mechanism in order to produce an overall working system. There is a whole line of research, in fact, on the question of how best to distribute information about an existing population of proxies, which is known as the “proxy distribution problem” or “proxy discovery problem.” Proposals such as Proximax [134], rBridge [188], and Salmon [54] aim to make proxy distribution robust by tracking the reputation of clients and the unblocked lifetimes of proxies.

A way to make proxy distribution more robust against censors (but at the same time less usable by clients) is to “poison” the set of proxy addresses with the addresses of important servers, the blocking of which would result in high collateral damage. VPN Gate employed this idea [144 §4.2], mixing into the their public proxy list the addresses of root DNS servers and Windows Update servers.

Apart from “in-band” discovery of bridges via subversion of a proxy distribution system, one must also worry about “out-of-band” discovery, for example by mass scanning [46 §6, 49 §9.3]. Durumeric et al. found about 80% of existing (unobfuscated) Tor bridges [57 §4.4] by scanning all of IPv4 on a handful of common bridge ports. Matic et al. had similar results in 2017 [133 §V.D], using public search engines in lieu of active scanning. The best solution to the scanning problem is to do as ScrambleSuit [200], obfs4 [206], and Shadowsocks [170] do, and associate with each proxy a secret, without which a scanner cannot initiate a connection. Scanning for bridges is closely related to active probing, the topic of Chapter 4.

Another way of achieving address blocking resistance is to treat proxies as temporary and disposable, rather than permanent and valuable. This is the idea underlying flash proxy [84] and Snowflake (Chapter 7). Most proxy distribution strategies are designed around proxies lasting at least on the order days. In contrast, disposable proxies may last only minutes or hours. Setting up a Tor bridge or even something lighter-weight like a SOCKS proxy still requires installing some software on a server somewhere. The proxies of flash proxy and Snowflake have a low set-up and tear-down cost: you can run one just by visiting a web page. These designs do not need a sophisticated proxy distribution strategy as long as the rate of proxy creation is kept higher than the censor’s rate of discovery.

The logic behind diffusing many proxies widely is that a censor would have to block large swaths of the Internet in order to effectively block them. However, it also makes sense to take the opposite tack: have just one or a few proxies, but choose them to have high enough collateral damage that the censor does not dare block them. Refraction networking [160] puts proxy capability into network routers—in the middle of paths, rather than at the end. Clients cryptographically tag certain flows in a way that is invisible to the censor but detectable to a refraction-capable router, which redirects from its apparent destination to some other, covert destination. In order to prevent circumvention, the censor has to induce routes that avoid the special routers [168], which is costly [106]. Domain fronting [89] has similar properties. Rather than a router, it uses another kind of network intermediary: a content delivery network. Using properties of HTTPS, a client may request one site while appearing (to the censor) to request another. Domain fronting is the topic of Chapter 6. The big advantage of this general strategy is that the proxies do not need to be kept secret from the censor.

The final strategy for address blocking resistance is address spoofing. The notable design in this category is CensorSpoofer [187]. A CensorSpoofer client never communicates directly with a proxy. It sends upstream data through a low-bandwidth, indirect channel such as email or instant messaging, and downstream data through a simulated VoIP conversation, spoofed to appear as if it were coming from some unrelated dummy IP address. The asymmetric design is feasible because of the nature of web browsing: typical clients send much less than they receive. The client never even needs to know the actual address of the proxy, meaning that CensorSpoofer has high resistance to insider attack: even running the same software as a legitimate client, the censor does not learn enough information to effect a block. The idea of address spoofing goes back farther; as early as 2001, TriangleBoy [167] employed lighter-weight intermediate proxies that simply forwarded client requests to a long-lived proxy at a static, easily blockable address. In the downstream direction, the long-lived proxy would, rather than route back through the intermediate proxy, only spoof its responses to look as if they came from proxy. TriangleBoy did not match CensorSpoofer’s resistance to insider attack, because clients still needed to find and communicate directly with a proxy, so the whole system basically reduced to the proxy discovery problem, despite the use of address spoofing.

2.4 Spheres of influence and visibility

It is usual to assume, conservatively, that whatever the censor can detect, it also can block; that is, to ignore blocking per se and focus only on the detection problem. We know from experience, however, that there are cases in practice where a censor’s reach exceeds its grasp: where it is able to detect circumvention but for some reason cannot block it. It may be useful to consider this possibility when modeling. Khattak, Elahi, et al. [113] express it nicely by subdividing the censor’s network into a sphere of influence within which the censor has active control, and a potentially larger sphere of visibility within which the censor may only observe, but not act.

A landmark example of this kind of thinking is the 2006 research on “Ignoring the Great Firewall of China” by Clayton et al. [31]. They found that the firewall would block connections by injecting phony TCP RST packets (which cause the connection to be torn down) or SYN/ACK packets (which cause the connection to become unsynchronized), and that simply ignoring the anomalous packets rendered blocking ineffective. (Why did the censor choose to inject its own packets, rather than drop those of the client or server? The answer is probably that injection is technically easier to achieve, highlighting a limit on the censor’s power.) One can think of this ignoring as shrinking the censor’s sphere of influence: it can still technically act within this sphere, but not in a way that actually achieves blocking. Additionally, intensive measurements revealed many failures to block, and blocking rates that changed over time, suggesting that even when the firewall intends a policy of blocking, it does not always succeed.

Another fascinating example of “look, but don’t touch” communication is the “filecasting” technique used by Toosheh [142], a file distribution service based on satellite television broadcasts. Clients tune their satellite receivers to a certain channel and record the broadcast to a USB flash drive. Later, they run a program on the recording that decodes the information and extracts a bundle of files. The system is unidirectional: clients can only receive the files that the operators choose to provide. The censor can easily see that Toosheh is in use—it’s a broadcast, after all—but cannot identify users, or block the signal in any way short of continuous radio jamming or tearing down satellite dishes.

There are parallels between the study of Internet censorship and that of network intrusion detection. One is that a censor’s detector may be implemented as a network intrusion detection system or monitor, a device “on the side” of a communication link that receives a copy of the packets that flow over the link, but that, unlike a router, is not responsible for forwarding the packets onward. Another parallel is that censors are susceptible to the same kinds of evasion and obfuscation attacks that affect network monitors more generally. In 1998, Ptacek and Newsham [158] and Paxson [149 §5.3] outlined various attacks against network intrusion detection systems—such as manipulating the IP time-to-live field or sending overlapping IP fragments—that cause a monitor either to accept what the receiver will reject, or reject what the receiver will accept. A basic problem is that a monitor’s position in the middle of the network does not enable it to predict exactly how each packet will be interpreted by the endpoints. Cronin et al. [36] posit that the monitor’s conflicting goals of sensitivity (recording all that is relevant) and selectivity (recording only what is relevant) give rise to an unavoidable “eavesdropper’s dilemma.”

Monitor evasion techniques can be used to reduce a censor’s sphere of visibility—remove certain traffic features from its consideration. Crandall et al. [33] in 2007 suggested using IP fragmentation to prevent keyword matching. In 2008 and 2009, Park and Crandall [148] explicitly characterized the Great Firewall as a network intrusion detection system and found that a lack of TCP reassembly allowed evading keyword matching. Winter and Lindskog [199] found that the Great Firewall still did not do TCP segment reassembly in 2012. They released a tool, brdgrd [196], that by manipulating the TCP window size, prevented the censor’s scanners from receiving a full response in the first packet, thereby foiling active probing. Anderson [9] gave technical information on the implementation of the Great Firewall as it existed in 2012, and observed that it is implemented as an “on-the-side” monitor. Khattak et al. [114] applied a wide array of evasion experiments to the Great Firewall in 2013, identifying classes of working evasions and estimating the cost to counteract them. Wang et al. [189] did further evasion experiments against the Great Firewall a few years later, finding that the firewall had evolved to prevent some previous evasion techniques, and discovering new ones.

2.5 Early censorship and circumvention

Internet censorship and circumvention began to rise to importance in the mid-1990s, coinciding with the popularization of the World Wide Web. Even before national-level censorship by governments became an issue, researchers investigated the blocking policies of personal firewall products—those intended, for example, for parents to install on the family computer. Meeks and McCullagh [138] reported in 1996 on the secret blocking lists of several programs. Bennett Haselton and Peacefire [100] found many cases of programs blocking more than they claimed, including web sites related to politics and health.

Governments were not far behind in building legal and technical structures to control the flow of information on the web, in some cases adapting the same technology originally developed for personal firewalls. The term “Great Firewall of China” first appeared in an article in Wired [15] in 1997. In the wake of the first signs of blocking by ISPs, people were thinking about how to bypass filters. The circumvention systems of that era were largely HTML-rewriting web proxies: essentially a form on a web page into which a client would enter a URL. The server would fetch the desired page on behalf of the client, and before returning the response, rewrite all the links and external references in the page to make them relative to the proxy. CGIProxy [131], SafeWeb [132], Circumventor [99], and the first version of Psiphon [28] were all of this kind.

These systems were effective against their censors of their day—at least with respect to the blocking of destinations. They had the major advantage of requiring no special client-side software other than a web browser. The difficulty they faced was second-order blocking as censors discovered and blocked the proxies themselves. Circumvention designers deployed some countermeasures; for example Circumventor had a mailing list [49 §7.4] which would send out fresh proxy addresses every few days. A 1996 article by Rich Morin [140] presented a prototype HTML-rewriting proxy called Rover, which eventually became CGIProxy. The article predicted the failure of censorship based on URL or IP address, as long as a significant fraction of web servers ran such proxies. That vision has not come to pass. Accumulating a sufficient number of proxies and communicating their addresses securely to clients—in short, the proxy distribution problem—turned out not to follow automatically, but to be a major sub-problem of its own.

Threat models had to evolve along with censor capabilities. The first censors would be considered weak by today’s standards, mostly easy to circumvent by simple countermeasures, such as tweaking a protocol or using an alternative DNS server. (We see the same progression play out again when countries first begin to experiment with censorship, such as in Turkey in 2014, where alternative DNS servers briefly sufficed to circumvent a block of Twitter [35].) Not only censors were changing—the world around them was changing as well. In field of circumvention, which is so heavily affected by concerns about collateral damage, the milieu in which censors operate is as important as the censors themselves. A good example of this is the paper on Infranet, the first academic circumvention design I am aware of. Its authors argued, not unreasonably for 2001, that TLS would not suffice as a cover protocol [62 §3.2], because the relatively few TLS-using services at that time could all be blocked without much harm. Certainly the circumstances are different today—domain fronting and all refraction networking schemes require the censor to permit TLS. As long as circumvention remains relevant, it will have to change along with changing times, just as censors do.

3.1 Censorship measurement studies

A large part of research on censorship is composed of studies of censor behavior in the wild. In this section I summarize past studies, which, taken together, present a picture of censor behavior in general. They are based on those in an evaluation study done by me and others in 2016 [182 §IV.A]. The studies are diverse and there are many possible ways to categorize them. Here, I have divided them into one-time experiments and generic measurement platforms.

3.2 The evaluation of circumvention systems

Evaluating the quality of circumvention systems is tricky, whether they are only proposed or actually deployed. The problem of evaluation is directly tied to threat modeling. Circumvention is judged according to how well it works under a given model; the evaluation is therefore meaningful only as far as the threat model reflects reality. Without grounding in reality, researchers risk running an imaginary arms race that evolves independently of the real one.

I took part, with Michael Carl Tschantz, Sadia Afroz, and Vern Paxson, in a meta-study [182] of how circumvention systems are evaluated by their authors and designers, and comparing those to empirically determined censor models. This kind of work is rather different than the direct evaluations of circumvention tools that have happened before, for example those done by the Berkman Center [162] and Freedom House [26] in 2011. Rather than testing tools against censors, we evaluated how closely aligned designers’ own models were to models derived from actual observations of censors.

This research was partly born out of frustration with some typical assumptions made in academic research on circumvention, which we felt placed undue emphasis on steganography and obfuscation of traffic streams, while not paying enough attention to the perhaps more important problems of proxy distribution and initial rendezvous between client and proxy. We wanted to help bridge the gap by laying out a research agenda to align the incentives of researchers with those of circumventors. This work was built on extensive surveys of circumvention tools, measurement studies, and known censorship events against Tor. Our survey included over 50 circumvention tools.

One outcome of the research is that that academic designs tended to be concerned with detection in the steady state after a connection is established (related to detection by content), while actually deployed systems cared more about how the connection is established initially (related to detection by address). Designers tend to misperceive the censor’s weighting of false positives and false negatives—assuming a whitelist rather than a blacklist, say. Real censors care greatly about the cost of running detection, and prefer cheap, passive, stateless solutions whenever possible. It is important to guard against these modes of detection before becoming too concerned with those that require sophisticated computation, packet flow blocking, or lots of state.

4.1 History of active probing research

Active probing research has mainly focused on Tor and its pluggable transports. There is also some work on Shadowsocks. Table 4.2 summarizes the research covered in this section.

Nixon [143] published in late 2011 an analysis of suspicious connections from IP addresses in China that his servers had at that point been receiving for a year. The connections were to the SSH port, but did not follow the SSH protocol; rather they contained apparently random bytes, resulting in error messages in the log file. Nixon discovered a pattern: the random-looking “garbage” probes were preceded, at an interval of 5–20 seconds, by a legitimate SSH login from some other IP address in China. The same pattern was repeated at three other sites. Nixon supposed that the probes were triggered by legitimate SSH users, as their connections traversed the firewall; and that the random payloads were a simple form of service identification, sent only to see how the server would respond to them. For a few weeks in May and June 2011, the probes did not look random, but instead looked like TLS.

In October 2011, Tor user hrimfaxi reported that a newly set up, unpublished Tor bridge would be blocked within 10 minutes of their first being accessed from China [41]. Moving the bridge to another port on the same IP address would work temporarily, but the new address would also be blocked within another 10 minutes. Wilde systematically investigated the phenomenon in December 2011 and published an extensive analysis of active probing that was triggered by connections from inside China to outside [193, 194]. There were two kinds of probes: “garbage” random probes like those Nixon had described, and specialized Tor probes that established a TLS session and inside the session sent the Tor protocol. The garbage probes were triggered by TLS connections to port 443, and were sent immediately following the original connection. The Tor probes, in contrast, were triggered by TLS connections to any port, as long as the TLS client handshake matched that of Tor’s implementation [48]. The Tor probes were not sent immediately, but in batches of 15 minutes. The probes came from diverse IP addresses in China: 20 different /8 networks [192]. Bridges using the obfs2 transport were, at that time, neither probed nor blocked.

Winter and Lindskog revisited the question of Tor probing a few months later in 2012 [199]. They used open proxies and a server in China to reach bridges and relays in Russia, Singapore, and Sweden. The bridges and relays were configured so that ordinary users would not connect to them by accident. They confirmed Wilde’s finding that the blocking of one port did not affect other ports on the same IP address. Blocked ports became reachable again 12 hours. By simulating multiple Tor connections, they collected over 3,000 active probe samples in 17 days. During that time, there were about 72 hours which where mysteriously free of active probing. Half of the probes came from a single IP address, 202.108.181.70; the other half were almost all unique. Reverse-scanning the probes’ source IP addresses, a few minutes after the probes were received, sometimes found a live host, though usually with a different IP TTL than was used during the probing, which the authors suggested may be a sign of address spoofing by the probing infrastructure. Because probing was triggered by patterns in the TLS client handshake, they developed a server-side tool, brdgrd [196], that rewrote the TCP window so that the client’s handshake would be split across packets. The tool sufficed, at the time, to prevent active probing, but stopped working in 2013 [197 §Software].

The obfs2 pluggable transport, first available in February 2012 [43], worked against active probing for about a year. The first report of its being probing arrived in March 2013 [47]. I found evidence for an even earlier onset, in January 2013, by analyzing the logs of my web server [60 §4.3]. At about the same time, the obfs3 pluggable transport became available [68]. It was, in principle, as vulnerable to active probing as obfs2 was, but the firewall did not gain the ability to probe for it until August 2013 [60 Figure 8].

Majkowski [128] documented a change in the GFW between June and July 2013. In June, he reproduced the observations of Winter and Lindskog: pairs of TLS probes, one from 202.108.181.70 and one from some other IP address. He also provided TLS fingerprints for the probers, which differed from those of ordinary Tor clients. In July, he began to see pairs of probes with apparently random contents, like the garbage probes Wilde described. The TLS fingerprints of the July probes differed from those seen earlier, but were still distinctive.

The ScrambleSuit transport, designed to be immune to active-probing attacks, first shipped with Tor Browser 4.0 in October 2014 [153]. The successor transport obfs4, similarly immune, shipped in Tor Browser 4.5 in April 2015 [154].

In August 2015, developer BreakWa11 described an active-probing vulnerability in the Shadowsocks protocol [19, 156 §2]. The flaw had to do with a lack of integrity protection, allowing a prober to introduce errors into ciphertext and watch the server’s reaction. As a stopgap, the developers deployed a protocol change that proved to have its own vulnerabilities to probing. They deployed another protocol in February 2017, adding cryptographic integrity protection and fixing the problem [102]. Despite the long window of vulnerability, I know of no evidence that the Great Firewall tried to probe for Shadowsocks servers.

Ensafi et al. (including me) [60] did the largest controlled study of active probing to date throughout early 2015. We collected data from a variety of sources: a private network of our own bridges, isolated so that only we and active probers would connect to them; induced intensive probing of a single bridge over a short time period, in the manner of Winter and Lindskog; analysis of server log files going back to 2010; and reverse-scanning active prober source IP addresses using tools such as ping, traceroute, and Nmap. Using these sources of data, we investigated many aspects of active probing, such as the types of probes the firewall was capable of sending, the probers’ source addresses, and potentially fingerprintable peculiarities of the probers’ protocol implementations. Observations from this research project appear in the remaining sections of this chapter.

Wang et al. [189 §7.3] tried connecting to bridges from 11 networks in China. They found that connections from four of the networks did not result in active probing, while connections from the other seven did. A bridge that was probed became blocked on all ports, a change from the single-port blocking that had been documented earlier.

4.2 Types of probes

Our experiments confirmed the existence of known probe types from prior research, and new types that had not been documented before. Our observations of the known probe types were consistent with previous reports, with only minor differences in some details. We found, at varying times, these kinds of probes:

Tor

We found probing of the Tor protocol, as expected. The probes we observed in 2015, however, differed from those Wilde described in 2011, which proceeded as far as building a circuit. The ones we saw used less of the Tor protocol: after the TLS handshake they only queried the server’s version and disconnected. Also, in contrast to what Winter and Lindskog found in 2012, the probes were sent immediately after a connection, not batched to a multiple of 15 minutes.

obfs2

The obfs2 protocol is meant to look like a random stream, but it has a weakness that makes it trivial to identify, passively and retroactively, needing only the first 20 bytes sent by the client. We turned the weakness of obfs2 to our advantage. It allowed us to distinguish obfs2 from other random-looking payloads, isolating a set of connections that could belong only to legitimate circumventors or to active probers.

obfs3

The obfs3 protocol is also meant to look like a random stream; but unlike obfs2, it is not trivially identifiable passively. It is not possible to retroactively recognize obfs3 connections (from, say, a packet capture) with certainty: sure classification requires active participation in the protocol. In some of our experiments, we ran an obfs3 server that was able to participate in the handshake and so confirm that the protocol really was obfs3. In the passive log analysis, we labeled “obfs3” any probes that looked random but were not obfs2.

SoftEther

We unexpectedly found evidence of probe types other than Tor-related ones. One of these was an HTTPS request:

POST /vpnsvc/connect.cgi HTTP/1.1
Connection: Keep-Alive
Content-Length: 1972
Content-Type: image/jpeg

GIF89a...

Both the path “/vpnsvc/connect.cgi”, and the body being a GIF image despite having a Content-Type of “image/jpeg”, are characteristic of the client handshake of the SoftEther VPN software that underlies the VPN Gate circumvention system [144].

AppSpot

This type of probe is also an HTTPS request:

GET / HTTP/1.1
Accept-Encoding: identity
Connection: close
Host: webncsproxyXX.appspot.com
Accept: */*
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Ubuntu Chromium/34.0.1847.116 Chrome/34.0.1847.116 Safari/537.36

where the ‘XX’ is a number that varies. The intent of this probe seems to be the discovery of servers that are capable of domain fronting for Google services, including Google App Engine, which runs at appspot.com. (See Chapter 6 for more on domain fronting.) At one time, there were simple proxies running at webncsproxyXX.appspot.com.

urllib

This probe type is new since our 2015 paper. I discovered it while re-analyzing my server logs in order to update Figure 4.3. It is a particular request that was sent over both HTTP and HTTPS:

GET / HTTP/1.1
Accept-Encoding: identity
Host: 69.164.193.231
Connection: close
User-Agent: Python-urllib/2.7

The urllib requests are unremarkable except for having been sent from an IP address that at some other time send another kind of active probe. The User-Agent “Python-urllib/2.7” and appears many other places in my logs, not in an active probing context. I cannot guess what this probe’s purpose may be, except to observe that Nobori and Shinjo also caught a “Python-urllib” client scraping the VPN Gate server list [144 §6.3].

These probe types are not necessarily exhaustive. The purpose of the random “garbage” probes is still not known; they were not obfs2 and were too early to be obfs3, so they must have had some other purpose.

Most of our experiments were designed around exploring known Tor-related probe types: plain Tor, obfs2, and obfs3. The server log analysis, however, unexpectedly turned up the other probe types. The server log data set consisted of application-layer logs from my personal web and mail server, which was also a Tor bridge. Application-layer logs lack much of the fidelity you would normally want in a measurement experiment; they do not have precise timestamps or transport-layer headers, for example, and web server logs truncate the client’s payload at the first ‘\0’ or ‘\n’ byte. But they make up for that with time coverage. Figure 4.3 shows the history of probes received at my server since 2013 (there were no probes before that, though the logs go back to 2010). We began by searching the logs for definite probes: those that were classifiable as obfs2 or otherwise looked like random garbage. Then we looked for what else appeared in the logs for the IP addresses that had, at any time, sent a probe. In a small fraction of cases, the other logs lines appeared to be genuine HTTP requests from legitimate clients; but usually they were other probe-like payloads. We continued this process, adding new classifiers for likely probes, until reaching a fixed point with the probe types described above.

4.3 Probing infrastructure

The most striking feature of active probes is the large number of source addresses from which they are sent, or appear to be sent. The 13,089 probes received by the HTTP and HTTPS ports of my server came from 11,907 distinct IP addresses, representing 47 /8 networks and 26 autonomous systems. 96% of the addresses appeared only once. There is one extreme outlier, the address 202.108.181.70, which by itself accounted for 2% of the probes. (Even this substantial fraction stands in contrast to previous studies, where that single IP address accounted for roughly half the probes [199 §4.5.1].) Among the address ranges are ones belonging to residential ISPs.

Despite the many source addresses, the probes seems to be managed by only a few underlying processes. The evidence for this lies in shared patterns in metadata: TCP initial sequence numbers and TCP timestamps. Figure 4.4 shows clear patterns in TCP timestamps, from about six months during which we ran a full packet capture on my web server, in addition to application-layer logging.

We tried connecting back to the source address of probes. Immediately after receiving a probe, the probing IP address would be completely unresponsive to any stimulus we could think to apply. In some cases though, within an hour the address became responsive. The responsive hosts looked like what you would expect to find if you scanned such address ranges, with a variety of operating systems and open ports.

4.4 Fingerprinting the probers

A potential countermeasure against active probing is for each proxy, when it receives a connection, to somehow decide whether the connection comes from a legitimate client, or from a prober. Of course, the right way to identify legitimate clients is with cryptographic authentication, whether at the transport layer (like BridgeSPA [172]) or at the application layer (like ScrambleSuit, obfs4, and Shadowsocks). But when that is not possible, one might hope to distinguish probers by their fingerprints, idiosyncrasies in their implementation that make them stand out from ordinary clients. In the case of the Great Firewall, the source IP address does not suffice as a fingerprint because of the great diversity of source addresses the system makes use of. And in a reversal of the usual collateral damage, the source addresses include those where we might expect legitimate clients to reside. The probes do, however, exhibit certain fingerprints at the application layer. While none of the ones we found were robust enough to effectively exclude active probers, they do hint at how the probing is implemented.

The active probers have an unusual TLS fingerprint, TLSv1.0 with a peculiar list of ciphersuites. Tor probes sent only a VERSIONS cell [50 §4.1], waited for a response, then closed the connection. The format of the VERSIONS cell was that of a “v2” Tor handshake that has been superseded since 2011, though still in use by a small number of real clients. The Tor probes described by Wilde in 2011 went further into the protocol. It hints at the possibility that at one time, the active probers used a (possibly modified) Tor client, and later switched to a custom implementation.

The obfs2 probes were conformant with the protocol specification, and unremarkable except for the fact that sometimes payloads were duplicated. obfs2 clients are supposed to use fresh randomness for each connection, but a small fraction, about 0.65%, of obfs2 probes shared an identical payload with one other probe. The two probes in a pair came from different source IP addresses and arrived within a second of each other. The apparently separate probers must therefore share some state—at least a shared pseudorandom number generator.

The obfs3 protocol calls for the client to send a random amount of random bytes as padding. The active probers’ implementation of the protocol gets the probability distribution wrong, half the time sending too much padding. This feature would be difficult to exploit for detection, though, because it would rely on application-layer proxy code being able to infer TCP segment boundaries.

The SoftEther probes seem to have been based on an earlier version of the official SoftEther client software than was current at the time, differing from current version in that they lack an HTTP Host header. They also differed from the official client in that their POST request was not preceded by a GET request. The TLS fingerprint of the official client is much different from that of the probers, again hinting at a custom implementation.

The AppSpot probes have a User-Agent header that claims to be a specific version of the Chrome browser; however the rest of the header, and the TLS fingerprint are inconsistent with Chrome.

5.1 The experiment

Our experiment primarily involved frequent, active test of the reachability of default bridges from probe sites in China, Iran, and Kazakhstan (countries well known to censor the network), as well as a control site in the U.S. We used a script that, every 20 minutes, attempted to make a TCP connection to each default bridge. The script recorded, for each attempt, whether the connection was successful, the time elapsed, and any error code. The error code allows us to distinguish between different kinds of failures such as “timeout” and “connection refused.” The control site in the U.S. enables us to distinguish temporary bridge failures from actual blocking.

The script only tested whether it is possible to make a TCP connection, which is a necessary but not sufficient precondition to actually establishing a Tor circuit through the bridge. In Kazakhstan, we deployed an additional script that attempted to establish a full Tor-in-obfs4 connection, in order to better understand the different type of blocking we discovered there.

The experiment was opportunistic in nature: we ran from China, Iran, and Kazakhstan not only because they are likely suspects for Tor blocking, but because we happened to have access to a site in each from which we could run probes over some period of time. Therefore the measurements cover different dates in different countries. We began at a time when Tor was building up its stock of default bridges. We began monitoring each new bridges as it was added, coordinating with the Tor Browser developers to get advance notice of their addition when possible. Additionally we had the developers run certain more controlled experiments for us—such as adding a bridge to the source code but commenting it out—that are further detailed below.

We were only concerned with default bridges, not secret ones. Our goal was not to estimate the difficulty of the proxy discovery problem, but to better understand how censors deal with what should be an easy task. We focused on bridges using the obfs4 pluggable transport [206], which not only is the most-used transport and the one marked “recommended” in the interface, but also has properties that help in our experiment. The content obfuscation of obfs4 reduces the risk of its passive detection. More importantly, it resists active probing attacks as described in Chapter 4. We could not have done the experiment with obfs3 bridges, because whether default or not, active probing would cause them to be blocked shortly after their first use.

Bridges are identified by a nickname and a port number. The nickname is an arbitrary identifier, chosen by the bridge operator. So, for example, “ndnop3:24215” is one bridge, and “ndnop3:10527” is another on the same IP address. We pulled the list of bridges from Tor Browser and Orbot, which is the port of Tor for Android. Tor Browser and Orbot mostly shared bridges in common, though there were a few Orbot-only bridges. A list of the bridges and other destinations we measured appears in Table 5.1. Along with the fresh bridges, we tested some existing bridges for comparison purposes.

There are four stages in the process of deploying a new default bridge. At the beginning, the bridge is secret, perhaps having been discussed on a private mailing list. Each successive stage of deployment makes the bridge more public, increasing the number of places where a censor may look to discover it. The whole process takes a few days to a few weeks, mostly depending on Tor Browser’s release schedule.

Ticket filed

The process begins with the filing of a ticket in Tor’s public issue tracker. The ticket includes the bridge’s IP address. A censor that pays attention to the issue tracker could discover bridges as early as this stage.

Ticket merged

After review, the ticket is merged and the new bridge is added to the source code of Tor Browser. From there it will begin to be included in nightly builds. A censor that reads the bridge configuration file from the source code repository, or downloads nightly builds, could discover bridges at this stage.

Testing release

Just prior to a public release, Tor Browser developers send candidate builds to a public mailing list to solicit quality assurance testing. A censor that follows testing releases would find ready-made executables with embedded bridges at this stage. Occasionally the developers skip the testing period, such as in the case of an urgent security release.

Public relase

After testing, the releases are made public and announced on the Tor Blog. A censor could learn of bridges at this stage by reading the blog and downloading executables. This is also the stage at which the new bridges begin to have an appreciable number of users. There are two release tracks of Tor Browser: stable and alpha. Alpha releases are distinguished by an ‘a’ in their version number, for example 6.5a4. According to Tor Metrics [180], stable downloads outnumber alpha downloads by a factor of about 30 to 1.

We advised operators to configure their bridges so that they would not become public except via the four stages described above. Specifically, we made sure the bridges did not appear in BridgeDB [181], the online database of secret bridges, and that the bridges did not expose any transports other than obfs4. We wanted to ensure that any blocking of bridges could only be the result of their status as default bridges, and not a side effect of some other detection system.

5.2 Results from China

We had access to probe sites in China for just over a year, from December 2015 to January 2017. Due to the difficulty of getting access to hosts in China, we used four different IP addresses (all in the same autonomous system) at different points in time. The times during which we had control of each IP address partially overlap, but there is a 21-day gap in the measurements during August 2016.

Our observations in China turned up several interesting behaviors of the censor. Throughout this section, refer to Figure 5.2, which shows the timeline of reachability of every bridge, in context with dates related to tickets and releases. Circled references in the text (ⓐ, ⓑ, etc.) refer to marked points in the figure. A “batch” is a set of Tor Browser releases that all contained the same default bridges.

The most significant single event—covered in detail in Section 5.2.7—was a change in the censor’s detection and blocking strategy in October 2016. Before that date, blocking was port-specific and happened only after the “public release” stage. After, bridges began to be blocked on all ports simultaneously, and were blocked soon after the “ticket merged” stage. We believe that this change reflects a shift in how the censor discovered bridges, a shift from running the finished software to see what addresses it accesses, to extracting the addresses from source code. More details and evidence appear in the following subsections.

5.3 Results from Iran

We had a probe site in Iran from December 2015 to June 2016, a virtual private server, which a personal contact could only provide for us for a limited time.

In contrast to the situation in China, in Iran we found no evidence of blocking. See Figure 5.3. Although there were timeouts and refused connections, they were the result of failures at the bridge side, as confirmed by a comparison with control measurements. This, despite the fact that Iran is a notorious censor [14], and has in the past blocked Tor directory authorities [7].

It seems that Iran has overlooked the blocking of default bridges. Tor Metrics shows thousands of simultaneous bridge users in Iran since 2014 [178], so it is unlikely that the bridges were simply blocked in a way that our probing script could not detect. However, in Kazakhstan we did find such situation, with bridges being effectively blocked despite the firewall allowing TCP connections to them.

5.4 Results from Kazakhstan

We had a single probe site in Kazakhstan between December 2016 and May 2017. It was a VPN node with IP address 185.120.77.110 . It was in AS 203087, which belongs to GoHost.kz, a Kazakh hosting provider. The flaky VPN connection left us with two extended gaps in measurements.

The bridge blocking in Kazakhstan had a different nature than that which we observed in China. Refer to Figure 5.4: every measurement agreed with the control site, with the sole exception of LeifEricson:41213 (not shown), which was blocked as it had been in China. However there had been reports of the blocking of Tor and pluggable transports since June 2016 [88 §obfs blocking]. The reports stated that the TCP handshake would succeed, but the connection would stall (with no packets received from the bridge) a short time after the connection was underway.

We deployed an additional probing script in Kazakhstan. This one tried not only to make a TCP connection, but also establish a full obfs4 connection and build a Tor circuit. Tor reports its connection progress as a “bootstrap” percentage: progression from 0% to 100% involves first making an obfs4 connection, then downloading directory information and the consensus, and finally building a circuit. Figure 5.5 shows the results of the tests. What we found was consistent with reports: despite being reachable at the TCP layer, some bridges would fail bootstrapping at 10% (e.g., Mosaddegh:80 and GreenBelt:80) or 25% (e.g., Mosaddegh:443 and GreenBelt:443). For three of the bridges (Mosaddegh:9332, Lisbeth:443, and NX01:443) we caught the approximate moment of blocking. Initially they bootstrapped to 100% and agreed with the control, but later they reached only 25% and disagreed with the control. Incidentally, these results suggest that Kazakhstan, too, blocks on a per-port basis, because for a time Mosaddegh:80 and Mosaddegh:443 were blocked while Mosaddegh:9332 was unblocked. Two more bridges (cymrubridge31:80 and cymrubridge33:80) remained unblocked.

ndnop3:10527 and ndnop5:13764, in the 5.5/6.0a1 batch, are a special case. Their varying bootstrap percentages were caused by a misconfiguration on the bridge itself (a file descriptor limit was set too low). Even from the control site in the U.S., connections would fail to bootstrap to 100% about 35% of the time. Still, it appears that both bridges were also blocked in Kazakhstan, because from the control site the bootstrap percentage would oscillate between 10% and 100%; while from Kazakhstan it would oscillate between 10% to 25%.

The bridges in the 6.0.6/6.5a4 and 6.0.8/6.5a6 batches were blocked on or around January 26, 2017. This sets the blocking delay at either 71 or 43 days after public release, depending on which release you compare against.

6.1 Work related to domain fronting

I did not invent domain fronting. I did, however, give it a name, help popularize its use, and produce an important implementation. As far as I have been able to find out, the first implementation of domain fronting was in GoAgent, a circumvention system, circa 2012. GoAgent employed a variant of fronting where the SNI is omitted, rather than being faked. Earlier in 2012, Bryce Boe wrote a blog post [17] outlining how to use Google App Engine as a proxy, and suggested that sending a false SNI could bypass SNI whitelisting. Even farther back, in 2004, when HTTPS and CDNs were less common, Köpsell and Hillig [120 §5.2] foresaw the possibilities of a situation such as exists today: “Imagine that all web pages of the United States are only retrievable (from abroad) by sending encrypted requests to one and only one special node. Clearly this idea belongs to the ‘all or nothing’ concept because a blocker has to block all requests to this node.”

Refraction networking is the name for a class of circumvention techniques that share similarities with domain fronting. The idea was introduced in 2011 with the designs Cirripede [104], CurveBall [112], and Telex [203]. In refraction networking, it is network routers that act as proxies, lying at the middle of network paths rather than at the ends. The client “tags” its messages in a way that the censor cannot detect (analogously to the way the Host header is encrypted in domain fronting). When the router finds a tagged message, it shunts the message away from its nominal destination and towards some other, covert destination. Refraction networking derives its blocking resistance from the collateral damage that would result from blocking the cover channel (typically TLS) or the refraction-capable network routers. Refraction networking has the potential to be the basis of exceptionally high-performance circumvention, as a test deployment in Spring 2017 demonstrated [94].

CloudTransport [23], proposed in 2014, is like domain fronting in many respects. It uses HTTPS to a shared server (in this case a cloud storage server). The specific storage area being accessed—what the censor would like to know—is encrypted, so the censor cannot block CloudTransport without blocking the storage service completely.

In 2015 I published a paper on domain fronting [89] with Chang Lan, Rod Hynes, Percy Wegmann, and Vern Paxson. In it, we described the experience of deploying domain fronting on Tor, Lantern [121], and Psiphon [157], and began an investigation into side channels, such as packet size and timing, that a censor might use to detect domain fronting. The Tor deployment, called meek, is the subject of Sections 6.2 and 6.3.

Later in 2015 there were a couple of papers on the detection of circumvention transports, including meek. Tan et al. [174] measured the Kullback–Leibler divergence between the distributions of packet size and packet timing in different protocols. (The paper is written in Chinese and my understanding of it is based on an imperfect translation.) Wang et al. [186] built classifiers for meek among other protocols using entropy, timing, and transport-layer features. They emphasized practical classifiers and tested their misclassification rates against real traffic traces.

6.2 A pluggable transport for Tor

I am the main author and maintainer of meek, a pluggable transport for Tor based on domain fronting. meek uses domain-fronted HTTP POST requests as the primitive operation to send or receive chunks of data up to a few kilobytes in size. The intermediate CDN receives domain-fronted requests and forwards them to a Tor bridge. Auxiliary programs on the client and the bridge convert the sequence of HTTP requests to the byte stream expected by Tor. The Tor processes at either end are oblivious to the domain-fronted that is going on between them. Figure 6.2 shows how the components and protocol layers interact.

When the client has something to send, it issues a POST request with data in the body; the server sends data back in the body of its responses. HTTP/1.1 does not provide a way for a server to preemptively push data to a client, so the meek server buffers its outgoing data until it receives a request, then includes the buffered data in the body of the HTTP response. The client must poll the server periodically, even when it has nothing to send, to give the server an opportunity to send back whatever buffered data it may have. The meek server must handle multiple simultaneous clients. Each client, at the beginning of a session, generates a random session identifier string and sends it with its requests in a special X-Session-Id HTTP header. The server maintains separate connections to the local Tor process for each session identifier. Figure 6.3 shows a sequence of requests and responses.

POST / HTTP/1.1
Host: forbidden.example
X-Session-Id: cbIzfhx1Hn+
Content-Length: 517

\x16\x03\x01\x02...

HTTP/1.1 200 OK
Content-Length: 739

\x16\x03\x03\x00...

POST / HTTP/1.1
Host: forbidden.example
X-Session-Id: cbIzfhx1Hn+
Content-Length: 0

HTTP/1.1 200 OK
Content-Length: 75

\x14\x03\x03\x00...

Even with domain fronting to hide the destination request, a censor may try to distinguish circumventing HTTPS connections by their TLS fingerprint. TLS implementations have a lot of latitude in composing their handshake messages, enough that it is possible to distinguish different TLS implementations through passive observation. For example, the Great Firewall used Tor’s TLS fingerprint for detection as early as 2011 [48]. For this reason, meek strives to make its TLS fingerprint look like that of a browser. It does this by relaying its HTTPS requests through a local headless browser (which is completely separate from the browser that the user interacts with).

meek first appeared in Tor Browser in October 2014 [153], and continues in operation to the present. It is Tor’s second-most-used transport (behind obfs4) [176]. The next section is a detailed history of its deployment.

6.3 An unvarnished history of meek deployment

Fielding a circumvention system and keeping it running is full of unexpected challenges. At the time of the publication of the domain fronting paper [89] in 2015, meek had been deployed for only a year and a half. Here I will recount the history of the project from its inception to the present, a period of four years. As the main developer and project leader, I have a unique perspective that I hope to share. As backdrops to the narrative, Figure 6.4 shows the estimated concurrent number of users of meek over its existence, and Table 6.5 shows the monthly cost to run it.

7.1 Design

There are three main components of the Snowflake system. Refer to Figure 7.1.

• many snowflake proxies, which communicate with clients over WebRTC and forward their traffic to the bridge
• many clients, responsible for initially requesting service and then establishing peer-to-peer connections with snowflake proxies
• a broker, an online database that serves to match clients with snowflake proxies
• a bridge (so called to distinguish it from the snowflake proxies), a full-featured proxy capable of connecting to any destination

The architecture of the system is influenced by the requirement that proxies run in a browser, and the nature of WebRTC connection establishment, which uses a bidirectional handshake. In our implementation, the bridge is really a Tor bridge. Even though a Tor circuit consists of multiple hops, that fact is abstracted away from the Tor client’s perspective; Snowflake does not inherently depend on Tor.

A Snowflake connection happens in multiple steps. In the first phase, called rendezvous, the client and snowflake exchange information necessary for a WebRTC connection.

1. The client registers its need for service by sending a message to the broker. The message, called an offer [166], contains the client’s IP address and other metadata needed to establish a WebRTC connection. How the client sends its offer is further explained below.
2. At some point, a snowflake proxy comes online and polls the broker. The broker hands the client’s offer to the snowflake proxy, which sends back its answer [166], containing its IP address and other connection metadata the client will need to know.
3. The broker sends back to the client the snowflake’s answer message.

At this point rendezvous is finished. The snowflake has the client’s offer, and the client has the snowflake’s answer, so they have all the information needed to establish a WebRTC connection to each other.

4. The client and snowflake proxy connect to each other using WebRTC.
5. The snowflake proxy connects to the bridge (using WebSocket, though the specific type of channel does not matter for this step).

The snowflake proxy then copies data back and forth between client and bridge until it is terminated. The client’s communication with the bridge is encrypted and authenticated end-to-end through the WebRTC tunnel, so the proxy cannot interfere with it. When the snowflake proxy terminates, the client may request a new one. Various optimizations are possible, such as having the client maintain a pool of proxies in order to bridge gaps in connectivity, but we have not implemented and tested them sufficiently to state their effects.

The rendezvous phase bears further explanation. Steps 1, 2, and 3 actually happen synchronously, using interleaved HTTP requests and responses: see Figure 7.2. The client’s single request uses domain fronting, but the requests of the snowflake proxies are direct. In Step 1, the client sends a request containing its offer. The broker holds the connection open but does not immediately respond. In Step 2, a snowflake proxy makes a polling request (“do you have any clients for me?”) and the broker responds with the client’s offer. The snowflake composes its answer and sends it back to the broker in a second HTTP request (linked to the first by a random token). In Step 3, the broker finally responds to the client’s initial request by passing on the snowflake proxy’s answer. From the client’s point of view, it has sent a single request (containing an offer) and received a single response (containing an answer). If no proxy arrives within a time threshold of the client sending its offer, the broker replies with an error message instead. We learned from the experience of running flash proxy that it is not difficult to achieve a proxy arrival rate of several per second, so timeouts ought to be exceptional.

One may ask, if the domain-fronted rendezvous channel is bidirectional and already assumed to be difficult to block, doesn’t it suffice for circumvention on its own? The answer is that it does suffice—that’s the idea behind meek (Section 6.3). The disadvantage of building a system exclusively on domain fronting, though, is high monetary cost (see Table 6.5). Snowflake offloads the bulk of data transfer onto WebRTC, and uses expensive domain fronting only for rendezvous.

There are two reasons why the snowflake proxies forward client traffic to a separate bridge, rather than connecting directly to the client’s desired destination. The first is generality: a browser-based proxy can only do the things a browser can do; it can fetch web pages but cannot, for example, open sockets to arbitrary destinations. The second is privacy: the proxies are operated by untrusted, potentially malicious strangers. If they were to exit client traffic directly, they would be able to tamper with it. Furthermore, a malicious client could cause a well-meaning proxy to connect to suspicious destinations, potentially getting its operator in trouble. This “many proxies, one bridge” model is essentially untrusted messenger delivery [63], proposed by Feamster et al. in 2003.

WebRTC offers two features that are necessary for Snowflake: 1. it is supported in web browsers, and 2. it deals with NAT. In other respects, though, WebRTC is a nuisance. Its close coupling with browser code makes it difficult to use as a library outside of a browser; a big part of the Snowflake project was to extract the code into a reusable library, go-webrtc [22]. WebRTC comes with a lot of baggage around audio and video codecs, which is useful for some of its intended use cases, but which we would prefer not to have to deal with. Working within a browser environment limits our flexibility, because we cannot access the network directly, but only at arm’s length through some API. This has implications for detection by content, as discussed in the next section.

7.2 WebRTC fingerprinting

Snowflake primarily tackles the problem of detection by address. The pool of temporary proxies changes too quickly for a censor to keep up with—or at least that’s the idea. Equally important, though, is the problem of detection by content. If Snowflake’s protocol has an easily detectable “tell,” then it could be blocked despite its address diversity. Just as with meek we were concerned about TLS fingerprinting (Section 6.2), with Snowflake we are concerned with WebRTC fingerprinting.

Snowflake will always look like WebRTC—that’s unavoidable without a major change in architecture. Therefore the best we can hope for is to make Snowflake’s WebRTC hard to distinguish from other applications of WebRTC. And that alone is not enough—it also must be that the censor is reluctant to block those other uses of WebRTC.

Mia Gil Epner and I began an investigation into the potential fingerprintability of WebRTC [20, 83]. While preliminary, we were able to find many potential fingerprinting features, and a small survey of applications revealed a diversity of implementation choices in practice.

WebRTC is a stack of interrelated protocols, and leaves implementers much freedom to combined them in different ways. We checked the various protocols in order to find places where implementation choices could facilitate fingerprinting.

Signaling

Signaling is WebRTC’s term for the exchange of metadata and control data necessary to establish the peer-to-peer connection. WebRTC offers no standard way to do signaling [5 §3]; it is left up to implementers. For example, some implementations do signaling via XMPP, an instant messaging protocol. Snowflake does signaling through the broker, during the rendezvous phase.

ICE

ICE (Interactive Connectivity Establishment) [164] is a combination of two protocols. STUN (Session Traversal Utilities for NAT) [165] helps hosts open and maintain a binding in a NAT table. TURN (Traversal Using Relays around NAT) [127] is a way of proxying through a third party when the end hosts’ NAT configurations are such that they cannot communicate directly. In STUN, both client and server messages have a number of optional attributes, including one called SOFTWARE that directly specifies the implementation. Furthermore, the very choice of which STUN and TURN servers to use is a choice made by the client.

Media and data channels

WebRTC offers media channels (used for audio and video) as well as two kinds of data channels (stream-oriented reliable and datagram-oriented unreliable). All channels are encrypted, however they are encrypted differently according to their type. Media channels use SRTP (Secure Real-time Transport Protocol) [16] and data channels use DTLS (Datagram TLS) [161]. Even though the contents of both are encrypted, an observer can easily distinguish a media channel from a data channel. Applications that use media channels have options for doing key exchange: some borrow the DTLS handshake in a process called DTLS-SRTP [135] and some use SRTP with Security Descriptions (SDES) [11]. Snowflake uses reliable data channels.

DTLS

DTLS, as with TLS, offers a wealth of fingerprintable features. Some of the most salient are the protocol version, extensions, the client’s offered ciphersuites, and values in the server’s certificate.

Snowflake uses a WebRTC library extracted from the Chromium web browser, which mitigates some potential dead-parrot distinguishers [103]. But WebRTC remains complicated and its behavior on the network depends on more than just what library is in use.

We conducted a survey of some WebRTC-using applications in order to get an idea of the implementation choices being made in practice. We tested three applications that use media channels, all chat services: Google Hangouts (https://hangouts.google.com), Facebook Messenger (https://www.messenger.com), and OpenTokRTC (https://opentokrtc.com/). We also tested two applications that use data channels: Snowflake itself and Sharefest (https://github.com/Peer5/ShareFest), a now-defunct file sharing service. Naturally, the network fingerprints of all five applications were distinguishable at some level. Snowflake, by default, uses a Google-operated STUN server, which may be a good choice because so do Hangouts and Sharefest. All applications other than Hangouts used DTLS for key exchange. While the client portions differed, the server certificate was more promising, in all cases having a Common Name of “WebRTC” and a validity of 30 days.

Finally, we wrote a script [82] to detect and fingerprint DTLS handshakes. Running the script on a day’s worth of traffic from Lawrence Berkeley National Laboratory turned up only seven handshakes, having three distinct fingerprints. While it is difficult to generalize from one measurement at one site, these results suggest that WebRTC use—at least the forms that use DTLS—is not common. We guessed that Google Hangouts would be the main source of WebRTC connections; however our script would not have found Hangouts connections because Hangouts does not use DTLS.