Tools and Criteria

Method

We exemined how circumvention tool authors evaluate their tools; we did not exemine the tools themselves nor attempt to evaluate them.

We organize evluation criteria into two classes: (1) abstract goals and (2) concrete metrics. The goals motivate the metrics, whereas the metrics can be measured of an approach.

To understand the evaluations that document authors had in mind for each goal and metric we determined whether each paper mentioned it. We included discussed criteria regardless of whether a documented approach actually met it, or even tried to. On the other hand, we only record the criteria as documented: we made no effort to infer undocumented goals and metrics. As such, we do not list some tools as having criteria they meet since they did not document it as an evaluation criteria.

For documents about a single approach, we also assessed which metrics the authors “checked off”. For binary metrics, we checked off those that the document stated that the approach provided. For quantitative metrics, we checked off those for which the document provided a measured value, since these have no clear cutoffs for satisfaction. We did not check off goals, since there is no clear meaning of satisfying most of them due to their generality.

We included not just complete circumvention tools, but also components of them and papers on how tool's should be evaluated. Not all the criteria make sense for all the documents and tools we exemined.

For more details, please see our paper.

Criteria Matrix

= Used in the wild
= Not used yet
/= goal/metric mentioned
= metric “checked off”
DEFIANCE Infranet Identity-based Steganographic Tagging Message in a Bottle Trist SkyF2F Collage Cirripede Decoy routing Telex CensorSpoofer Flash Proxy SkypeMorph StegoTorus Dust OSS Marionette FreeWave SWEET Facade Facet TapDance CloudTransport Bit-smuggler Castle Rook CacheBrowser Rebound Freedom House 2011 Circumvention is not privacy Berkman 2011 Tor 10 things BridgeDB MessageStreamEncryption FOE MailMyWeb Obfs2 Obfs3 Obfs4 ScrambleSuit GoAgent Meek FTE VPN Gate uProxy CGIProxy Ultrasurf FreeGate Psiphon Lantern GTunnel Hotspot Shield JAP Your Freedom Green Simurgh GoHop
GOAL: adaptability to blocking adaptabil... adaptabil... adaptabil... adaptabil... adaptabil... adaptabil... adaptabil... adaptabil... adaptabil... adaptabil...
time to create an adaptation time to c...
GOAL: availability of infrastructure availabil... availabil... availabil... availabil... availabil... availabil... availabil... availabil... availabil... availabil... availabil... availabil... availabil... availabil... availabil... availabil...
geographic diversity of proxies geographi...
independent deployment independe...
number of proxies number of... number of... number of... number of...
preponderance of suitable servers preponder... preponder... preponder... preponder... preponder...
rate of proxy churn rate of p... rate of p...
stability of decoy hosts stability...
GOAL: client performance client pe... client pe... client pe... client pe... client pe...
CPU usage by users CPU usage... CPU usage... CPU usage... CPU usage... CPU usage...
memory usage by users memory us... memory us... memory us...
startup time startup t...
GOAL: decentralization of trust decentral... decentral... decentral... decentral... decentral... decentral...
GOAL: deniability under computer inspection deniabili... deniabili... deniabili...
no installation no instal... no instal... no instal... no instal... no instal... no instal... no instal... no instal... no instal... no instal... no instal... no instal...
GOAL: developed by experts developed... developed...
GOAL: diversity of users diversity... diversity...
GOAL: end-user protection end-user ... end-user ... end-user ... end-user ... end-user ... end-user ... end-user ... end-user ... end-user ... end-user ... end-user ... end-user ... end-user ... end-user ... end-user ... end-user ... end-user ... end-user ... end-user ... end-user ... end-user ... end-user ... end-user ... end-user ... end-user ... end-user ... end-user ... end-user ... end-user ...
does not store user information does not ... does not ... does not ... does not ... does not ... does not ... does not ... does not ... does not ... does not ... does not ... does not ...
hide user information from end host hide user... hide user... hide user... hide user... hide user... hide user... hide user... hide user... hide user... hide user... hide user... hide user... hide user... hide user... hide user... hide user... hide user... hide user... hide user... hide user... hide user... hide user... hide user... hide user... hide user... hide user... hide user...
GOAL: infrastructure cost infrastru... infrastru... infrastru... infrastru... infrastru... infrastru...
cost of external services cost of e... cost of e... cost of e... cost of e... cost of e... cost of e...
GOAL: network performance network p... network p... network p... network p... network p... network p... network p... network p... network p... network p... network p... network p... network p... network p... network p... network p... network p... network p... network p... network p... network p... network p... network p... network p... network p... network p... network p... network p... network p... network p... network p... network p... network p... network p...
byte overhead byte over... byte over... byte over... byte over... byte over... byte over... byte over... byte over... byte over...
fraction of clients that can utilize the network fraction ...
goodput goodput goodput goodput goodput goodput goodput goodput goodput goodput goodput goodput goodput goodput goodput goodput goodput
latency latency latency latency latency latency latency latency latency latency latency
number of requests needed to retrieve data number of... number of...
registration performance registrat... registrat... registrat...
speed of downloading a webpage speed of ... speed of ... speed of ... speed of ... speed of ... speed of ... speed of ... speed of ... speed of ... speed of ...
throughput throughpu... throughpu... throughpu... throughpu... throughpu... throughpu... throughpu... throughpu... throughpu... throughpu... throughpu...
time overhead time over... time over... time over... time over... time over...
GOAL: openness of design openness ... openness ... openness ... openness ... openness ... openness ... openness ... openness ... openness ... openness ... openness ... openness ... openness ... openness ... openness ... openness ... openness ... openness ... openness ... openness ... openness ... openness ... openness ... openness ... openness ... openness ... openness ... openness ... openness ... openness ... openness ... openness ... openness ... openness ... openness ... openness ... openness ...
open source open sour... open sour... open sour... open sour... open sour... open sour... open sour... open sour... open sour... open sour... open sour... open sour... open sour... open sour... open sour... open sour... open sour... open sour... open sour... open sour... open sour... open sour... open sour... open sour... open sour... open sour... open sour... open sour... open sour... open sour... open sour... open sour... open sour... open sour... open sour...
GOAL: resistance to active probing resistanc... resistanc... resistanc... resistanc... resistanc... resistanc... resistanc... resistanc... resistanc... resistanc... resistanc... resistanc... resistanc... resistanc... resistanc... resistanc... resistanc...
respond to probes like something else respond t... respond t... respond t... respond t... respond t... respond t... respond t...
use authentication use authe... use authe... use authe... use authe... use authe... use authe... use authe... use authe...
GOAL: resistance to blocking resistanc... resistanc... resistanc... resistanc... resistanc... resistanc... resistanc... resistanc... resistanc... resistanc... resistanc... resistanc... resistanc... resistanc... resistanc... resistanc... resistanc... resistanc... resistanc... resistanc... resistanc... resistanc... resistanc... resistanc... resistanc... resistanc... resistanc... resistanc... resistanc... resistanc... resistanc... resistanc... resistanc...
use a popular protocol use a pop... use a pop... use a pop... use a pop... use a pop... use a pop... use a pop... use a pop... use a pop...
use many access points use many ... use many ... use many ... use many ... use many ... use many ... use many ... use many ... use many ... use many ... use many ... use many ...
use network infrastructure use netwo... use netwo... use netwo... use netwo... use netwo...
use popular hosts use popul... use popul... use popul... use popul... use popul... use popul... use popul...
GOAL: resistance to insider attacks resistanc...
GOAL: resistance to security attacks resistanc... resistanc... resistanc... resistanc... resistanc... resistanc... resistanc... resistanc... resistanc... resistanc... resistanc... resistanc... resistanc... resistanc... resistanc... resistanc... resistanc... resistanc... resistanc... resistanc... resistanc... resistanc... resistanc... resistanc... resistanc... resistanc... resistanc... resistanc... resistanc... resistanc...
ignore invalid connections (DoS) ignore in... ignore in... ignore in...
limit service to each user ID (DoS) limit ser... limit ser... limit ser... limit ser... limit ser...
use TLS for confidentiality use TLS f... use TLS f...
use authenticated key exchange (MITM) use authe...
use block cipher (key reuse) use block...
use certificate pinning (MITM) use certi... use certi...
use client puzzle (DoS) use clien... use clien... use clien... use clien...
use encryption for confidentiality use encry... use encry... use encry... use encry... use encry... use encry... use encry... use encry... use encry... use encry... use encry... use encry...
use shared secret (MITM) use share... use share...
use strong third-party service (DoS) use stron... use stron...
use timestamp (replay) use times... use times... use times... use times... use times... use times...
use trustworthy proxy use trust... use trust... use trust... use trust... use trust...
GOAL: resistance to traffic analysis resistanc... resistanc... resistanc... resistanc... resistanc... resistanc... resistanc... resistanc... resistanc... resistanc... resistanc... resistanc... resistanc... resistanc... resistanc... resistanc... resistanc... resistanc... resistanc... resistanc... resistanc... resistanc... resistanc... resistanc... resistanc... resistanc... resistanc... resistanc... resistanc...
TLS characteristics TLS chara... TLS chara...
concurrent connection count concurren...
connection length connectio... connectio... connectio... connectio...
inter-packet timing inter-pac... inter-pac... inter-pac... inter-pac... inter-pac... inter-pac... inter-pac... inter-pac... inter-pac... inter-pac... inter-pac...
lack of server response lack of s...
matching allowed n-gram distribution matching ... matching ...
network stack fingerprinting network s... network s...
number of HTTP requests/responses number of...
packet size distribution packet si... packet si... packet si... packet si... packet si... packet si... packet si... packet si... packet si... packet si... packet si... packet si... packet si... packet si... packet si...
protocol misclassification rate protocol ... protocol ...
serial connection count serial co... serial co...
total TCP connection total TCP...
total payload length total pay...
use encryption to resist traffic analysis use encry... use encry... use encry... use encry... use encry... use encry... use encry... use encry... use encry... use encry... use encry... use encry...
use random port use rando... use rando... use rando... use rando...
GOAL: resistance to traffic manipulation resistanc... resistanc... resistanc... resistanc... resistanc... resistanc... resistanc... resistanc... resistanc... resistanc... resistanc...
limit service to each user ID (DoS) limit ser... limit ser... limit ser... limit ser... limit ser...
use TLS for integrity use TLS f... use TLS f...
use UDP with reliability use UDP w... use UDP w... use UDP w...
use authentication use authe... use authe... use authe... use authe... use authe... use authe... use authe... use authe...
use error correcting codes use error... use error...
GOAL: self promotion self prom...
GOAL: server obfuscation server ob... server ob...
indirect connection to forwarder indirect ... indirect ...
GOAL: sustainable network and development sustainab... sustainab... sustainab...
GOAL: usability usability usability usability usability usability usability usability usability usability usability usability usability usability usability usability usability usability usability usability usability usability usability usability usability
application support applicati... applicati...
availability of documentation availabil... availabil... availabil...
clean uninstall clean uni... clean uni...
free/low cost free/low ... free/low ... free/low ... free/low ... free/low ... free/low ... free/low ... free/low ... free/low ... free/low ... free/low ...
has a GUI has a GUI has a GUI
localization localizat... localizat... localizat... localizat... localizat...
no installation no instal... no instal... no instal... no instal... no instal... no instal... no instal... no instal... no instal... no instal... no instal... no instal...
no usage limitation no usage ... no usage ... no usage ...
number of errors per webpage number of...
portability portabili... portabili... portabili... portabili...
small download file small dow... small dow... small dow... small dow... small dow... small dow... small dow... small dow... small dow... small dow... small dow... small dow...
software updates software ... software ... software ...
GOAL: usage usage usage usage usage usage usage usage usage usage usage
number of unique connections number of...
number of users number of... number of... number of...
test deployment test depl... test depl... test depl... test depl... test depl... test depl... test depl... test depl... test depl...
GOAL: veracity of claims veracity ... veracity ...

Criteria

adaptability to blocking

Used by Marionette, SWEET, Facade, Facet, Castle, Rook, Circumvention is not privacy, FTE, VPN Gate, uProxy

Assesses the system's resilience to unexpected blocking events and new kinds of blocking.

MARIONETTE (URL)

Despite the progress these obfuscation systems represent, each of them suffers from one or more shortcomings that severely limit their ability to adapt to new network environments or censorship strategies.

Marionette is a network-traffic obfuscation system that empowers users to rapidly explore a rich design space, without the need to deploy new code or re-design the underlying system.

SWEET (URL)

Section 5.2 Availability: IP filtering and DNS hijacking techniques would not be able to stop SWEET traffic as a SWEET user’s traffic is destined to her public email provider, but not to an IP address or nameserver belonging to SWEET system. Another technique used by today’s sophisticated censors is deep packet inspection (DPI). The use of encryption-enabled email renders DPI ineffective, as the email headers get encrypted and the DPI will not be able to analyze the email headers in order to detect the email addresses of SWEET, to hence block the traffic. In the case of plaintext emails, to defeat DPI SWEET server can provide different email aliases to different users or to change its public email address frequently. Note that generating email aliases has no cost for SWEET server and can be done with no limit. In the worst case, a user can obtain her specialized email address through an out of band channel, or by connecting through a encryption-enabled email account (as mentioned before the DPI is ineffective on encryption- enabled emails).

FACADE (URL)

Robust: The tool should be able to continue operation despite attacks from the censor.

FACET (URL)

Our approach is provider independent. Since the emulator devices in Facet are built independently from the videoconferencing systems, Facet can be adopted widely on any conferencing platform, such as Google Hangout, Skype, FaceTime or QQ.

Scalability. The design of Facet should be independent from the specific videoconferencing systems. This scalability will make Facet applicable to a wide range of videoconferencing systems. This property not only makes Facet accessible for the client to use, but also makes it difficult for the censor to block.

CASTLE (URL)

Users of video-game-based censorship-circumvention tools can therefore diversify across many games, making it difficult for the censor to respond by simply blocking a single cover protocol.

The primary goal of Castle is adaptability - Castle is loosely cou- pled to the underlying game, enabling developers to quickly adapt Castle to many games

ROOK (URL)

"Introduction: The general design of Rook is not specific to a game, and so if a censor attempted to block Rook by blocking a single game, it could be adapted to another."

CIRCUMVENTIONNOTPRIVACY (URL)

CIRCUMVENTIONNOTPRIVACY: 7.5.2 Resilient: "The challenge that many solutions face is how to quickly adapt to traffic monitoring (deep packet inspection) and ultimately filtering and blocking.... In any case, tools needs to learn from adversaries and have the capability and flexibility to adapt to new situations."

FTE (URL)

To that end, we develop a generic approach for controlling the format of en- crypted data, so that it will match whatever regex we desire to specify. With this ability, we can force protocol misidentification across a broad range of DPI systems.

VPNGATE (URL)

Section 6.3.Cat-and-mouse game with the Great Firewall authority

UPROXY (URL)

https://docs.google.com/document/d/1t_30vX7RcrEGuWwcg0Jub-HiNI0Ko3kBOyqXgrQN3Kw/edit?pref=2&pli=1#heading=h.g3bfo82x608w (Technical Design Objectives): "Easily extended/strengthened in light of attempts to block or surveille usage"

time to create an adaptation

Used by Castle

The amount of time it takes some programmer to create a new adaptation of the protocol.

CASTLE (URL)

As a consequence, it was possible to port Castle to Aeons and Conquerors in under 6 hours per game.

availability of infrastructure

Used by DEFIANCE, Collage, Cirripede, CensorSpoofer, Flash Proxy, OSS, FreeWave, SWEET, TapDance, Rook, Freedom House 2011, Berkman 2011, Meek, VPN Gate, uProxy, Your Freedom

This criterion considers the availability of the infrastructure used by an approach for users and the feasibility of deployment.

DEFIANCE (URL)

"Section 2 (paper) - Address Pools frustrate address blocking by sheer size and diversity: any address in a pool can be (perhaps only briefly) the address of a DEFIANCE Gateway."

COLLAGE (URL)

Section 7.1 Availability: "A censor may try to prevent clients from sending and re- ceiving messages. Our strongest argument for Collage’s availability depends on a censor’s unwillingness to block large quantities of legitimate content."

CIRRIPEDE (URL)

Section 6.3 DR deployment simulation

CENSORSPOOFER (URL)

Table 2: Usable dummy hosts based on AS paths and Figure 3(e)-(f): stability of the dummy hosts over a short and long time period

FLASHPROXY (URL)

Section 4.3 Capacity

OSS (URL)

Section 3 is a short catalog of online scanning services and states that there are many more and they are easy to find.

FREEWAVE (URL)

Deployment feasibility: An important feature of a circumvention system is the amount of resources (e.g., hardware, network bandwidth, etc.) required for it to be deployed in real world. A circumvention system is also desired to have few dependencies on other systems and entities in order to make it more reliable, secure, and cost-effective.

SWEET (URL)

Section 5.2 Availability: SWEET’s availability is tied to the assumption dis- cussed previously that a censor is not willing to block all email communications, as it would degrade the usability of the Internet for its users. As the use of SWEET does not require an email account with any specific email provider, users can always find an email service to get connected to SWEET.

TAPDANCE (URL)

Server support: In order to measure how many servers can act as decoy destinations, we probed samples of the IPv4 address space as well as the Alexa top million hosts with tests to indicate support for TapDance.

ROOK (URL)

"Introduction: Rook was developed with the FPS as the primary type of game to be used: this is because of the prevalence of private servers and the use a robust and low-latency UDP- based network protocol."

FREEDOMHOUSE_2011 (URL)

FREEDOMHOUSE_2011: Appendix 1, Performance, Likely availability: "In this review we looked for tools that effectively use more than one intermediary so that availability, both in terms of resilience against blocking and against technical failures, is likely high. This criteria favours decentralized tools, as these are likely to have fewer points of failure." Appendix II, Part II, 15: "Consistency: How often do the abovementioned tools enable you to access blocked websites?"

BERKMAN_2011 (URL)

BERKMAN_2011: Preface: "In this report, we focus on questions of utility--the ability for a tool to be installed and used in a particular location..." Summary of Findings: "We evaluated the tools in terms of utility (were they able to connect to blocked webpages?)..."

MEEK (URL)

Section 4 surveys services that support the domain fronting technique.

VPNGATE (URL)

Figure 8. Numbers of VPN servers with changed and unchanged IP addresses.

UPROXY (URL)

https://docs.google.com/document/d/1t_30vX7RcrEGuWwcg0Jub-HiNI0Ko3kBOyqXgrQN3Kw/edit#heading=h.rykn8f4tnrsc (Product Overview): "Goals: Give access in a way that is hard to block: blocking is always possible, but we can push up the collateral damage so that to block uProxy as much of the rest of the internet has to be blocked (e.g. assuming that no country will not block all social/chat networks, video conferencing, and email)."

YOURFREEDOM (URL)

https://www.your-freedom.net/?id=servers shows availability of the servers

geographic diversity of proxies

Used by VPN Gate

Examines the diversity of proxies in terms of geographic location.

VPNGATE (URL)

We gained a total of 16,523 volunteer servers from 127 countries or regions over the course of 175 days. These servers have used 108,633 unique IP addresses. Table 3 shows the geographical distribution of the 2,800 volunteer servers running at 15:00 (GMT) on Au- gust 30, 2013. We resolved the location of each volunteer by using IP address allocation information. We found that 77% of the volunteers were from five countries: Ko- rea, Japan, Vietnam, United States, and Russia.

independent deployment

Used by FreeWave

Can deploy the circumvention approach without needing the help of third-parties, such as friendly ISPs.

FREEWAVE (URL)

Deployment feasibility: The real-world deployment of FreeWave does not rely on other entities. This is in contrast to some recent designs that need collaboration from third parties for their operation. For instance, Infranet [5] requires support from some web destinations that host the circumvention servers. As another example, several recent proposals [10], [11], [51] rely on the collaboration from friendly ISPs for their operation.

number of proxies

Used by DEFIANCE, VPN Gate, uProxy, Your Freedom

The number of proxies usable with the tool.

DEFIANCE (URL)

DEFIANCE: Section 1: "Address Pools are provisioned with sufficient *quantity*, quality, and diversity..." Section 3: "Rather than a few thousand well-known access entry points, tens (or hundreds) of thousands of ephemeral IP addresses are coordinated by Address Pool Operators via central APRAdb servers and regional Gateways."

VPNGATE (URL)

By the end of August it had about 3,000 daily volunteers using 6,300 unique IP addresses to facilitate 464,000 VPN connections from users worldwide, including 45,000 connections and 9,000 unique IP addresses from China.

UPROXY (URL)

https://docs.google.com/document/d/1t_30vX7RcrEGuWwcg0Jub-HiNI0Ko3kBOyqXgrQN3Kw/edit?pref=2&pli=1#heading=h.g3bfo82x608w (Technical Design Objectives): "Scaleable: the more users the more proxies."

YOURFREEDOM (URL)

YOURFREEDOM specifies number of servers on their webpage.

preponderance of suitable servers

Used by Collage, CensorSpoofer, OSS, TapDance, Meek

Some tools rely on finding servers with a specific property at large in the Internet. For example, servers that accept user-posted content, or servers with specific network protocol quirks. This criterion means that the study measured how common such servers really are.

COLLAGE (URL)

COLLAGE can use any available content hosts to transfer messages, e.g., Flickr, blogspot.

CENSORSPOOFER (URL)

CensorSpoofer uses the term "dummy host"; they did an Nmap scan to find hosts with particular SIP port characteristics that they need (see Algorithm 1 and Section 7.2.2).

OSS (URL)

OSS: Section 3 is a short catalog of online scanning services and states that there are many more and they are easy to find.

TAPDANCE (URL)

In TapDance, Section 8 "Server support", they probed 1% of the IPv4 space to find the number of TLS servers that had a long enough timeout and acknowledge out-of-order data in a particular way.

MEEK (URL)

Meek: Section 4 surveys services that support the domain fronting technique.

rate of proxy churn

Used by Flash Proxy, VPN Gate

Measures or estimates the rate at which new proxies appear and old proxies go away.

FLASHPROXY (URL)

Section 4.3 Capacity. Figure 6 shows the number of simultaneous visitors to the web page for each day of the experiment. There were at times as many as three visitors viewing the page at once, but only about 17% of the time was there even one visitor. This web page acting alone would not be able to provide good proxy service, because of the long periods during which there are no visitors and hence no flash proxies. It would take several such pages working together to fill in the gaps and provide continuous service with high probability.

VPNGATE (URL)

Figure 8. Numbers of VPN servers with changed and unchanged IP addresses.

stability of decoy hosts

Used by CensorSpoofer

Examines how long a decoy host is available to carry on a conversation.

CENSORSPOOFER (URL)

Figure 3(e) and 3(f)

client performance

Used by Cirripede, Facet, TapDance, Rebound, FTE

Assesses an approach's client program efficiency in terms of CPU and memory usage.

CIRRIPEDE (URL)

Section 6, Evaluation discusses CPU and memory utilization

FACET (URL)

Section 9.5 Performance Analysis

TAPDANCE (URL)

8 Evaluation

REBOUND (URL)

VII: Performance Results.

FTE (URL)

Section 5. Performance (Memory utilization)

CPU usage by users

Used by Cirripede, Marionette, Facet, TapDance, Rebound

Assesses the percentage of CPU cycles consumed by the client or server part of the system.

CIRRIPEDE (URL)

Cirripede: Section 6.1 "Registration performance": "the load on the RS (in particular, CPU and memory utilization).... the average CPU utilization is 56% and the max 73%. The average memory utilization is 1.1 GB and the max 1.6 GB."

MARIONETTE (URL)

Marionette Section 7.6 and Figure 11: "...the Marionette server for the HTTP specification in Section 7.4 sits idle 98.8% of the time..."

FACET (URL)

Facet (9.5 Performance Analysis) Facet computed CPU cycle with 106 YouTube videos (with length below 180s). For Facet server, CPU costs comes from making a Skype video call (Skype), downloading and redirecting video & audio stream (Gstreamer), and executing a Skype wrapper (Python). The Facet server consumes more CPU cycles (18.7%) than Squid (0.4%) (most of which comes from the Skype video call).

TAPDANCE (URL)

TapDance looked at CPU usage by the proxy station and the client. Section 8: "We find that the CPU performance is bottlenecked by our single-threaded client. During our tests, the client consumes 100% CPU on a single core, while each of the 8 processes on the ISP station consume between 4-7% CPU."

REBOUND (URL)

VII: "...our unoptimized Python implementation of the Rebound router uses less than half of the processing bandwidth of a single core of an Intel Xeon E5620 2.4 GHz processor"

memory usage by users

Used by Cirripede, Facet, FTE

Assesses the memory requirements to run the system.

CIRRIPEDE (URL)

Cirripede: Section 6.1 "Registration performance": "the load on the RS (in particular, CPU and memory utilization).... the average CPU utilization is 56% and the max 73%. The average memory utilization is 1.1 GB and the max 1.6 GB."

FACET (URL)

Facet (9.5 Performance Analysis) Facet computed memory usage with 106 YouTube videos (with length below 180s). For Facet server, the costs comes from making a Skype video call (Skype), downloading and redirecting video & audio stream (Gstreamer), and executing a Skype wrapper (Python). The Facet server consumes more memory (3%) than Squid (0.3%) (most of which comes from the Skype video call).

FTE (URL)

FTE (Section 5- Memory utilization.)

startup time

Used by Freedom House 2011

Measures how quickly client software starts up.

FREEDOMHOUSE_2011 (URL)

FREEDOMHOUSE_2011: Appendix 1, Performance, Start-up: "we have assessed whether a tool is quick to start up and whether usage can start instantly or requires a burdensome installation and/or payment."

decentralization of trust

Used by Rebound, Freedom House 2011, Circumvention is not privacy, Berkman 2011, Tor 10 things, uProxy

Evaluates the degree to which trust is centralized; i.e., all trust is placed in a single server/company, or spread out among many parties.

REBOUND (URL)

(Mentioned but not satisfied.) II: "...we assume that the user can trust the Rebound software and the decoy router; compromise of the decoy router would compromise its users as well."

FREEDOMHOUSE_2011 (URL)

FREEDOMHOUSE_2011: Appendix 1, Performance, Likely availability: "In this review we looked for tools that effectively use more than one intermediary so that availability, both in terms of resilience against blocking and against technical failures, is likely high. This criteria favours decentralized tools, as these are likely to have fewer points of failure."

CIRCUMVENTIONNOTPRIVACY (URL)

CIRCUMVENTIONNOTPRIVACY: 7.5.1 Decentralized vs Centralized: "In our review we were looking for tools that use more than one intermediary."

BERKMAN_2011 (URL)

BERKMAN_2011: Background, Trust and security: "With one notable exception, proxy systems give their operators a great deal of power to examine the traffic passing through their systems."

TOR10THINGS (URL)

TOR10THINGS: 5 Has a decentralized architecture: "A centralized tool puts all of its users' requests through one or a few servers that the tool operator controls. A decentralized design like Tor or JAP sends the trac through multiple dierent locations, so there is no single location or entity that gets to watch what websites each user is accessing."

UPROXY (URL)

https://www.uproxy.org/faq.html#whoKnowsThat: "Anyone you connect with knows that you're using uProxy. In addition, if you choose to connect uProxy to a social network such as Facebook, the administrators of the social network can tell that you use uProxy, and your friends on that network who are using uProxy may also be able to tell. For users connecting with a Gmail or Facebook account, uProxy uses Firebase, a service operated by Google. The Firebase team, and the uProxy team which administers the uProxy Firebase account, can therefore access information about which accounts are using uProxy." https://docs.google.com/document/d/1t_30vX7RcrEGuWwcg0Jub-HiNI0Ko3kBOyqXgrQN3Kw/edit#heading=h.rykn8f4tnrsc (Product Overview): "Goals: Improve security and trust: provide a better basis for the both users and providers of proxies to trust each other and have the capacity to securely communicate." https://docs.google.com/document/d/1t_30vX7RcrEGuWwcg0Jub-HiNI0Ko3kBOyqXgrQN3Kw/edit?pref=2&pli=1#heading=h.g3bfo82x608w (Technical Design Objectives): "Robust to interference: Minimise single points of failure, Supports obfuscation of proxy connections, Easily extended/strengthened in light of attempts to block or surveille usage."

deniability under computer inspection

Used by Collage, SkypeMorph, Castle

Whether the circumvention tool users can plausibly deny using it even when their computers are inspected.

COLLAGE (URL)

While Collage discusses "deniability", it is in the sense of resistence to traffic analysis.

SKYPEMORPH (URL)

Claims to not have this property: "Plausible deniability: The only way to prove that a node is actually using SkypeMorph software is to break into a user’s machine or to coerce him to divulge his information. Otherwise, communicating through SkypeMorph should look like a normal Skype video chat."

CASTLE (URL)

Vague but does mention "Deniability and ease of distribution."

no installation

Used by SkyF2F, Flash Proxy, Facet, Freedom House 2011, Circumvention is not privacy, Tor 10 things, MailMyWeb, CGIProxy, Ultrasurf, FreeGate, Psiphon, Lantern

Using the tool does not require installing special software.

SKYF2F (URL)

Section IV.C, SYSTEM DESCRIPTION, "Our system is a plug-in application Skype Client. As Skype clients are widespread over the Internet, low deployment costs become available and user can use the system easily (without installing any additional software)."

FLASHPROXY (URL)

Relay operators. On the part of Tor relay operators, the only additional requirement is to run the flash proxy server transport plugin. This is a matter of installing the plugin and adding a line to the relay's configuration file. Clients. Our programs are designed to work with the Tor pluggable transports design, so configuration is fairly easy. A user must run the transport plugin, add a few lines to the Tor configuration file, and then be able to register with the facilitator. Our transport plugin is written in Python, which is an additional requirement beyond plain Tor. If the user is not able to receive direct TCP connections, the more technical step of enabling port forwarding must be taken. A Windows installer can automate this process and we plan to build one as interest increases.

FACET (URL)

FACET: No deployment at client side. For Facet clients, there is no need to install any client software (which is often blocked), or to pre-share secrets with the server. This property makes Facet easier to use and maintain, since software updates only need to be applied by servers outside of the censored region.

FREEDOMHOUSE_2011 (URL)

FREEDOMHOUSE_2011: Appendix 1, Usability, Accessibility (portability): "Some tools work without client application (for example, they rely on server side application only). This approach is a great advantage in terms of accessibility." Appendix 1, Privacy/Security, Portability: "Software that does not need to be installed on a computer, but can run from a single executable file or even from an external flash drive, provides more flexibility than the ones that require installation. It is easier to hide the existence of software with high portability than one that is installed on a computer. In this review we looked for tools that do not leave traces during operation and after being uninstalled." Appendix 1, Performance, Start-up: "...whether usage can start instantly or requires a burdensome installation..."

CIRCUMVENTIONNOTPRIVACY (URL)

CIRCUMVENTIONNOTPRIVACY: 7.3.3 Access to software: "Some tools work without client application (relied on server side application only), which is a great advantage in terms of accessibility." 7.3.6 Portability: "A software that does not need to be installed in a computer, but can run from a single executable file or even from an external flash drive, provides more flexibility that those that require an installer."

TOR10THINGS (URL)

TOR10THINGS: 9 Makes it easy to get the software and updates: "The best answer here is to not require any specialized client software. Psiphon, for example, relies on a normal web browser, so it doesn't matter if the censors block their website."

MAILMYWEB (URL)

mailmyweb doesn't need installation

CGIPROXY (URL)

http://www.jmarshall.com/tools/cgiproxy/install.html: Installing CGIProxy is often trivial ... You need to install CGIProxy on a machine that's outside of any censoring firewall, but that is still accessible to people behind the firewall. You do NOT need to install anything on the browsing machine(s). Once CGIProxy is installed on a machine, any number of people can use it, if they know its URL.

ULTRASURF (URL)

ULTRASURF, FREEGATE don't require any installation.

FREEGATE (URL)

http://www.dongtaiwang.com/loc/faq_en.php: How do I install and run Freegate? You may download and run Freegate without any installation. Just double click the Freegate executible. Your IE browser will launch and open the Dynaweb homepage. You can fill in the address of the website you want to visit in the input box and click "Anonymous Surfing".

PSIPHON (URL)

Does not require installation.

LANTERN (URL)

LANTERN has a easy setup

developed by experts

Used by Freedom House 2011, Circumvention is not privacy

Assesses whether the developers of the tool are known security experts.

FREEDOMHOUSE_2011 (URL)

FREEDOMHOUSE_2011 (sorta): JAP: "The trustworthiness of the software is very high due to the reputation of the developers (researchers from well respected universities), and the openness of the code (the source code is publicly available)."

CIRCUMVENTIONNOTPRIVACY (URL)

CIRCUMVENTIONNOTPRIVACY: 7.2.4 Developers: "Who are the developers behind the tool? What is their background and previous experience in the field of computer security and Internet privacy? In our review we were looking for tools that have recognized security experts in their development teams."

diversity of users

Used by Circumvention is not privacy, Tor 10 things

Assesses the diversity of types of users of the system.

CIRCUMVENTIONNOTPRIVACY (URL)

CIRCUMVENTIONNOTPRIVACY: 7.4.1 Target group: "We assume that tools with a diverse set of users are more suitable for circumvention as they can not bind a user to a certain group of people or organization."

TOR10THINGS (URL)

TOR10THINGS: 1 Has a diverse set of users: "A wide variety of users means that if somebody finds out you are using the software, they can't conclude much about why you're using it."

end-user protection

Used by SkyF2F, Cirripede, Telex, Flash Proxy, SkypeMorph, StegoTorus, OSS, FreeWave, CloudTransport, Freedom House 2011, Circumvention is not privacy, Tor 10 things, Obfs2, Obfs3, Obfs4, Meek, FTE, VPN Gate, uProxy, CGIProxy, Ultrasurf, FreeGate, Psiphon, Lantern, GTunnel, Hotspot Shield, JAP, Your Freedom, Green Simurgh

Assesses whether an approach protects user's privacy from intermediate and end nodes.

SKYF2F (URL)

However, Skype does not guarantee strong anonymity. To improve anonymity, existing anonymity systems could be tailored to our system.

CIRRIPEDE (URL)

Using Cirripede alone provides unobservability from the warden ISP, but it does not provide destination-anonymity from the Cirripede system itself, the service proxy knows the covert destination being targeted by a client.

TELEX (URL)

Unlike Tor, we separate the problem of censorship resistance from that of anonymous communication and concentrate on re- sisting blocking; users who require increased anonymity can use Telex as a gateway to the Tor network.

FLASHPROXY (URL)

Uses Tor for anonymity

SKYPEMORPH (URL)

Uses Tor for anonymity

STEGOTORUS (URL)

"StegoTorus preserves Tor\u2019s basic design goals: Unlinkability:\ \ The censor should not be able to determine which Internet users communicate\ \ with which remote hosts via Tor.\n"

OSS (URL)

Section 7: Eavesdropping by the OSS. Our threat model assumes that the OSS is not colluding with the censor; however it is not necessarily a trusted entity. An OSS can intercept all communications between the user and the cooperating proxy. In this sense the OSS resembles an ISP, Tor entry relay, or other network router that lies on the path between the user and the cooperating proxy. Traffic should be encrypted and authenticated, as the Tor protocol is, to prevent eavesdropping and tampering by the OSS.

FREEWAVE (URL)

A FreeWave server only knows the VoIP IDs of its client, but not their IP addresses since the VoIP connections are being relayed through intermediate VoIP nodes. As a result, unless the VoIP service (e.g., the Google Voice server, or a Skype supernode owned by a FreeWave server) is colluding with the FreeWave server, the FreeWave server will not be able to link VoIP IDs to IP addresses, i.e., the client is anonymous to the server.

CLOUDTRANSPORT (URL)

Table 2 shows what information CloudTransport aims to hide from, respectively, the censoring ISP, cloud storage provider, and CloudTransport bridges. The cloud storage provider is trusted not to reveal to the censors the identities and network locations of its customers who are using CloudTransport. The bridges are trusted not to perform flow correlation (see Section 4.4). In the tunnel mode, the bridges must also be trusted not to reveal the contents and destinations of CloudTransport traffic; this assumption is not required in the proxified modes.

FREEDOMHOUSE_2011 (URL)

FREEDOMHOUSE_2011: Appendix 1, Privacy/Security: "The ideal case will allow the users of the technology to remain anonymous and would make the requested content not traceable to any particular user." Appendix II, Part 1, 9: "Which is the *most* important to you in choosing a circumvention tool? Anonymity/security." Appendix II, Part 1, 10: "Which is the *second* most important to you in choosing a circumvention tool? Anonymity/security."

CIRCUMVENTIONNOTPRIVACY (URL)

CIRCUMVENTIONNOTPRIVACY: 7.4.3 End-user privacy: "An important aspect of a circumvention tools is the ability to hide where the initial request come from." 7.4.4 Location Privacy: "Location privacy is critical when using circumvention tools that can run from mobile devices or laptops connected to 3G mobile networks."

TOR10THINGS (URL)

TOR10THINGS: 6 Keeps you safe from websites too. "Privacy isn't only about whether the tool operator can log your requests. It's also about whether the websites you visit can recognize or track you."

OBFS2 (URL)

Uses Tor for anonymity

OBFS3 (URL)

Uses Tor for anonymity

OBFS4 (URL)

Similar to obfs2/3

MEEK (URL)

Uses Tor for anonymity from the final website but the CDN can see the user's IP. Section 9 Discussion: "Even though the censor does not know which client IP addresses are engaging in circumven- tion, the CDN knows. The risk is especially acute when client browses a web site of the same entity that con- trols the intermediate web server, for example brows- ing YouTube while fronting through www.google.com. When this happens, the web service gets to see both entry and exit traffic, and is in a better position to at- tempt to correlate flows by timing and volume, even when the underlying channel is an encrypted protocol like Tor. This phenomenon seems hard to counter, be- cause the front domain needs to be a popular one in order to have high collateral damage, but popular do- mains are also the ones that users tend to want to visit. It is in theory possible to dynamically switch between multiple fronts, so as to avoid the situation where the destination and front are under the same control, at the cost of leaking information about where the user is not going at a given moment."

FTE (URL)

Uses Tor for anonymity

VPNGATE (URL)

VPN Gate does not do well to protect end user privacy: Section 1: "VPN Gate is a system for bypassing censorship. It is not an anonymizer. Unlike Tor, VPN Gate volunteer servers record packet logs."

UPROXY (URL)

https://www.uproxy.org/faq.html#doesUproxyLogData: "We ask users if they would like to opt-in to report usage metrics. If they do, all metrics are anonymized on the client (before they are submitted) using Rappor. In addition, when users manually use the Submit Feedback tool in the settings menu, they have the option to include logs from their recent uProxy activity. Logs may contain personally identifiable information (PII). PII is never shared outside the uProxy team, and the logs that contain it are retained for at most three months before being deleted. All reports are submitted in a way that makes it hard for an adversary to detect uProxy users." https://docs.google.com/document/d/1t_30vX7RcrEGuWwcg0Jub-HiNI0Ko3kBOyqXgrQN3Kw/edit#heading=h.rykn8f4tnrsc (Product Overview): "Non-goals: Strong anonymity. We are not trying to anonymize the proxy owner and user from each other. uProxy depends on leveraging existing trust relationships to to find and use a proxy."

CGIPROXY (URL)

http://www.jmarshall.com/tools/cgiproxy/ (What it is, what it is) : This CGI script (or other) acts as an HTTP, HTTPS, or FTP proxy. Through it, you can retrieve any resource that is accessible from the server it runs on. This is useful when your own access is limited, but you can reach a server that in turn can reach others that you can't. In addition, the user is kept as anonymous as possible from any servers.

ULTRASURF (URL)

http://ultrasurf.us/security.html (Data Retention Policy): We log bare minimum information for anti blocking purposes. We only keep logs for maximum of 30 days. http://ultrasurf.us/privacy.html: (1) Web Server Logs.

When you visit our Website, we may track information to administer the site and analyze its usage. Examples of information we may track include:

1. Your Internet protocol address (IP). 2. Number of links you click within the site. 3. Date and time of your visit. 4. Web page you linked to our site from. 5. Pages you viewed on the site.

FREEGATE (URL)

http://www.dongtaiwang.com/loc/faq_en.php#ip: When I use Freegate, is my IP exposed? Freegate will hide your real IP when you surf the Internet

PSIPHON (URL)

https://psiphon.ca/en/privacy.html "We use Google Analytics on some of our websites to collect information about usage. The information collected by Google Analytics will only be used for statistical analysis related to your browsing behaviour on this specific site. The information we obtain from Google Analytics is not personally identifying, nor is it combined with information from other sources to create personally identifying information." "User IP addresses are not collected by Psiphon servers in the normal course of operation. Psiphon does not require user accounts, so, by default, there is no collection of email addresses, usernames, or passwords."

LANTERN (URL)

(https://getlantern.org/faq/index.html) Lantern allows you to provide the Lantern team with useful information and analytics that will help us improve the Lantern program. You can change this option in your Lantern settings. If you choose to send Lantern this data we will only use it for improving the Lantern service so that we can continue to offer better service for you and others.

"If you enable this option we use:

Google Analytics with IP Anonymization to store information about your usage. Loggly.com to store information about errors in the Lantern software. When you install Lantern, we ask if you want to contribute this information. You can change this setting at any time in the settings menu."

GTUNNEL (URL)

"User's IP address is hidden and user's Internet privacy protected. The destination servers see GTunnel server addresses instead." http://gardennetworks.org/products: "In Tor mode, GTunnel connects throuph Tor nodes and adds security to Tor users. In GTunnel Tor mode, even the Tor exit node owners do not see the original traffic."

HOTSPOTSHIELD (URL)

Hides IP address from websites (https://www.hotspotshield.com/hide-ip-address/)

JAP (URL)

https://anonymous-proxy-servers.net/en/faq-jondo.html#1f: "Do you save log files? JonDonym mixes usually do not collect user data. Ony a respective legal obligation may force some Mix operators to retain certain connection data."

YOURFREEDOM (URL)

"(https://docs.google.com/document/d/1fROW15y2nO8LoE3heU7slgE6lAsWerAK4vCc4DGfqKE/pub#h.5lsd0xw8ldtq): It has been said before that Your Freedom is not a full-blown anonymization service. It will however hide your IP address, unless your application communicates it “in-band”. Web server admins will not be able to see where the access comes from initially; they will instead see one of our IP addresses. But we do not take any further anonymization measures: we do not remove tracking cookies, nor do we "wash" the request headers that your web browser sends."

GREENSIMURGH (URL)

Hides IP address of the user from the websites

does not store user information

Used by Freedom House 2011, Circumvention is not privacy, Tor 10 things, VPN Gate, uProxy, Ultrasurf, Psiphon, Lantern, GTunnel, Hotspot Shield, JAP, Your Freedom

Does not log user information.

FREEDOMHOUSE_2011 (URL)

FREEDOMHOUSE_2011: Appendix 1, Privacy/Security, Logging practises: "It is important to determine what information is stored in the proxy that is handling the requests. This also includes whether or not IP addresses and the requested URLs are logged. For tools that do maintain such user activity logs, it is also important to determine for how long these logs are preserved, and under which policies they are accessible to third parties. Naturally, a circumvention tool should log as little information as possible, and users should find a way to know what is logged, for what purpose, and for how long. In this review, we looked for tools that have clear logging policies and correctly inform users about such practices."

CIRCUMVENTIONNOTPRIVACY (URL)

CIRCUMVENTIONNOTPRIVACY: 7.4.2 logging practises: "Naturally, a circumvention tool should log as little information as possible, and users should find a way to know what is logged, for what purpose and for how long."

TOR10THINGS (URL)

TOR10THINGS: 5 Has a decentralized architecture: "In early 2009 Hal Roberts from the Berkman Center ran across a FAQ entry for a circumvention tool that offered to sell its users' clicklogs. I later talked to a different circumvention tool provider who explained that they had all the logs of every request ever made through their system 'because you never know when you might want them.'"

VPNGATE (URL)

VPNGATE: VPN Gate does not do well to protect end user privacy: Section 1: "VPN Gate is a system for bypassing censorship. It is not an anonymizer. Unlike Tor, VPN Gate volunteer servers record packet logs."

UPROXY (URL)

https://www.uproxy.org/faq.html#doesUproxyLogData: "We ask users if they would like to opt-in to report usage metrics. If they do, all metrics are anonymized on the client (before they are submitted) using Rappor. In addition, when users manually use the Submit Feedback tool in the settings menu, they have the option to include logs from their recent uProxy activity. Logs may contain personally identifiable information (PII). PII is never shared outside the uProxy team, and the logs that contain it are retained for at most three months before being deleted. All reports are submitted in a way that makes it hard for an adversary to detect uProxy users."

ULTRASURF (URL)

http://ultrasurf.us/security.html (Data Retention Policy): We log bare minimum information for anti blocking purposes. We only keep logs for maximum of 30 days. http://ultrasurf.us/privacy.html: (1) Web Server Logs.

When you visit our Website, we may track information to administer the site and analyze its usage. Examples of information we may track include:

1. Your Internet protocol address (IP). 2. Number of links you click within the site. 3. Date and time of your visit. 4. Web page you linked to our site from. 5. Pages you viewed on the site.

PSIPHON (URL)

Psiphon is designed to respect user privacy. User statistics are logged in aggregate, but no individual personally identifying information, such as user IP addresses, are retained in Psiphon log files.

LANTERN (URL)

(https://getlantern.org/faq/index.html) Lantern allows you to provide the Lantern team with useful information and analytics that will help us improve the Lantern program. You can change this option in your Lantern settings. If you choose to send Lantern this data we will only use it for improving the Lantern service so that we can continue to offer better service for you and others.

"If you enable this option we use:

Google Analytics with IP Anonymization to store information about your usage. Loggly.com to store information about errors in the Lantern software. When you install Lantern, we ask if you want to contribute this information. You can change this setting at any time in the settings menu."

GTUNNEL (URL)

http://www.internetfreedom.org/privacy_policy.html: "GIF collects the type and version of your web browser and computer operating system, your Internet Protocol ('IP') addresses, Uniform Resource Locators ('URLs') you visit with GIF Services, date and time of these visits, and their referring URLs."

HOTSPOTSHIELD (URL)

(https://www.hotspotshield.com/privacy/) "Automatically Collected Information. When you use our Service, we may automatically record certain information from your web browser by using different types of proprietary technology (such as cookies), which may include your IP address or unique device ID. For example, we may collect your IP address when you commence your use of the Service; we do not, however, store logs associating your IP address with your online activities that take place when you are using of the Service. The automatically-collected information is used by AnchorFree only in the aggregate, in truncated form, or in order to generate a "hashed" or "virtual" IP Address. AnchorFree may use automatically-collected information to identify your general location, improve the Service, or optimize advertisements displayed through the Service." "AnchorFree may use automatically-collected information to monitor the advertisements displayed on the Service, and for purposes of research or analysis. " "AnchorFree may share anonymous or aggregated data with third parties, including its affiliates, advertisers, and other current and prospective business partners. AnchorFree may use anonymous or aggregated data collected for website administration, advertising, and promotional purposes, and may share such information with affiliated and unaffiliated entities."

JAP (URL)

https://anonymous-proxy-servers.net/en/law_enforcement.html: "JonDonym does not make it impossible to uncover individual users, as there is no such thing as a 100% security. However, such a disclosure is by magnitudes more difficult than for other VPN or proxy services, as this would require the cooperation of several states and organizations." https://anonymous-proxy-servers.net/en/faq-jondo.html#1f: "JonDonym mixes usually do not collect user data. Ony a respective legal obligation may force some Mix operators to retain certain connection data."

YOURFREEDOM (URL)

"https://docs.google.com/document/d/1fROW15y2nO8LoE3heU7slgE6lAsWerAK4vCc4DGfqKE/pub#h.w10ibhjoilaw: We do not log what you access on the Internet; German telecommunications laws do not even permit this. We do log the fact that you have used our service, from where you have logged in to our service (if we know it at all! With DNS mode, we usually don't), the lowest 16 bits of IP addresses you have connected to (but not the full address, only the last two numbers!) and statistical data about your usage needed for accounting and quality assurance. This information is typically held on file for only a few days and no longer than 4 weeks. We do not use this information in any other way except for statistical, debugging and accounting purposes and for combating violations of our terms, unless required by legal authorities in Germany. We will never provide any details to private parties or oppressive regimes."

hide user information from end host

Used by Cirripede, Telex, Flash Proxy, SkypeMorph, StegoTorus, OSS, FreeWave, CloudTransport, Freedom House 2011, Circumvention is not privacy, Tor 10 things, Obfs2, Obfs3, Obfs4, Meek, FTE, uProxy, CGIProxy, Ultrasurf, FreeGate, Psiphon, Lantern, GTunnel, Hotspot Shield, JAP, Your Freedom, Green Simurgh

The tool hides information about the user from the end host (destination) to which the user connects to provide some degree of anonymity.

CIRRIPEDE (URL)

Cirripede: Using Cirripede alone provides unobservability from the warden ISP, but it does not provide destination-anonymity from the Cirripede system itself: the service proxy knows the covert destination being targeted by a client.

TELEX (URL)

Mentions but does not satisfy. TELEX: "Unlike Tor, we separate the problem of censorship resistance from that of anonymous communication and concentrate on re- sisting blocking; users who require increased anonymity can use Telex as a gateway to the Tor network."

FLASHPROXY (URL)

Uses Tor for anonymity

SKYPEMORPH (URL)

Uses Tor for anonymity

STEGOTORUS (URL)

StegoTorus preserves Tor’s basic design goals: Unlinkability: The censor should not be able to determine which Internet users communicate with which remote hosts via Tor.

OSS (URL)

Section 7: Eavesdropping by the OSS. Our threat model assumes that the OSS is not colluding with the censor; however it is not necessarily a trusted entity. An OSS can intercept all communications between the user and the cooperating proxy. In this sense the OSS resembles an ISP, Tor entry relay, or other network router that lies on the path between the user and the cooperating proxy. Traffic should be encrypted and authenticated, as the Tor protocol is, to prevent eavesdropping and tampering by the OSS.

FREEWAVE (URL)

A FreeWave server only knows the VoIP IDs of its client, but not their IP addresses since the VoIP connections are being relayed through intermediate VoIP nodes. As a result, unless the VoIP service (e.g., the Google Voice server, or a Skype supernode owned by a FreeWave server) is colluding with the FreeWave server, the FreeWave server will not be able to link VoIP IDs to IP addresses, i.e., the client is anonymous to the server.

CLOUDTRANSPORT (URL)

Table 2 shows what information CloudTransport aims to hide from, respectively, the censoring ISP, cloud storage provider, and CloudTransport bridges. The cloud storage provider is trusted not to reveal to the censors the identities and network locations of its customers who are using CloudTransport. The bridges are trusted not to perform flow correlation (see Section 4.4). In the tunnel mode, the bridges must also be trusted not to reveal the contents and destinations of CloudTransport traffic; this assumption is not required in the proxified modes.

FREEDOMHOUSE_2011 (URL)

FREEDOMHOUSE_2011: Appendix 1, Privacy/Security, Anonymity: "For the purpose of our technical test we have defined anonymity as a crypted channel to relatively anonymous IP being used. In other words, where the access method involves a crypted channel that cannot be easily intercepted and where accessing services is done from a relatively anonymous IP we have assumed that the user can stay relatively anonymous." Appendix 1, Privacy/Security, End-user privacy: "An important aspect of circumvention tools is the ability to hide where the initial request came from. This can be done by creating a crypted channel to a relatively anonymous IP address. The crypted channel here will add to user privacy as communications cannot be easily intercepted."

CIRCUMVENTIONNOTPRIVACY (URL)

CIRCUMVENTIONNOTPRIVACY: 7.4.3 End-user privacy: "An important aspect of a circumvention tools is the ability to hide where the initial request come from." 7.4.4 Location Privacy: "Location privacy is critical when using circumvention tools that can run from mobile devices or laptops connected to 3G mobile networks."

TOR10THINGS (URL)

TOR10THINGS: 6 Keeps you safe from websites too: "Some circumvention tools are safer than others. At one extreme are open proxies. They often pass along the address of the client with their web request, so it's easy for the website to learn exactly where the request is coming from. At the other extreme are tools like Tor that include client-side browser extensions to hide your browser version, language preference, browser window size, time zone, and so on; segregate cookies, history, and cache; and prevent plugins like Flash from leaking information about you."

OBFS2 (URL)

Uses Tor for anonymity

OBFS3 (URL)

Uses Tor for anonymity

OBFS4 (URL)

Uses Tor for anonymity

MEEK (URL)

Uses Tor for anonymity from the final website but the CDN can see the user's IP. Section 9 Discussion: "Even though the censor does not know which client IP addresses are engaging in circumven- tion, the CDN knows. The risk is especially acute when client browses a web site of the same entity that con- trols the intermediate web server, for example brows- ing YouTube while fronting through www.google.com. When this happens, the web service gets to see both entry and exit traffic, and is in a better position to at- tempt to correlate flows by timing and volume, even when the underlying channel is an encrypted protocol like Tor. This phenomenon seems hard to counter, be- cause the front domain needs to be a popular one in order to have high collateral damage, but popular do- mains are also the ones that users tend to want to visit. It is in theory possible to dynamically switch between multiple fronts, so as to avoid the situation where the destination and front are under the same control, at the cost of leaking information about where the user is not going at a given moment."

FTE (URL)

Uses Tor or VPN for anonymity

UPROXY (URL)

https://www.uproxy.org/faq.html#doesUproxyGiveMe: "uProxy is not an anonymity tool; it is useful for concealing your browsing from your ISP, but not for hiding your identity from the sites you visit. A website visited by someone who is getting access via uProxy will see the IP address of the person who is sharing access, and the website may be able to discover the IP address of the uProxy user who is getting access. If you need to hide your identity from the websites you visit, we recommend using the Tor Browser." https://docs.google.com/document/d/1t_30vX7RcrEGuWwcg0Jub-HiNI0Ko3kBOyqXgrQN3Kw/edit?pref=2&pli=1#heading=h.g3bfo82x608w (Technical Design Objectives): "Private: Provide good level of privacy for both the uProxy client and uProxy server."

CGIPROXY (URL)

CGIProxy: In addition, the user is kept as anonymous as possible from any servers. Common uses include: anonymous proxies, other personal uses, VPN-like functionality, and others. It's very simple to install, and very configurable.

ULTRASURF (URL)

ULTRASURF: Hide your IP address from the websites visited

FREEGATE (URL)

http://www.dongtaiwang.com/loc/faq_en.php#ip: When I use Freegate, is my IP exposed? Freegate will hide your real IP when you surf the Internet

PSIPHON (URL)

Psiphon does not provide anonymity and does not provide protection from traffic analysis attacks.

LANTERN (URL)

Lantern is not an anonymity tool. Lantern was built for fast and open Internet access. If you feel you need to be anonymous online (if you are posting something you think could bring legal action against you, for example) we recommend using Tor. Otherwise, Lantern will give you faster access to blocked sites.

GTUNNEL (URL)

"User's IP address is hidden and user's Internet privacy protected. The destination servers see GTunnel server addresses instead." http://www.internetfreedom.org/privacy_policy.html: "GIF Services relays the information between you and the websites you visit, except your IP addresses, which will be replaced with GIF's own IP addresses. Each website has its own privacy policy for the collection and use of your information."

HOTSPOTSHIELD (URL)

Hides IP address from websites (https://www.hotspotshield.com/hide-ip-address/). "Hotspot Shield VPN essentially changes your IP address by replacing it with an IP address belonging to one of our servers. Thus, when you get a free US IP address, you can browse the Internet as a user from the United States or other countries of your choosing with our premium Elite service. Therefore, hackers are not able to locate you or your computer."

JAP (URL)

Introduction: "For these reasons our goal is to develop a practical, usable and blocking resistant system for anonymous web surfing. We strongly believe that an information retrieval system which bypasses censorship has to guarantee the anonymity of its users, because often the consumption of 'forbidden' (censored) information is illegal."

YOURFREEDOM (URL)

"https://docs.google.com/document/d/1fROW15y2nO8LoE3heU7slgE6lAsWerAK4vCc4DGfqKE/pub#h.5lsd0xw8ldtq: It has been said before that Your Freedom is not a full-blown anonymization service. It will however hide your IP address, unless your application communicates it “in-band”. Web server admins will not be able to see where the access comes from initially; they will instead see one of our IP addresses. But we do not take any further anonymization measures: we do not remove tracking cookies, nor do we “wash” the request headers that your web browser sends."

GREENSIMURGH (URL)

GREENSIMURGH hides user IP address

infrastructure cost

Used by Message in a Bottle, SkyF2F, SWEET, CloudTransport, CacheBrowser, Meek

Assesses the cost of infrastructure required to deploy an approach in real world.

MIAB (URL)

Unobtrusive deployment. With our proof-of-concept ap- plication, we have demonstrated that it is possible to run a miab instance on a single modern machine with a fast domestic Internet connection. We recommend a 100Mbps connection, such as the one provided by Comcast in the US, also considering the fluctuations in the speed achievable at rush hours. Therefore, any private citizen with some disposable income, and living in a country with a modern offering for Internet connectivity, can run a miab instance. Moreover, this burden is sustained only by Bob; Alice has minimal requirements to participate in the protocol.

SKYF2F (URL)

Section III.B.: "Low resources cost: Our system should be easily deployed and used in the real world. Unlike other censorship resistant design that need to deploy a number of nodes or need volunteers, our system is built on existing overlay network, users just install a plug-in for Skype client."

SWEET (URL)

Section 5.3 Other properties of SWEET (Ease of deployment)

CLOUDTRANSPORT (URL)

Table 1. Prices charged by cloud storage providers (2013)

CACHEBROWSER (URL)

MISSING_RATIONALE

MEEK (URL)

Table 1. Summary of fronting-capable services. The table does not include other kinds of services, such as shared web hosting, that may work for domain fronting. Bandwidth charges usually vary by geographic region. Many services offer price breaks start- ing around 10 TB/month. Prices are current as of May 2015 and are rounded to the nearest cent.

cost of external services

Used by Message in a Bottle, SkyF2F, SWEET, CloudTransport, CacheBrowser, Meek

Estimates the cost of external services, e.g., cloud services, CDNs, that are required to deploy an approach.

MIAB (URL)

MIAB discusses "unobtusive deployment". "Unobtrusive deployment. With our proof-of-concept ap- plication, we have demonstrated that it is possible to run a miab instance on a single modern machine with a fast domestic Internet connection. We recommend a 100Mbps connection, such as the one provided by Comcast in the US, also considering the fluctuations in the speed achievable at rush hours. Therefore, any private citizen with some disposable income, and living in a country with a modern offering for Internet connectivity, can run a miab instance. Moreover, this burden is sustained only by Bob; Alice has minimal requirements to participate in the protocol."

SKYF2F (URL)

SkyF2F: Section III.B.: "Low resources cost: Our system should be easily deployed and used in the real world. Unlike other censorship resistant design that need to deploy a number of nodes or need volunteers, our system is built on existing overlay network, users just install a plug-in for Skype client.

SWEET (URL)

Ease of deployment: We argue that SWEET can be easily deployed on the Internet and provide service to a wide range of users. First of all, SWEET is low-cost and needs few resources for deployment. It can be de- ployed using a single server that runs a few light-weight processes, including a mail server and a SOCKS proxy. To service in a large scale SWEET server can be de- ployed in a distributed manner by several machines in different geographic locations. Secondly, the operation of SWEET is standalone and does not rely on collabo- ration from other entities, e.g., end-hosts or ISPs. This provides a significant advantage to recent research that relies on collaboration from ISPs [20, 24, 37], or end- hosts [9, 18]. In fact, the easy setup and low-resources of SWEET’s deployment allows it to be implemented by individuals with different levels of technical exper- tise.

CLOUDTRANSPORT (URL)

Table 1. Prices charged by cloud storage providers (2013)

CACHEBROWSER (URL)

Cachebrowser: Minimal expenses to third-parties: Proxy-based cir- cumvention systems rely on either third-parties (e.g., volun- teer Tor relays) or end-users (e.g., paid VPN services and Anonymizer) to pay the monetary expenses of running cir- cumvention proxies. In a publisher-centric approach, how- ever, each content publisher pays the expenses for having its own content un-censored. In CacheBrowser, in particu- lar, the price is indirectly paid by content publishers who host their content on commercial CDN systems.

MEEK (URL)

Table 1. Summary of fronting-capable services. The table does not include other kinds of services, such as shared web hosting, that may work for domain fronting. Bandwidth charges usually vary by geographic region. Many services offer price breaks start- ing around 10 TB/month. Prices are current as of May 2015 and are rounded to the nearest cent.

network performance

Used by Infranet, Message in a Bottle, SkyF2F, Collage, Cirripede, Telex, CensorSpoofer, Flash Proxy, SkypeMorph, StegoTorus, OSS, Marionette, FreeWave, SWEET, Facade, Facet, TapDance, CloudTransport, Bit-smuggler, Castle, Rook, CacheBrowser, Rebound, Freedom House 2011, Circumvention is not privacy, Berkman 2011, Tor 10 things, ScrambleSuit, Meek, FTE, VPN Gate, uProxy, Your Freedom, GoHop

Assesses the system's performance in terms of goodput, latency and overhead.

INFRANET (URL)

Section 7 (Performance Evaluation)

MIAB (URL)

Section 5.1, Performance

SKYF2F (URL)

Section IV.B, Design Goals: "Performance: we seek to achieve acceptable bandwidth for web browsing experiences."

COLLAGE (URL)

Section 5, Performance Evaluation

CIRRIPEDE (URL)

Section 6, Evaluation discusses overheads of the system

TELEX (URL)

Section 8 Evaluation

CENSORSPOOFER (URL)

Section 7.2.1 Performance Evaluation

FLASHPROXY (URL)

Section 4

SKYPEMORPH (URL)

Section 7. EXPERIMENTS, Table 1

STEGOTORUS (URL)

Section 6. PERFORMANCE

OSS (URL)

Section 5.2 Throughput Measurements

MARIONETTE (URL)

Section 7.6 Performance

FREEWAVE (URL)

Section VIII. PROTOTYPE AND EVALUATION

SWEET (URL)

Section 7. EVALUATION

FACADE (URL)

Section 5.2 Performance Evaluation

FACET (URL)

Section 9.5 Performance Analysis

TAPDANCE (URL)

Section 8 Evaluation

CLOUDTRANSPORT (URL)

Section 5 Performance

BITSMUGGLER (URL)

BITSMUGGLER: Problems, Performance.

CASTLE (URL)

CASTLE: 7. Performance Evaluation: "Without any game-specific modifications, Castle offers per- formance amenable to transfer of textual data (e.g., tweets, email, news articles)."

ROOK (URL)

Section 4.1 Bandwidth and Usability

CACHEBROWSER (URL)

MISSING_RATIONALE

REBOUND (URL)

VII: Performance Results.

FREEDOMHOUSE_2011 (URL)

FREEDOMHOUSE_2011 mentions but does not measure: Appendix 1, Performance: "Please note that operating speed was not tested since this will be highly dependent on the countries internet access infrastructure." Appendix II, Part 1, 9: "Which is the *most* important to you in choosing a circumvention tool? Speed." Appendix II, Part 1, 10: "Which is the *second* most important to you in choosing a circumvention tool? Speed." Appendix II, Part II, 16: "Speed: How quickly are the abovementioned tools in accessing blocked sites?"

CIRCUMVENTIONNOTPRIVACY (URL)

CIRCUMVENTIONNOTPRIVACY: 7.5.3 Speed

BERKMAN_2011 (URL)

BERKMAN_2011: Preface: "...and the accuracy and speed of the tool." Summary of Findings: "We evaluated the tools in terms of ... speed..." Results: "We also evaluate the time it takes to load different web pages using each tool compared to not using the tool from the same connection."

TOR10THINGS (URL)

TOR10THINGS: 8 Provides consistently good latency and throughput.

SCRAMBLESUIT (URL)

Section 5.2 Performance

MEEK (URL)

Section 7.3 Performance

FTE (URL)

Section 5. PERFORMANCE

VPNGATE (URL)

Section 6. Experiences

UPROXY (URL)

https://docs.google.com/document/d/1t_30vX7RcrEGuWwcg0Jub-HiNI0Ko3kBOyqXgrQN3Kw/edit#heading=h.rykn8f4tnrsc (Product Overview): "Goals: Useful to users: provide a reasonably fast proxy service that can be widely used." https://docs.google.com/document/d/1t_30vX7RcrEGuWwcg0Jub-HiNI0Ko3kBOyqXgrQN3Kw/edit?pref=2&pli=1#heading=h.g3bfo82x608w (Technical Design Objectives): "Performant: Performance of proxying should not be (orders of magnitude) slower than normal internet connection; ideally it should be faster."

YOURFREEDOM (URL)

"https://www.your-freedom.net/?id=servers discusses load and throughput of the servers."

GOHOP (URL)

Section V. EXPERIMENTS

byte overhead

Used by Infranet, Collage, SkypeMorph, Facade, CloudTransport, ScrambleSuit, Meek, FTE, GoHop

How many extra bytes are introduced by the tool.

INFRANET (URL)

"Figure 13. The overhead of running Infranet on Web server performance."

COLLAGE (URL)

Figure 5(b) shows Per-task Traffic Overhead

SKYPEMORPH (URL)

Table 1, "..the raw data shows that normal bridge tra c con- sistently incurs a 12% overhead, due to overheads incurred by Tor, TLS, and TCP/IP. The overhead of SkypeMorph is a little more than twice that; we incur the extra cost of sending padding when not enough data is available to fill the packet size informed by the tra c shaping oracle."

FACADE (URL)

Entropy of Facade encodings. Using standard entropy calculations, we can quantify the maximum amount of information that Facade can encode in a single HTTP request and still remain deniable. Using the AOL search corpus [8], we calculated that the average length of a search query was 17.83 bytes and that each byte has an entropy of 2.28 bits. Thus, a search query can encode 40.65 bits of information while maintaining deniability.

CLOUDTRANSPORT (URL)

CloudTransport connections have minimal bandwidth overhead per message: 350-400 bytes for S3, 700-800 for CloudFiles, and 375-450 for Google Cloud Storage. HTTPS uploads and downloads have extra 2-3% overhead. When Cirriform polls an S3 account 3 times per second and 5 times per second per connection, its total overhead is 1.2KB + 2KB/connection per second.

SCRAMBLESUIT (URL)

Table 1 shows goodput, transferred KBytes and the total overhead.

MEEK (URL)

Section 5, Deployment on Tor: "The HTTP-based tunneling protocol adds over- head. Each chunk of data gets an HTTP header, then the HTTP request is wrapped in TLS. The HTTP header adds about 160 bytes [59], and TLS adds an- other 50 bytes or so (the exact amount depends on the ciphersuite chosen by the intermediate web service). The worst-case overhead when transporting a single en- crypted Tor cell of about 540 bytes is about 40%, and less when more than one cell is sent at once. We can estimate how much overhead occurs in practice by ex- amining CDN usage reports. In April 2015, the Ama- zon CloudFront backend for meek received 3,231 GB in 389 M requests [21], averaging about 8900 bytes per request. If the overhead per request is 210 bytes, then the average overhead is 210/(8900 − 210) ≈ 2.4%."

FTE (URL)

When used to surf the web, FTE imposes as little as 16% bandwidth overhead

GOHOP (URL)

"The overhead of traffic shaping is about 30%, which is similar to SkypeMorph [14]."

fraction of clients that can utilize the network

Used by Cirripede

Assesses the number of clients (source hosts) in the Internet that would be able to join a system.

CIRRIPEDE (URL)

(copied from Cirripede) Fraction of clients that can utilize the network (Figure 5): First, we studied how many clients (source hosts) in the Internet would be able to join Cirripede, while varying the extensiveness of DR deployment. Figure 5(a) shows this result under the assumption that a random subset of ASes in the Internet act as DRs. We also vary the fraction of overt destinations the client is allowed to probe (in practice, the client may wish to limit the set of overt destinations probed, to reduce potential suspicion).

goodput

Used by SkyF2F, CensorSpoofer, SkypeMorph, StegoTorus, OSS, Marionette, FreeWave, Facet, Castle, Rook, Circumvention is not privacy, Tor 10 things, ScrambleSuit, FTE, VPN Gate, GoHop

The amount of useful throughput the tool enables.

SKYF2F (URL)

SkyF2F: Section III.B.: "Performance: we seek to achieve acceptable bandwidth for web browsing experiences." (Though they never actually measure it.)

CENSORSPOOFER (URL)

Figure 3(a)

SKYPEMORPH (URL)

Table 1: Download speed (goodput), network bandwidth used, and overhead imposed by (a) Normal Tor-over-TCP, (b) SkypeMorph-over-UDP with naive traffic shaping, and (c) SkypeMorph-over-UDP with our enhanced Traffic Morphing

STEGOTORUS (URL)

Stegotorus measures mean goodput by downloading different files of 100 kB to 1 MB size (section 6).

OSS (URL)

5.2 Throughput Measurements

MARIONETTE (URL)

Marionette Section 7: "Downstream and upstream goodput was measured by transmitting a 1MB file, and averaged across 100 trials." Figure 2: "High Throughput."

FREEWAVE (URL)

Table I EVALUATION RESULTS OF FREEWAVE.

FACET (URL)

Table 3: Facet Traffic Break Down (kbit/s)

CASTLE (URL)

CASTLE: 7. Performance Evaluation (tech report): "Since each real-time strategy game has a limit on the number of objects that can be selected for a single command, the data rate obtained by Castle is game dependent. For example, 0 A.D. allows the selection of up to 200 units for a single command, giving us an average of ... 65 bytes per command. On the other hand, Aeons has no limits on the number of units that may be selected for a single command but allows only 435 objects to be placed within a single screen - giving us an average of a 39 bytes per command.... We found that on average, issuing a single command required between 300-350 ms. With no delays between the issue of each command, this allows 3 commands/second."

ROOK (URL)

MISSING_RATIONALE

CIRCUMVENTIONNOTPRIVACY (URL)

CIRCUMVENTIONNOTPRIVACY: 7.5.3 Speed: "The speed of a circumvention tool depends mainly of the amount of bandwidth available across the virtual channel created between the user and the final destination... In our review we were looking for infrastructure that can effectively provision bandwidth to the users.

TOR10THINGS (URL)

TOR10THINGS: 8 Provides consistently good latency and throughput.

SCRAMBLESUIT (URL)

Table 1

FTE (URL)

Section 5. Performance (Goodput)

GOHOP (URL)

GoHop Section V.B.2 "Application Performance".

latency

Used by Message in a Bottle, StegoTorus, FreeWave, SWEET, Facade, Facet, CloudTransport, Bit-smuggler, Circumvention is not privacy, Tor 10 things

Assesses the round-trip time for a request.

MIAB (URL)

MIAB Section 5.4.1: "Therefore, the maximum latency between the publishing of a post with MIAB content and our tweeting is ten minutes (five minutes in the ping server's queue, and another five before we process the post)."

STEGOTORUS (URL)

Stegotorus computes Round-trip latency (ms)

FREEWAVE (URL)

Two important factors are connection bandwidth, and browsing latency.

SWEET (URL)

Sweet measures the end-to-end web browsing latency for the client to reach different web destinations.

FACADE (URL)

Real-time: Latency between the client and server should be at most on the order of seconds.

FACET (URL)

Real-time Delivery. Facet should provide real-time delivery.

CLOUDTRANSPORT (URL)

Cumuliform is noticeably slower because it buffers messages for all connec- tions (as many as 30 when browsing). The variance for CloudTransport is much lower than for Tor+Obfsproxy, mainly because delays in CloudTransport are due to waiting for data to become available in the rendezvous account and S3 has fairly consistent delays in propagating small files used by CloudTransport. Uploading files involves a lot of back-and-forth communication to set up the SCP connection. This puts CloudTransport at a disadvantage because of its per- message overheads, but Fig. 8 shows that it still outperforms Tor+Obfsproxy in all modes but one.

BITSMUGGLER (URL)

BITSMUGGLER: Problems, Performance: "Has poor latency since the stream of data is broken down to fit in bittorrent piece messages. (high throughput on the upside though)"

CIRCUMVENTIONNOTPRIVACY (URL)

CIRCUMVENTIONNOTPRIVACY: 7.5.3 Speed: "You can expect a slower response the bigger the number of intermediaries are used. Forcing the traffic to travel by an alternative path that can include locations spread all around the world has an impact in speed.

TOR10THINGS (URL)

TOR10THINGS: 8 Provides consistently good latency and throughput.

number of requests needed to retrieve data

Used by Infranet, SWEET

Assesses the number of requests that a requester must make to retrieve hidden messages.

INFRANET (URL)

"Figure 12. Number of requests required to retrieve data of various sizes."

SWEET (URL)

7.2 Traffic analysis (Fig. 11. The number of emails sent and received by a SWEET client to get one of the websites from Alexa’s top ten ranking.)

registration performance

Used by Cirripede, Telex, TapDance

Some systems need to apply a special distinguisher or mark to traffic destined for circumvention. For example, end-to-middle proxying systems need to tag flows at the client side and recognize them at the station. This criterion considers the performance of the registration method.

CIRRIPEDE (URL)

Section 6.1 Registration performance: We are interested in the ability of the RS to handle real traffic load. The two main metrics are: (1) the fraction of registration signals that the RS can detect, and (2) the load on the RS (in particular, CPU and memory utilization).

TELEX (URL)

Section 8.2 Tagging performance: We evaluated our tagging implementation by generating and verifying tags in bulk using a single CPU core on the Telex station. We performed ten trials, each of which processed a batch of 100, 000 tags. The mean time to gen- erate a batch was 18.24 seconds with a standard deviation of 0.016 seconds, and the mean time to verify a batch was 9.03 seconds with a standard deviation of 0.0083 seconds. This corresponds to a throughput of approximately 5482 tags generated per second and 11074 tags verified per second. As our TLS throughput experiments show, tag verification appears very unlikely to be a bottleneck in our system.

TAPDANCE (URL)

Section 8 Evaluation (Tag creation and processing)

speed of downloading a webpage

Used by CensorSpoofer, SWEET, TapDance, CloudTransport, CacheBrowser, Rebound, Berkman 2011, ScrambleSuit, FTE, GoHop

Assesses the time required to download a webpage. This is really a combination of goodput and latency, but it is specifically applied so often that we made it its own criterion.

CENSORSPOOFER (URL)

Figure 3

SWEET (URL)

Figure 9: The CDF of the TBT time using SWEET.

TAPDANCE (URL)

TapDance: Section 8: "We used Apache Benchmark in order to issue 5,000 requests through our station proxy, with a concurrency of 100, and compared the performance for fetching a simple page over HTTP and over HTTPS. We also compare fetching the same pages directly from the server and through a single-hop proxy."

CLOUDTRANSPORT (URL)

Fig. 7. Browsing (different usage modes).

CACHEBROWSER (URL)

Cachebrowser: Comparing download time of a CDN content object from the "best" edge server returned by mapping system vs. other edge servers. The alternative edge servers are chosen to be geographically far distanced from the end-user.

REBOUND (URL)

VII: "We use the 'Page load time' plugin to the Google Chrome web browser to measure the time to load web pages from several popular web sites."

BERKMAN_2011 (URL)

BERKMAN_2011: Summary of Findings: "...we logged the time elapsed for downloading the page..." Results: "We also evaluate the time it takes to load different web pages using each tool compared to not using the tool from the same connection."

SCRAMBLESUIT (URL)

Table 1

FTE (URL)

Figure 6: Distribution of webpage (Alexa top fifty) download times (top row) and data transferred (bottom row) for our intersection, manually-generated and automatically-generated FTE formats, compared to using our socks-over-ssh configuration.

GOHOP (URL)

"2) Application Performance: Then we test the performance in application scenario by downloading a 20 MB file2 from an unblocked website. Then we measure the speed of downloading the file, and the results are shown in table III"

throughput

Used by Cirripede, Telex, Flash Proxy, SkypeMorph, Bit-smuggler, Rook, Rebound, ScrambleSuit, VPN Gate, Your Freedom, GoHop

The amount of throughput/bandwidth the tool enables.

CIRRIPEDE (URL)

Section 6.2 Throughput performance: For these experiments, we only measure the performance of downloading data from a web server (thus all clients are pre-registered with Cirripede before each experiment).

TELEX (URL)

Figure 4: Client Request Throughput: We measured the rate at which two client machines could complete HTTP requests for a 1 kB page over a laboratory network, using either TLS or our Telex prototype. The prototype’s performance was competitive with that of unmodified TLS.

FLASHPROXY (URL)

Section 4.1 Throughput

SKYPEMORPH (URL)

Table 1: Download speed (goodput), network bandwidth used, and overhead imposed by (a) Normal Tor-over-TCP, (b) SkypeMorph-over-UDP with naive traffic shaping, and (c) SkypeMorph-over-UDP with our enhanced Traffic Morphing

BITSMUGGLER (URL)

BITSMUGGLER: Problems, Performance: "Has poor latency since the stream of data is broken down to fit in bittorrent piece messages. (high throughput on the upside though)"

ROOK (URL)

"Section 4.1 Bandwidth and Usability: Our implementation of Rook for Team Fortress 2 currently operates at 34 bits/second from game client to game server, and 26 bits/second from game server to game client. This is relatively low but still useful for the real- time chat messaging that is the target of this system."

REBOUND (URL)

VII: "Table I shows typical transfer rates for 1 megabyte transfers from the disallowed host to the client."

SCRAMBLESUIT (URL)

Throughput is goodput+overhead, the paper shows both.

VPNGATE (URL)

Figure 10 shows the TCP bandwidth between each VPN server and our speed test server in Japan. More than 50% of the VPN servers had bandwidth of 5Mbps or faster. We estimated the total available bandwidth as 70Gbps. This is much larger than the used bandwidth of 1.6Gbps shown in Figure 7.

YOURFREEDOM (URL)

YOURFREEDOM has information about "traffic". https://www.your-freedom.net/142/

GOHOP (URL)

GoHop Section V.B.1 "Throughput Performance".

time overhead

Used by Message in a Bottle, Collage, Telex, Marionette, GoHop

How much extra time it takes to use the tool.

MIAB (URL)

Section 5.1, Performance: "On average, it takes 0.56 seconds per image to embed a message, and 0.02 seconds to recover it. In particular, performing exclusively our steganographic extraction on a 5- minute pings chunk takes, on average, 2m:51s on a Intel-i7 eight- core laptop. Performing exclusively the RSA decryption takes 2m:35s. Fetching all the images from the blogs takes an average of 4m:17s. Since the steganographic test is CPU bound, and the blogs fetching is I/O bound, the two operations can execute simultaneously with an acceptable loss in performance: processing a five-minutes chunk of pings with the full miab, with either scheme, completes under five minutes on average, with a processor load under 90%."

COLLAGE (URL)

Figure 5(c) shows Transfer time, for various network connectivity rates (download/upload)

TELEX (URL)

We also compared the time taken to load the 83 unblocked sites with and without Telex. While this metric was difficult to measure accurately due to varying network conditions, we observed a median overhead of approximately 60%.

MARIONETTE (URL)

Figure 11: Summary of case study formats and time spent blocking on network I/O for both client and server.

GOHOP (URL)

"The overhead of traffic shaping is about 30%, which is similar to SkypeMorph [14]."

openness of design

Used by Infranet, Message in a Bottle, Collage, Telex, Flash Proxy, SkypeMorph, StegoTorus, Dust, OSS, Marionette, Facade, Facet, TapDance, Bit-smuggler, Castle, Rebound, Freedom House 2011, Circumvention is not privacy, Berkman 2011, Tor 10 things, BridgeDB, MessageStreamEncryption, FOE, Obfs2, Obfs3, Obfs4, ScrambleSuit, GoAgent, Meek, FTE, VPN Gate, uProxy, CGIProxy, Psiphon, Lantern, JAP, GoHop

Assesses whether the source code available (client and server) and whether the design public or relies on security through obscurity.

INFRANET (URL)

Source code is available \\url{http://nms.csail.mit.edu/infranet/\\#research}

MIAB (URL)

Open-source (http://www.message-in-a-bottle.us/)

COLLAGE (URL)

Source code available (http://noise-lab.net/projects/old-projects/collage/)

TELEX (URL)

Code available, https://github.com/ewust/telex

FLASHPROXY (URL)

Open-source (https://crypto.stanford.edu/flashproxy/)

SKYPEMORPH (URL)

Code available (https://crysp.uwaterloo.ca/software/CodeTalkerTunnel.html)

STEGOTORUS (URL)

Code available (https://sri-csl.github.io/stegotorus/)

DUST (URL)

Code available (https://github.com/blanu/Dust)

OSS (URL)

Code available (https://gitweb.torproject.org/user/dcf/oss.git)

MARIONETTE (URL)

Marionette Introduction: "To encourage adoption and use of Marionette it has been made available as free and open source software."

FACADE (URL)

Code available (https://github.com/ben-jones/facade)

FACET (URL)

Code available (https://github.com/magicle/Facet)

TAPDANCE (URL)

Code available (https://github.com/ewust/tapdance/)

BITSMUGGLER (URL)

Code available (https://github.com/danoctavian/bit-smuggler)

CASTLE (URL)

CASTLE: 9. Conclusions, Code and data release: "To ensure reproducibility of our results and ease comparative evaluation, our implementation of Castle is available at https://github.com/bridgar/Castle-Covert-Channel."

REBOUND (URL)

VI: Implementation.

FREEDOMHOUSE_2011 (URL)

FREEDOMHOUSE_2011 (sorta): JAP: "The trustworthiness of the software is very high due to the reputation of the developers (researchers from well respected universities), and the openness of the code (the source code is publicly available)."

CIRCUMVENTIONNOTPRIVACY (URL)

CIRCUMVENTIONNOTPRIVACY: 7.2.1 Transparency: "A well designed privacy friendly circumvention tool shall not depend on secrecy of its code, protocols, and technology in use."

BERKMAN_2011 (URL)

BERKMAN_2011: Preface: "Additionally, we address concerns about security, usability and openness when appropriate."

TOR10THINGS (URL)

TOR10THINGS: 4 Has an open design. "The first step to transparency and reusability of the tool's software and design is to distribute the software (not just the client-side software, but also the server-side software) under an open source license... Just having an open source license is not enough. Trustworthy circumvention tools need to provide clear, complete documentation for other security experts..."

BRIDGEDB (URL)

Source code available ("https://pythonhosted.org/bridgedb/")

MSE (URL)

https://wiki.vuze.com/w/Message_Stream_Encryption

FOE (URL)

Open source

OBFS2 (URL)

Source code available (https://gitweb.torproject.org/pluggable-transports/obfsproxy.git/tree/doc/obfs2/obfs2-threat-model.txt)

OBFS3 (URL)

Source code available (https://gitweb.torproject.org/pluggable-transports/obfsproxy.git/tree/doc/obfs3/obfs3-threat-model.txt)

OBFS4 (URL)

Source code available (https://gitweb.torproject.org/pluggable-transports/obfs4.git/tree/doc/obfs4-spec.txt)

SCRAMBLESUIT (URL)

Code available (http://www.cs.kau.se/philwint/scramblesuit/)

GOAGENT (URL)

Code available (https://github.com/goagent/goagent)

MEEK (URL)

Code available (https://trac.torproject.org/projects/tor/wiki/doc/meek)

FTE (URL)

Code available (https://fteproxy.org/)

VPNGATE (URL)

Some of the source code is available (http://www.vpngate.net/en/download.aspx)

UPROXY (URL)

Open source (https://github.com/uProxy/uproxy)

CGIPROXY (URL)

Code available (http://www.jmarshall.com/tools/cgiproxy/)

PSIPHON (URL)

Open source (https://psiphon.ca/en/open-source.html)

LANTERN (URL)

Code available (https://github.com/getlantern/lantern)

JAP (URL)

Code available (https://anon.inf.tu-dresden.de/develop/sources_en.html)

GOHOP (URL)

"GoHop is published as an open-source software, and is available to be downloaded freely." Code available (https://github.com/bigeagle/gohop)

open source

Used by Infranet, Message in a Bottle, Collage, Telex, Flash Proxy, SkypeMorph, StegoTorus, Dust, OSS, Marionette, Facade, Facet, TapDance, Bit-smuggler, Castle, Rebound, Freedom House 2011, Circumvention is not privacy, BridgeDB, MessageStreamEncryption, FOE, Obfs2, Obfs3, Obfs4, ScrambleSuit, GoAgent, Meek, FTE, VPN Gate, uProxy, CGIProxy, Psiphon, Lantern, JAP, GoHop

The tool's source code is open.

INFRANET (URL)

Source code is available \\url{http://nms.csail.mit.edu/infranet/\\#research}

MIAB (URL)

Open-source (http://www.message-in-a-bottle.us/)

COLLAGE (URL)

Source code available (http://noise-lab.net/projects/old-projects/collage/)

TELEX (URL)

Code available, https://github.com/ewust/telex

FLASHPROXY (URL)

https://crypto.stanford.edu/flashproxy/#source-code

SKYPEMORPH (URL)

Code available (https://crysp.uwaterloo.ca/software/CodeTalkerTunnel.html)

STEGOTORUS (URL)

Code available (https://sri-csl.github.io/stegotorus/)

DUST (URL)

Code available (https://github.com/blanu/Dust)

OSS (URL)

Code available (https://gitweb.torproject.org/user/dcf/oss.git)

MARIONETTE (URL)

Code available (https://github.com/marionette-tg/marionette)

FACADE (URL)

Code available (https://github.com/ben-jones/facade)

FACET (URL)

Code available (https://github.com/magicle/Facet)

TAPDANCE (URL)

Code available (https://github.com/ewust/tapdance/)

BITSMUGGLER (URL)

BITSMUGGLER does not mention that it has source code available but it does (https://github.com/danoctavian/bit-smuggler)

CASTLE (URL)

The source code of Castle (not including game specific code – e.g., replay decoders, map generators, etc.) is available under the CRAPL license 4 at https://github.com/bridgar/Castle-Covert-Channel.

REBOUND (URL)

VI: "Our implementation of Rebound is available as open source, as part of the Curveball software release, at https://curveball.nct.bbn.com."

FREEDOMHOUSE_2011 (URL)

FREEDOMHOUSE_2011 (sorta): JAP: "The trustworthiness of the software is very high due to the reputation of the developers (researchers from well respected universities), and the openness of the code (the source code is publicly available)."

CIRCUMVENTIONNOTPRIVACY (URL)

CIRCUMVENTIONNOTPRIVACY: 7.2.1 Transparency: "A first and important step towards transparency is the openness of the source code."

BRIDGEDB (URL)

Source code available ("https://pythonhosted.org/bridgedb/")

MSE (URL)

https://wiki.vuze.com/w/Message_Stream_Encryption

FOE (URL)

Source and design available

OBFS2 (URL)

Source code available (https://gitweb.torproject.org/pluggable-transports/obfsproxy.git/tree/doc/obfs2/obfs2-threat-model.txt)

OBFS3 (URL)

Code available (https://gitweb.torproject.org/pluggable-transports/obfsproxy.git/tree/doc/obfs3/obfs3-threat-model.txt)

OBFS4 (URL)

Source code available (https://gitweb.torproject.org/pluggable-transports/obfs4.git/tree/doc/obfs4-spec.txt)

SCRAMBLESUIT (URL)

Code available (http://www.cs.kau.se/philwint/scramblesuit/)

GOAGENT (URL)

Code available (https://github.com/goagent/goagent)

MEEK (URL)

Code available (https://trac.torproject.org/projects/tor/wiki/doc/meek)

FTE (URL)

Code available (https://fteproxy.org/)

VPNGATE (URL)

Some of the source code is available (http://www.vpngate.net/en/download.aspx)

UPROXY (URL)

Code available (https://github.com/uProxy/uproxy)

CGIPROXY (URL)

Code available (http://www.jmarshall.com/tools/cgiproxy/)

PSIPHON (URL)

Code available (https://psiphon.ca/en/open-source.html)

LANTERN (URL)

Code available (https://github.com/getlantern/lantern)

JAP (URL)

Code available (https://anon.inf.tu-dresden.de/develop/sources_en.html)

GOHOP (URL)

Code available (https://github.com/bigeagle/gohop)

resistance to active probing

Used by DEFIANCE, Infranet, Decoy routing, Marionette, Facade, Facet, TapDance, Bit-smuggler, Castle, Rook, Rebound, MessageStreamEncryption, Obfs4, ScrambleSuit, VPN Gate, Psiphon, Lantern

Active probing attacks involve the censor initiating connections to hosts to determine whether the host runs a given circumvention protocol, typically then blocking the host's IP address upon finding that it does. A system is resistant to active probing if an adversary cannot discover the use of the system using this technique.

DEFIANCE (URL)

"Section 1...current protocols are easy to circumvent... by scanning suspect IP addresses or address blocks for service response fingerprints and preemptively blocking them." Section 2.1: "If their traffic analysis leads them to suspect IP addresses or address blocks are being used for censorship bypass, they can scan those network address blocks. These scans might appear from anywhere in the world using contractors or other assets." Section 3.1: "An adversary scanning IP address blocks will not discover the contact and/or bridge relay Gateways. Without the correct sequence and timing, the Gateway does not respond to the contact or returns an innocuous response."

INFRANET (URL)

Section 5.1, "Discovery Attacks: A censor might attempt to discover Infranet requesters or responders by joining Infranet as a requester or a responder."

DECOYROUTING (URL)

A more active adversary can replay or preplay sentinels. If the adversary observes a TLS client hello, it can replay the hello message to the same destination to see whether the response is the expected response or appears to be from a decoy proxy. If the session fails in an unexpected manner but the TCP connection is not closed or reset, then the adversary may suspect that the client is using decoy routing.

MARIONETTE (URL)

MARIONETTE: Introduction: "...the automata admit distinguished error states, thereby providing an explicit mechanism for handling active attacks, such as censor-initiated "probing attacks."

FACADE (URL)

FACADE: 2 Threat Model: "Active identification, on the other hand, includes probing and scanning potential Facade clients and servers; for example, an attacker might actively probe clients or modify traffic to determine how clients respond to error conditions."

FACET (URL)

FACET: Centralized service cannot be discovered, but decentralized can be.

"Even though the censor may proactively probe the service, it can not pinpoint the Facet server IP address, because this address is hidden behind the videoconferencing server.

For decentralized videoconferencing systems such as Skype, the two entities send traffic to each other di- rectly. Consequently, the Facet server ID should only be distributed privately. Otherwise, the censor can pinpoint and block the Facet server IP address by proactively probing the service. "

TAPDANCE (URL)

TAPDANCE: Section 5.2, Packet injection. TAPDANCE: Section 5.2, Active defense.

BITSMUGGLER (URL)

BITSMUGGLER: Why use real bittorrent clients: "A common attack agains Tor bridges used to unmask their dientity is to active probe them see bottom of page here. Using real bittorrent clients means that probing attacks are hard to get right since the proxy (Tor bridge or just a proxy) responds like a normal bittorrent client since it actually runs one."

CASTLE (URL)

CASTLE: 2. Adversary and Threat Model: "The adversary may also take an active approach and probe application endpoints or otherwise interact with the game."

ROOK (URL)

ROOK: Since Rook actually runs the game client and server, an active adversary's probes will be responded to in exactly the same manner as a normal game client and server.

REBOUND (URL)

VIII-A: "An active third party can probe the decoy host to see whether it is still connected to the client, and whether that connection reflects the same state that is observed at the client."

MSE (URL)

MSE: "It is also designed to provide limited protection against ... portscanning by requiring a weak shared secret to complete the handshake."

OBFS4 (URL)

OBFS4: 2. Threat Model: "obfs4 offers protection against active attackers attempting to probe for obfs4 servers. Such machines should not be able to verify the existence of an obfs4 server without obtaining the server's Node ID and identity public key."

SCRAMBLESUIT (URL)

SCRAMBLESUIT: 1. Introduction: "We argue that many circumvention tools--Tor included--suffer from two shortcomings which can easily be exploited by censors. First and most importantly, they are vulnerable to active probing as pioneered by the Great Firewall of China (GFW)..."

VPNGATE (URL)

VPNGATE: 1. Introduction: "The second technique, collaborative spy detection, seeks probing activities from censorship authority's computers, called spies." VPNGATE: 2. Related Work: "Although bridges are not public, censorship authorities can probe and block them.... Tor bridges currently have no blocking resistance against such probing activities."

PSIPHON (URL)

Psiphon DESIGN.pdf "Risks": "Network scanning and/or monitoring: An attacker may scan IP address ranges for web and/or VPN servers that match particular patterns in URL paths, HTML responses, and SSL certificates..."

LANTERN (URL)

Lantern wiki/Threat-Model: "Adversaries are assumed to be able to: Pose as legitimate users on the network in an attempt to learn of as many access points as possible."

respond to probes like something else

Used by Marionette, Facet, TapDance, Bit-smuggler, Rook, Rebound, VPN Gate

When probed, respond similar to how some allowed server would respond so that a censor deciding to block such responses will incur false positives.

MARIONETTE (URL)

MARIONETTE allows for error states that fall back to normal application-layer traffic if a malformed message is received. They discuss mimicking real servers like Apache. MARIONETTE: Introduction: "...the automata admit distinguished error states, thereby providing an explicit mechanism for handling active attacks, such as censor-initiated "probing attacks." Section 7.5.1: " This error transition is traversed if all other potential transitions encounter fatal errors in their action blocks, which occur if an invalid message is received." If the client uses the wrong key (Section 6.1) it also induces an error transition."

FACET (URL)

FACET: Centralized service cannot be discovered, but decentralized can be.

"Even though the censor may proactively probe the service, it can not pinpoint the Facet server IP address, because this address is hidden behind the videoconferencing server.

For decentralized videoconferencing systems such as Skype, the two entities send traffic to each other di- rectly. Consequently, the Facet server ID should only be distributed privately. Otherwise, the censor can pinpoint and block the Facet server IP address by proactively probing the service. "

TAPDANCE (URL)

TapDance resists active probing by increasing the censor's false positive rates. Every time a TapDance station observes an active probe it always responds as if the connection as if it is a proxy connection, even if the connection was not a proxy connection. TAPDANCE: Section 5.2, Active defense: "As an example, consider a censor that injects a stale ACK for suspected proxy connections. Connections that are actually proxy connections will respond with a stale ACK from the server, revealing the connection to the censor. However, the station could detect the original probe, and if it is not a proxied connection, respond with a stale ACK so as to make it appear to the censor as if it were. In this way, for every probe the censor makes, they will detect, sometimes incorrectly, that the connection was a proxy connection."

BITSMUGGLER (URL)

BITSMUGGLER: Why use real bittorrent clients: "A common attack agains Tor bridges used to unmask their dientity is to active probe them see bottom of page here. Using real bittorrent clients means that probing attacks are hard to get right since the proxy (Tor bridge or just a proxy) responds like a normal bittorrent client since it actually runs one."

ROOK (URL)

Rook: "Since Rook actually runs the game client and server, an active adversary's probes will be responded to in exactly the same manner as a normal game client and server."

REBOUND (URL)

VIII-A: "2) Connection State Probes: An active third party can probe the decoy host to see whether it is still connected to the client.... Connection probes will not reveal any discrepancy between the client and decoy host states, because there is no discrepancy to reveal."

VPNGATE (URL)

VPNGATE: 4.2. Innocent IP mixing: "In this technique, we include a number of fake IP addresses, called innocent IP addresses, when VPN Gate List Server returns a list of VPN servers to a user. Innocent IP addresses are chosen from among addresses unrelated to VPN Gate, and they should be addresses of vitally important hosts in the Internet. Examples of good innocent IP addresses include DNS root servers, top-level-domain DNS servers, Windows Update servers, and popular email servers."

use authentication

Used by DEFIANCE, Infranet, Facade, Castle, MessageStreamEncryption, Obfs4, ScrambleSuit, Psiphon

Whether a client needs authentication to connect to the server.

DEFIANCE (URL)

DEFIANCE Section 1: "...current protocols are easy to circumvent... by scanning suspect IP addresses or address blocks for service response fingerprints and preemptively blocking them." Section 2.1: "If their traffic analysis leads them to suspect IP addresses or address blocks are being used for censorship bypass, they can scan those network address blocks. These scans might appear from anywhere in the world using contractors or other assets." Section 3.1: "An adversary scanning IP address blocks will not discover the contact and/or bridge relay Gateways. Without the correct sequence and timing, the Gateway does not respond to the contact or returns an innocuous response." Section 6.4: "These ephemeral Bridge Relays are the 'crown jewel', the goal of Address-Change Signaling. This step requires confidentiality, mutual authentication, and Perfect Forward Secrecy.... Separate identities and secrets prevent impersonation of another user and subsequent breaches of confidentiality. Proofs of security for key exchange require authentication of the ephemeral secret key by both parties."

INFRANET (URL)

Infranet resists active probing by using authentication (similar to obfs4). The censor needs to discover the IP address and public key of an Infranet responder (server). Section 5.1, "Once the client joins, all information exchanged with a responder is specific to that requester. Thus, by joining the network as a requester, the censor gains no additional information other than that which must already have been obtained out-of-band."

FACADE (URL)

Facade Section 5.1 "Active attacks": "Server discovery via session initiation probing. The censor cannot detect Facade servers with active scanning that attempts to initiate Facade sessions because Facade uses a pre-shared secret for authentication.

CASTLE (URL)

Castle resists active probing by using authenticated command channel.

MSE (URL)

MSE: "It is also designed to provide limited protection against ... portscanning by requiring a weak shared secret to complete the handshake."

OBFS4 (URL)

OBFS4 resists active probing by using authentication. An active attacker cannot verify the existence of an obfs4 server without obtaining the server's Node ID and identity public key. The Node ID and identity public key is distributed to a client in an out-of-band mechanism such as BridgeDB. If anybody wihout access the server NODEID and public key tries to communicate with an OBFS4 server it will delay dropping the TCP connection at a random interval to make active probing harder.

SCRAMBLESUIT (URL)

SCRAMBLESUIT: 4.1 Thwarting Active Probing: "We defend against active probing by proposing two mutual authentication mechanisms which rely on a secret which is shared out-of-band."

PSIPHON (URL)

Psiphon DESIGN.pdf "Risks": "Network scanning and/or monitoring: An attacker may scan IP address ranges for web and/or VPN servers that match particular patterns in URL paths, HTML responses, and SSL certificates.... In order to reduce the effectiveness of scanning attacks, the Psiphon servers are configured to return generic data and error messages to non-clients; and to use generic authentication information including self-signed web server certificates."

resistance to blocking

Used by DEFIANCE, Infranet, Message in a Bottle, SkyF2F, Collage, Cirripede, Decoy routing, Telex, CensorSpoofer, Flash Proxy, SkypeMorph, StegoTorus, OSS, Marionette, FreeWave, SWEET, Facade, Facet, TapDance, CloudTransport, Castle, Rook, CacheBrowser, Rebound, Meek, FTE, VPN Gate, uProxy, CGIProxy, Ultrasurf, Psiphon, Lantern, JAP

A system resists blocking if it is hard to block the protocol or IP address of the infrastructure that the approach uses, even given a method of identifying it. For example, if blocking would cause substantial collateral damage.

DEFIANCE (URL)

DEFIANCE: "The DEFIANCE Rendezvous Protocol specifies a series of network interactions and local calculations that ultimately reveal to each DEFIANCE user one of the many addresses of a DEFIANCE Gateway." DEFIANCE Section 1: "Address Pools are provisioned with sufficient quantity, quality, and diversity, frustrating efforts of censors to predict, map, or block the IP addresses." "...current protocols are easy to circumvent... by blocking direct communication with the service itself, by blocking communication with a service discovery component, and by blocking access entry points distributed by service discovery and/or listed in a communal service directory." Section 2.1: "They control access to the Domain Name System (DNS)."

INFRANET (URL)

Section 5.2.1- Infranets success against filtering attacks depends on the pervasiveness of Infranet responders throughout the Web... The wider the deployment of responders on Web servers around the world, the more likely it is that Infranet will succeed.

MIAB (URL)

MIAB Section 5.6: "The Censor might attempt to block all blogs by blacklisting their domain names, or IP addresses. It is essential to MIAB's availability that the blocking set (that is, the set of domains or IP addresses to block) is large, as this makes the maintenance of a blacklist impractical..."

SKYF2F (URL)

Section V.C. "...because Skype relies on a central login server, Skype can still be blocked. However, we think blocking a major service like Google or Skype can do actual economic damage."

COLLAGE (URL)

COLLAGE is resistant to address blocking as it uses popular content hosts used by regular users, e.g., Flickr and it is hard to distinguish Collage content from regular content.

CIRRIPEDE (URL)

Introduction - "By strategically placing deflecting routers in the Internet core, it is possible to make the Cirripede service available to a large user population, we show that using only two tier-1 ASes can deliver Cirripede service to all Internet hosts. In this case, censors cannot block access to Cirripede without blocking a significant fraction of all Internet sites. Cirripede can operate on the existing router infrastructure using off-the-shelf networking tools, with low-cost commodity servers providing the registration and proxy services." Section 7.2, Blocking Circumvention - "A key difference between Cirripede and the above proxybased approaches is that, in our case, the proxy is embedded within the network itself, and blocking individual web sites is ineffective against Cirripede."

DECOYROUTING (URL)

Abstract: "Unlike other circumvention techniques, decoy routing does not require a client to connect to a specific IP address (which is easily blocked) in order to provide circumvention. We show that if it is possible for a client to connect to any unblocked host/service, then decoy routing could be used to connect them to a blocked destination without cooperation from the host. This is accomplished by placing the circumvention service in the network itself - where a single device could proxy traffic between a significant fraction of hosts - instead of at the edge."

TELEX (URL)

Introduction: Today, the most widely-used tools for circumventing Internet censorship take the form of encrypted tunnels and proxies, ... these systems inevitably lead to a cat-and-mouse game in which the censor attempts to discover and block the services’ IP addresses. To overcome this problem, we propose Telex: an end- to-middle proxy with no IP address, located within the network infrastructure. Clients invoke the proxy by using public-key steganography to tag otherwise ordinary TLS sessions destined for uncensored websites.

CENSORSPOOFER (URL)

CensorSpoofer: Section 1: "Our key insight is that it is possible to use IP address spoofing to send data from the proxy to a user without revealing its actual origin."

FLASHPROXY (URL)

Proxy creation. The circumvention system relies on proxies outside the fil- tered region to relay tra c from the client to the desired site. In response the censor can masquerade as legitimate users to discover proxy addresses and promptly block them. One way to combat this Sybil attack is to constantly create new proxies outside the filtered region. As proxies get blocked, new ones take their place.

SKYPEMORPH (URL)

"Hard to block: Since the outputs of SkypeMorph greatly resemble Skype video calls, in order to block SkypeMorph, the censor would need to block Skype calls altogether, which we assume it is unwilling to do."

STEGOTORUS (URL)

Section 2.1 Design Goals, Unblockability: The censor should not be able to block StegoTorus without also blocking a great deal of unrelated traffic.

OSS (URL)

"We show that OSSes are widely available on the Internet and blocking all of them can be difficult and harmful."

MARIONETTE (URL)

Another popular approach is to mimic certain characteristics of popular protocols, such as HTTP or Skype, so that blocking traffic with those characteristics would result in significant collateral damage.

That is, even a tiny false positive rate can generate an overwhelming amount of collateral damage when we consider traffic volumes in the 1 Gbps range.

FREEWAVE (URL)

FREEWAVE calls it "server obfuscation": "...prevents censors from detecting circumvented traffic by matching the destination addresses of traffic." "even if a censor identifies the IP address belonging to a FreeWave server it will not be able to block connections to it since users' connection to that FreeWave server are not direct connections, but are relayed through varying, oblivious VoIP nodes."

SWEET (URL)

SWEET provides several key advantages as compared to the existing circumvention systems. First, since email is an essential service in today’s Internet it is very unlikely that a censorship authority will block all email communications to the outside world, due to different financial and political reasons. This, along the fact that SWEET can be reached through any email service, pro- vides a high degree of availability for SWEET since a censor will need to block all email traffic to the Inter- net in order to block SWEET.

FACADE (URL)

Blacklisting and filtering. A censor could block traffic using IP or port blacklists. Deploying Facade on legitimate web servers would make it difficult for a censor to deploy a blacklist that blocks Facade, presuming that the censor does not want to also block access to the legitimate site and the legitimate site has sufficient cover search traffic.

FACET (URL)

Hard to block without blocking legitimate traffic. "using the best known traffic analysis methods, a censor seeking to block 90% of Facet calls would need to block over 40% of all Skype calls."

TAPDANCE (URL)

Uses network infrastructure

CLOUDTRANSPORT (URL)

"Censorship circumvention systems such as Tor are highly vulnerable to network-level filtering. Because the traffic generated by these systems is disjoint from normal network traffic, it is easy to recog- nize and block, and once the censors identify network servers (e.g., Tor bridges) assisting in circumvention, they can locate all of their users. CloudTransport is a new censorship-resistant communication system that hides users’ network traffic by tunneling it through a cloud storage ser- vice such as Amazon S3."

CASTLE (URL)

CASTLE: 2.1 Network traffic attacks: "IP and port filtering: The censor can observe the IP addresses and port numbers of connections on their network (e.g., using standard tools like Netflow])."

ROOK (URL)

"Introduction: Finally, like VoIP services, games are a widespread and popular form of network use [26]; we believe a censor would face similar dissent to a decision to block all Internet-gaming as they would to blocking all VoIP."

CACHEBROWSER (URL)

MISSING_RATIONALE

REBOUND (URL)

Rebound uses decoy routers.

MEEK (URL)

Uses popular CDNs, blocking these will have high collateral damage

FTE (URL)

The first idea would be for DPI systems to obtain the FTE regex formats and then use them to mark any traffic exactly matching the regex as FTE. For most of the regexes we consider, this would lead to prohibitively high false positive rates (e.g., 100% of HTTP traffic)

Elsewhere this kind of check can be addressed by, for example, developing formats that encode a large number of lengths that are frequently observed in legitimate traffic, and for each length ensuring appropriate length of ciphertexts.

VPNGATE (URL)

"VPN Gate is a public VPN relay service designed to achieve blocking resistance to censorship firewalls such as the Great Firewall (GFW) of China. To achieve such resistance, we organize many volunteers to provide a VPN relay service, with many changing IP addresses."

UPROXY (URL)

https://www.uproxy.org/faq.html#howDoesUproxyCompare: "uProxy is designed to be trustworthy and resistant to blocking. VPN users typically connect to a shared pool of servers that can be identified and blocked. However, uProxy users connect to each other, rather than to common servers, and we conceal the nature of those connections, to make them hard to identify. Also, just like ISPs, VPN services can monitor which websites you visit, and it's often impossible to know what they do with that data. uProxy users only have to trust their friends, not VPN services they don't know."

CGIPROXY (URL)

CGIPROXY sort of satisfy this metric because depends on how many other people used the tool.

ULTRASURF (URL)

http://ultrasurf.us/faq.html: Blocking resillient: Ultrasurf is one of a few circumvention tools that have been battle tested for the past ten years. It has survived many major targeted blocking attempts, and daily heavy blockings

PSIPHON (URL)

Psiphon DESIGN.pdf "Risks": "Network scanning and/or monitoring: They may also monitor traffic flows to identify and block access to IP addresses matching known patterns."

LANTERN (URL)

Lantern wiki/Threat-Model: "Using these tools, adversaries can: Block IP addresses of their choosing; Block specific DNS lookups."

JAP (URL)

Section 6: "We utilize the 'many access points' idea, thus every JAP can act as a forwarder if the direct access to the anonymity service is blocked."

Used by SkyF2F, Collage, CensorSpoofer, SkypeMorph, FreeWave, SWEET, Facade, Facet, Rook

Whether an approach sends traffic using a popular protocol, such as the Skype protocol, to force the censor to either block a popular protocol or identify the circumventing usage of the protocol from normal usage.

SKYF2F (URL)

Another idea is all or nothing which assumes that it is hard to decide based on observing if certain communication data belongs to censored content or not. For example, if all emails are encrypted around the world, then a censor could not scan them by certain words. We investigate how to utilize this idea to design a low-cost system for circumventing Internet censorship. We are aware of the fact that building on top of existing overlays will make the job easier. For example, we could use the Skype overlay network as a messaging transport, a popular plug-in application for Skype client could spread from user to user through the network.

COLLAGE (URL)

The censor might instead block traffic patterns resembling Collage's tasks. From the censor's perspective, doing so may allow legitimate users access to content as long as they do not use one of the many tasks in the task database to retrieve the content. Because tasks in the database are "popular" among innocuous users by deign, blocking a task may also disrupt the activities of legitimate users.

CENSORSPOOFER (URL)

To avoid identification by the censor, CensorSpoofer mimics an encrypted VoIP session to tunnel the downstream data

However, the censor is motivated to allow citizens to normally access basic Internet services, such as IM, Email and VoIP, as blocking such services would lead to economic losses and political pressure. More specifically, we assume the censor is unwilling to interfere with the Internet connections of a user, e.g., an ongoing VoIP conversation, unless it has evidence that a particular connection is being used for bypassing censorship.

SKYPEMORPH (URL)

Uses Skype. "Hard to block: Since the outputs of SkypeMorph greatly resemble Skype video calls, in order to block SkypeMorph, the censor would need to block Skype calls altogether, which we assume it is unwilling to do."

"Skype enables users to make free, unlimited and encrypted voice and video calls over the Internet which has led to its huge popularity [3] and therefore the amount of Skype traffic in today’s Internet is relatively high"

FREEWAVE (URL)

We implement a prototype of FreeWave over the popular VoIP service of Skype

VoIP constitutes an important part of today’s Internet communications [36]–[38]; a recent report [37] shows that about one-third of U.S. businesses use VoIP solutions to reduce their telecommunications expenses, and the report predicts the VoIP penetration to reach 79% by 2013, a 50% increase compared to 2009.

SWEET (URL)

"First, since email is an essential service in today’s Internet it is very unlikely that a censorship authority will block all email communications to the outside world, due to different financial and political reasons. This, along the fact that SWEET can be reached through any email service, provides a high degree of availability for SWEET since a censor will need to block all email traffic to the Internet in order to block SWEET. "

FACADE (URL)

Web service protocols are ubiquitous, so there is significant legitimate traffic for each protocol, making this covert channel more difficult to distinguish.

FACET (URL)

Facet uses popoular video conferencing services: 'Like all proxy steganography systems, it relies on the assumption that the censor is unwilling to indiscriminately block all or most sessions of the cover protocol (Skype) to avoid "collateral damage".'

ROOK (URL)

"Introduction: Finally, like VoIP services, games are a widespread and popular form of network use [26]; we believe a censor would face similar dissent to a decision to block all Internet-gaming as they would to blocking all VoIP."

use many access points

Used by DEFIANCE, Infranet, Message in a Bottle, SkyF2F, Collage, Flash Proxy, OSS, FreeWave, VPN Gate, uProxy, CGIProxy, JAP

Whether an approach uses too many hosts to make it hard for a censor to block all of them.

DEFIANCE (URL)

DEFIANCE: Section 1: "Address Pools are provisioned with sufficient *quantity*, quality, and diversity..." Section 3: "Rather than a few thousand well-known access entry points, tens (or hundreds) of thousands of ephemeral IP addresses are coordinated by Address Pool Operators via central APRAdb servers and regional Gateways."

INFRANET (URL)

"Infranet's success against filtering attacks depends on the pervasiveness of Infranet responders throughout the Web."

"The wider the deployment of responders on Web servers around the world, the more likely it is that Infranet will succeed."

Infranet and CGIPROXY sort of satisfy this metric because depends on how many other people used the tool.

MIAB (URL)

MIAB Section 5.6: "The Censor might attempt to block all blogs by blacklisting their domain names, or IP addresses. It is essential to MIAB's availability that the blocking set (that is, the set of domains or IP addresses to block) is large, as this makes the maintenance of a blacklist impractical..."

SKYF2F (URL)

Rejects, but mentions, the idea: "Many censorship resistant systems have been proposed, which rely on deploying many access points to the censored domain. Therefore they face the problem of discovering available nodes and deploying a large number of nodes. Opposite to many access point approach, we present a system building on existing overlay network,"

COLLAGE (URL)

The sheer number of sites that users could use to exchange messages, and the many different ways they could hide content, makes it difficult for a censor to successfully monitor and block all of them.

Hiding messages in photos, text, and video across a wide range of host sites makes it more difficult for censors to block all possible sources of censored content.

FLASHPROXY (URL)

Flashproxy uses many hosts

OSS (URL)

OSS uses large number of available webhosts.

FREEWAVE (URL)

FreeWave’s availability is tied to the availability of the VoIP service: since the operation of FreeWave is not bound to a specific VoIP provider, in order to block FreeWave a censor needs to block all VoIP connections with the outside world.

VPNGATE (URL)

VPNGATE: To achieve such resistance, we organize many volunteers to provide a VPN relay service, with many changing IP addresses.

UPROXY (URL)

https://www.uproxy.org/faq.html#howDoesUproxyCompare: "uProxy is designed to be trustworthy and resistant to blocking. VPN users typically connect to a shared pool of servers that can be identified and blocked. However, uProxy users connect to each other, rather than to common servers, and we conceal the nature of those connections, to make them hard to identify. Also, just like ISPs, VPN services can monitor which websites you visit, and it's often impossible to know what they do with that data. uProxy users only have to trust their friends, not VPN services they don't know."

CGIPROXY (URL)

Infranet and CGIPROXY sort of satisfy this metric because depends on how many other people used the tool.

JAP (URL)

From Jap paper: "We utilize the "many access points" idea, thus every JAP can act as a forwarder if the direct access to the anonymity service is blocked."

use network infrastructure

Used by Cirripede, Decoy routing, Telex, TapDance, Rebound

Whether an approach uses infrastructure within a network, e.g., router, to avoid address blocking.

CIRRIPEDE (URL)

CIRRIPEDE: To address these issues, we need technologies that provide unobservable communication that circumvent monitoring and censorship technologies. As a first step in that direction, we describe Cirripede, a platform for unobservable communication with Internet destinations. From the perspective of a monitoring entity, a user of Cirripede appears to be making regular network connections, while the user is actually getting connected to destinations that are forbidden by that monitoring entity. To do this, Cirripede requires in-network support, through configuration changes and deployment of overlay nodes outside of the repressive regime's network. We envision these in-network changes may be offered as a service by some participating ISPs, or mandated/supported by non-repressive governments (or NGOs) to encourage the freedom of speech abroad"

DECOYROUTING (URL)

Abstract: "Unlike other circumvention techniques, decoy routing does not require a client to connect to a specific IP address (which is easily blocked) in order to provide circumvention. We show that if it is possible for a client to connect to any unblocked host/service, then decoy routing could be used to connect them to a blocked destination without cooperation from the host. This is accomplished by placing the circumvention service in the network itself - where a single device could proxy traffic between a significant fraction of hosts - instead of at the edge."

TELEX (URL)

TELEX: To overcome this problem, we propose Telex: an end- to-middle proxy with no IP address, located within the network infrastructure. Clients invoke the proxy by using public-key steganography to "tag" otherwise ordinary TLS sessions destined for uncensored websites.

TAPDANCE (URL)

Uses End-to-middle proxying

REBOUND (URL)

I: "The essential difference between decoy routing and conventional proxy services, covert channels, or anonymization tools such as Tor, is that decoy routing uses real connections to allowed (or decoy) hosts and services outside of the filtered area as a conduit for clients within the filtered area to exchange information with disallowed hosts and services outside of it. A third party who wishes to block use of a conventional proxy service only needs to block the addresses of each proxy, but a third party who wishes to block use of decoy routing must block the addresses of all possible decoy hosts -- every host that might be reached by the client via a route that includes a decoy router."

Used by SkyF2F, Facade, CloudTransport, CacheBrowser, Meek, Psiphon, Lantern

Whether an approach uses popular hosts, such as Skype nodes and CDNs, to resist address blocking.

SKYF2F (URL)

Section V.C, Limitations - "... because Skype relies on a central login server, Skype can still be blocked. However, we think blocking a major service like Google or Skype can do actual economic damage."

FACADE (URL)

Blacklisting and filtering. A censor could block traffic using IP or port blacklists. Deploying Facade on legitimate web servers would make it difficult for a censor to deploy a blacklist that blocks Facade, presuming that the censor does not want to also block access to the legitimate site and the legitimate site has sufficient cover search traffic.

CLOUDTRANSPORT (URL)

Cloudtransport: "By contrast, blacklisting the IP addresses of CloudTransport bridges has no effect on CloudTransport, while blacklisting the IP addresses of cloud servers used by CloudTransport disrupts other cloud-based applications using the same servers."

CACHEBROWSER (URL)

Cachebrowser: we show that IP address blocking, a highly-effective technique in blocking regular Internet content, is impracti- cal in blocking CDN content, and that the GFW refrains from IP blocking CDN content due to the potential collat- eral damage.

MEEK (URL)

MEEK use popular CDN.

PSIPHON (URL)

MEEK, lantern, psiphon use popular CDN.

Psiphon DESIGN.pdf "Risks": "Network scanning and/or monitoring: They may also monitor traffic flows to identify and block access to IP addresses matching known patterns."

LANTERN (URL)

MEEK, lantern, psiphon use popular CDN.

Lantern wiki/Threat-Model: "Using these tools, adversaries can: Block IP addresses of their choosing; Block specific DNS lookups."

resistance to insider attacks

Used by CensorSpoofer

Considers whether the system continues to work even if the censor joins the circumvention network and attempts to disrupt it.

CENSORSPOOFER (URL)

Perfect resistance to insider attacks: The censor should not be able to break unblockability or unobservability of CensorSpoofer even if nearly all users are compromised.

resistance to security attacks

Used by DEFIANCE, SkyF2F, Collage, Cirripede, Decoy routing, Telex, SkypeMorph, Dust, OSS, FreeWave, SWEET, Facade, Facet, TapDance, CloudTransport, CacheBrowser, Rebound, Berkman 2011, MessageStreamEncryption, Obfs2, Obfs3, Obfs4, ScrambleSuit, uProxy, Psiphon, Lantern, Hotspot Shield, JAP, Your Freedom, GoHop

This criterion considers different measures that a paper uses to avoid security attacks such as man-in-the-middle, denial of service, malicious proxy, key reuse and replay attack.

DEFIANCE (URL)

DEFIANCE Section 2.1: "They can create counterfeit certificates used for Transport Layer Security (TLS)... By modifying the response, or by replacing the response with entirely false information, they can perform a Monkey-In-The- Middle (MITM) interception."

SKYF2F (URL)

Section V.A, Attacks, "A censor might setup a SkyF2F server and publish it to public, in the hope that some user might connect it." "A censor might host a supernode in the Skype network." "A censor might mount DoS attacks against a target SkyF2F server. By attacking the server to shut it down, reduce its reliability. "

COLLAGE (URL)

Considers malicious hosts. See "Use_innocuous_proxy"

CIRRIPEDE (URL)

Section 4.3 Security analysis: considers "Malicious participating ISPs" and "Honest but curious participating ISPs".

DECOYROUTING (URL)

4.2 Denial of Access to Decoy Routing

TELEX (URL)

Section 6, Security Analysis

SKYPEMORPH (URL)

Employing a steganographic technique, one needs to consider two major factors: the security and efficiency of the method.

DUST (URL)

Section 3, Discussion: Additionally, protection is provided against a number of specific attacks on the protocol. Packet corruption is defeated by use of a MAC. Replay attacks are defeated within a certain time window by use of a timestamp. Brute force decryption of invite packets are defeated by use of salt and a PBKDF.

OSS (URL)

Section 7 Security Analysis

FREEWAVE (URL)

Section VI. SECURITY ANALYSIS

SWEET (URL)

"As another approach for disrupting the operation of SWEET, a censor might try to launch a denial-of-service (DoS) attack on SWEET server. The common tech- niques for DoS attacks, e.g., ICMP flooding and SYN flooding, can be mitigated by protecting the SWEET server using up-to-date firewalls. Alternatively, a ma- licious entity (e.g., a censor) can try to exhaust the SWEET service by sending disruptive traffic through the email communication channel of SWEET. In other words, a censor can play the role of a SWEET client and send Internet traffic through its SWEET client software in a way that breaks or overloads the SWEET server. As an example, the attacker can flood the SWEET’s SOCKS proxy by initiating many incomplete SOCKS connections, or sending SYN floods. A censor could send such attacking requests on behalf of a number of rogue (non-existing) email addresses, to render an email blacklist maintained by SWEET server ineffective in preventing such attacks. As a result, SWEET server should deploy effective mechanisms to protect against possible DoS attacks. One effective mechanism is to require a new user to register her email address with SWEET server prior to her first use of SWEET. Such registration can be performed in an unobservable man- ner by SWEET’s client software through the email com- munication channel (see Section 4.1). Also, to ensure the quality of service for all users, the SWEET server can limit the use of SWEET by putting a cap on the volume of traffic communicated by each registered email address."

FACADE (URL)

Section 5.1 Security Evaluation

FACET (URL)

Section 8. SECURITY ANALYSIS

TAPDANCE (URL)

TAPDANCE is vulnerable to this attack but considers the attack to be expensive for a censor. (5.2 Active Attacks, TLS attacks)

CLOUDTRANSPORT (URL)

4.2 Abusing the CloudTransport bootstrapping protocol 4.3 Attacking a CloudTransport bridge

CACHEBROWSER (URL)

MISSING_RATIONALE

REBOUND (URL)

II: "When the decoy router detects the sentinel in the client connection, it begins the process of determining whether the connection represents a valid decoy routing connection (rather than a spurious match or an attempt by a malicious third party to replay an old connection)." V-A: "public-key systems simplify key distribution, but are susceptible to flooding attacks (a malicious third party can use the public key to create huge numbers of connections and overwhelm the decoy router)."

BERKMAN_2011 (URL)

BERKMAN_2011: Preface: "Additionally, we address concerns about security, usability and openness when appropriate."

MSE (URL)

MSE: It is also designed to provide limited protection against active MITM attacks and portscanning by requiring a weak shared secret to complete the handshake.

OBFS2 (URL)

OBFS2 adds an extra layer of encryption.

OBFS3 (URL)

Adds an extra layer of encryption. obfs3 offers protection against passive Deep Packet Inspection machines that expect the obfs3 protocol. Such machines should not be able to verify the existence of the obfs3 protocol without launching an active attack against its handshake.

OBFS4 (URL)

Similar to obf3

SCRAMBLESUIT (URL)

Section 4.1.2: Foiling Replay.

UPROXY (URL)

https://www.uproxy.org/faq.html#doesUproxyProtect: "uProxy can help protect you from an adversary who is trying to redirect you to a malicious site or otherwise tamper with your traffic. However, uProxy's primary focus is on enabling users to share access to the open Internet."

PSIPHON (URL)

PSIPHON: Instead, any server certificate that is signed by a trusted CA is accepted. We feel that it is possible that our targeted users' computers may have CAs installed that are controlled by their regional censors. That would make it possible for the censor to create a server that will man-in-the-middle or masquerade as a legitimate server.

LANTERN (URL)

MITM: Lantern: https://github.com/getlantern/lantern/wiki/%5Bdevelopers%5D-Questions-and-Answers First, Lantern connects to Google Talk servers over TLS. Lantern embeds the Google Talk signing certificate in its install and only trusts that certificate and a handful of others as trusted certificates, a sort of hard-coded form of certificate pinning. Lantern's connections between peers use self-signed certificates that are exchanged over XMPP through that trusted Google Talk connection. Lantern then only allows connections with those trusted certificates, thwarting any possible man-in-the-middle attack.

HOTSPOTSHIELD (URL)

https://www.hotspotshield.com/benefits-of-vpn/: "Malware protection - Hotspot Shield VPN will alert you if you visit sites that are known to contain malware, and then block the site. It detects and blocks more than 3.5 million malicious, phishing and spam sites from infecting your device."

JAP (URL)

Section 5.3: "The second requirement arises from the fact, that we cannot distinguish a blockee from a blocker. If we would be able to distinguish them we could give information about access points only to blockees. One concept is to let the client solve puzzles. The idea behind this is that a blockee only needs to solve one puzzle while a blocker has to solve all puzzles."

YOURFREEDOM (URL)

"(https://docs.google.com/document/d/1fROW15y2nO8LoE3heU7slgE6lAsWerAK4vCc4DGfqKE/pub#h.5lsd0xw8ldtq): For those looking for privacy, the client offers a high level of encryption using the AES encryption standard, public/private keys, and strong session keys. Details can be found on our web page on https://www.your-freedom.net/?id=encryption (you need to be logged in). Unless you explicitly disable encryption, you’ll be safe from spying eyes. With regards to viruses: we do not have any virus protection mechanisms built into the service and therefore do not provide any virus protection[4]."

GOHOP (URL)

"b) Security: GoHop is still in development, and now it’s im- plementation is not secure enough. We did not implement dynamic session key, So every packet for GoHop shares one master key. If that key was leaked to an attacker, then he can decrypt all GoHop traffic. To implement dynamic key, the session establishment part need to be enhanced. We can adopt D-H key exchange [23] to create a session cipher besides the master cipher, and encrypt packet payload with session cipher and header with master cipher. Thus GoHop’s security is improved."

ignore invalid connections (DoS)

Used by Facet, TapDance, Rebound

Whether an approach ignores invalid connections to avoid denial of service attacks.

FACET (URL)

FACET: To prevent denial-of-service (DoS) attacks, the Facet server is con- figured to not accept strangers' requests. Thus, a potential Facet client is required to register with the server, by sending an "add contact" request to the server's conferencing ID. Only after this request is proved by the Facet server, can the client access to the service. Also, the Facet server enforces usage limits on each regis- tered client ID to further defend against DoS attacks

TAPDANCE (URL)

TapDance: Section 5.2 "Denial of service". "Because ISPs com- monly perform load balancing by flow-based hashing, we can scale our deployment linearly to multiple branches of machines and use standard intrusion detection techniques to ignore packets that do not belong to valid connections or that come from spoofed or blacklisted sources "

REBOUND (URL)

V-A: "In different contexts, both private- and public-key systems have advantages: public-key systems simplify key distribution, but are susceptible to flooding attacks (a malicious third party can use the public key to create huge numbers of connections and overwhelm the decoy router)."

limit service to each user ID (DoS)

Used by SkyF2F, FreeWave, SWEET, Facet, TapDance

Avoid DoS by limiting the amount of service the approach will provide to each user.

SKYF2F (URL)

SkyF2F: Section V.B.: "A censor might mount DoS attacks against a target SkyF2F server. By attacking the server to shut it down, reduce its reliability." "s a public service, this is a real problem. we take a simple measure of limiting each client's connections and bandwidth."

FREEWAVE (URL)

FreeWave: Section XI: "Denial of service." "Different approaches can be taken to limit the effect of such attempts such as the existing sybil defense mechanisms [69], as well as usage limitation enforcement per VoIP caller."

SWEET (URL)

"As another approach for disrupting the operation of SWEET, a censor might try to launch a denial-of-service (DoS) attack on SWEET server. The common tech- niques for DoS attacks, e.g., ICMP flooding and SYN flooding, can be mitigated by protecting the SWEET server using up-to-date firewalls. Alternatively, a ma- licious entity (e.g., a censor) can try to exhaust the SWEET service by sending disruptive traffic through the email communication channel of SWEET. In other words, a censor can play the role of a SWEET client and send Internet traffic through its SWEET client software in a way that breaks or overloads the SWEET server. As an example, the attacker can flood the SWEET’s SOCKS proxy by initiating many incomplete SOCKS connections, or sending SYN floods. A censor could send such attacking requests on behalf of a number of rogue (non-existing) email addresses, to render an email blacklist maintained by SWEET server ineffective in preventing such attacks. As a result, SWEET server should deploy effective mechanisms to protect against possible DoS attacks. One effective mechanism is to require a new user to register her email address with SWEET server prior to her first use of SWEET. Such registration can be performed in an unobservable man- ner by SWEET’s client software through the email com- munication channel (see Section 4.1). Also, to ensure the quality of service for all users, the SWEET server can limit the use of SWEET by putting a cap on the volume of traffic communicated by each registered email address."

FACET (URL)

Facet: Denial of Service Attack. When Facet server ID is distributed publicly, the censor may launch a DoS attack. CAPTCHA [11] can be used to mitigate the censor's enumeration. In addition, the server can enforce usage limitations on each client ID. Besides, puzzles can be used to defeat the Sibil identify attack.

TAPDANCE (URL)

7.3 Connection Limits

use TLS for confidentiality

Used by TapDance, Rebound

Whether an approach uses TLS to provide confidentiality.

TAPDANCE (URL)

While TapDance and previous designs are vulnerable to this attack, there may be external political pressure that discourages a censor from this attack, as it may be disrup- tive to foreign e-commerce in particular. We also argue that as the number of sites using TLS continues to in- crease, this attack becomes more expensive for the censor to perform without impacting performance. Finally, decoy servers that use certificate pinning or other CA-protection mechanisms such as Perspectives [45], CAge [27], or CA country pinning [42], can potentially avoid such attacks.

REBOUND (URL)

V-A: "To authenticate the client and decoy router (and provide confidentiality and data integrity), we use TLS.... using this information in a normal TLS handshake gives the connection the authentication and security attributes of TLS."

use authenticated key exchange (MITM)

Used by Obfs4

Whether an approach uses authenticated key exchange.

OBFS4 (URL)

OBFS4: obfs4 attempts to address these shortcomings by using an authenticated key exchange mechanism based around the Tor Project's ntor handshake [2]. Obfuscation of the Curve25519 public keys transmitted over the wire is accomplished via the Elligator 2 mapping [3].

use block cipher (key reuse)

Used by Telex

Whether an approach uses block cipher to resist key reuse attack.

TELEX (URL)

Section 6 Security Analysis, Stream cipher weakness: TLS supports several stream cipher modes for encrypting data sent over the connec- tion. Normally, the key stream is used once per session, to avoid vulnerability to a reused key attack. However, the Telex station and NotBlocked.com use the same shared secret when sending data to the client, so the same key stream is used to encrypt two different plaintexts. An attacker (possibly different from the censor) with the abil- ity to receive both of the resulting ciphertexts can simply XOR them together to obtain the equivalent of the plain- texts XORed together. To mitigate this issue, Telex sends a TCP RST to NotBlocked.com to quickly stop it from returning data. In addition, our implementation uses a block cipher in CBC mode, for which TLS helps mitigate these issues further by providing for the communication of a random per-record IV.

use certificate pinning (MITM)

Used by TapDance, Lantern

Whether an approach uses certificate pinning to avoid MiTM.

TAPDANCE (URL)

Tapdance: Finally, decoy servers that use certificate pinning or other CA-protection mechanisms such as Perspectives [45], CAge [27], or CA country pinning [42], can potentially avoid such attacks.

LANTERN (URL)

First, Lantern connects to Google Talk servers over TLS. Lantern embeds the Google Talk signing certificate in its install and only trusts that certificate and a handful of others as trusted certificates, a sort of hard-coded form of certificate pinning. Lantern's connections between peers use self-signed certificates that are exchanged over XMPP through that trusted Google Talk connection. Lantern then only allows connections with those trusted certificates, thwarting any possible man-in-the-middle attack.

use client puzzle (DoS)

Used by Telex, SWEET, Facet, CacheBrowser

Require clients to solve a puzzle to prevent DoS.

TELEX (URL)

TELEX: "First, it may attempt to exhaust Telex's bandwidth to proxy to Blocked.com. Second, it may attempt to exhaust a Telex station's tag detection capabilities by creating a large amount of ClientHello messages for the station to check. " "To com- bat the first attack, we can implement a client puzzle [20]," "To combat the second attack, we can implement our tag checking in hardware to increase throughput if necessary."

SWEET (URL)

SWEET: Each client has to register "to prevent denial-of-service (DoS) attacks " "For any new registration request, the registration agent generates and sends an email to the requesting email address (through the email agent) that contains a unique computational challenge"

FACET (URL)

Facet: Denial of Service Attack. When Facet server ID is distributed publicly, the censor may launch a DoS attack. CAPTCHA [11] can be used to mitigate the censor's enumeration. In addition, the server can enforce usage limitations on each client ID. Besides, puzzles can be used to defeat the Sibil identify attack.

CACHEBROWSER (URL)

CACHEBROWSER: Also, a Bootstrapper can use standard DoS defense mechanisms like using computation puzzles as suggested for SWEET

use encryption for confidentiality

Used by DEFIANCE, Collage, Cirripede, SkypeMorph, OSS, CloudTransport, Obfs2, Obfs3, Obfs4, ScrambleSuit, Psiphon, Your Freedom

Whether an approach uses encryption for confidentiality (and/or integrity).

DEFIANCE (URL)

DEFIANCE Section 6.4: "These ephemeral Bridge Relays are the 'crown jewel', the goal of Address-Change Signaling. This step requires confidentiality, mutual authentication, and Perfect Forward Secrecy."

COLLAGE (URL)

Section 6.2, Web Content Proxy: "Once the client knows the publisher’s public key, it sends a message requesting registration. The message identifier is the publisher’s public key and the message payload contains the public key of the client encrypted using the publisher’s public key. This encryption ensures that only the publisher knows the client’s public key. The publisher receives and decrypts the client’s registration request using his own private key."

CIRRIPEDE (URL)

CIRRIPEDE: as the communication of Cirripede is encrypted using a key shared between Cirripede and a client, a par- ticipating ISP will not be able to disclose either the covert destination address or the communicated content.

SKYPEMORPH (URL)

Skype encrypts messages using the AES cipher and uses RSA-based certificates for authentication [2, 11]. Also our experiments showed that Skype utilizes some form of message authentication and would not accept altered messages. Thus an eavesdropper is neither able to access the content of a packet nor can he alter them in such a way that is not detectable.

OSS (URL)

MISSING_RATIONALE

CLOUDTRANSPORT (URL)

CLOUDTRANSPORT: The traffic between the user's CloudTransport client and the bridge is encrypted, preventing the cloud provider from observing traffic contents.

(Cloudtransport has other modes where the traffic is not encrypted)

OBFS2 (URL)

OBFS2/3/4 add an extra layer of encryption.

OBFS3 (URL)

OBFS2/3/4 add an extra layer of encryption.

OBFS4 (URL)

OBFS2/3/4 add an extra layer of encryption.

SCRAMBLESUIT (URL)

4.2 Header Format and Confidentiality [...] HMAC-SHA256-128 which protects the integrity and authenticity of the protocol message.

PSIPHON (URL)

All data that goes through Psiphon is encrypted. This means that your ISP cannot see the content of your Internet traffic: web pages your browse, your chat messages, your uploads, etc.

YOURFREEDOM (URL)

"https://docs.google.com/document/d/1fROW15y2nO8LoE3heU7slgE6lAsWerAK4vCc4DGfqKE/pub#h.5lsd0xw8ldtq: For those looking for privacy, the client offers a high level of encryption using the AES encryption standard, public/private keys, and strong session keys. Details can be found on our web page on https://www.your-freedom.net/?id=encryption (you need to be logged in). Unless you explicitly disable encryption, you’ll be safe from spying eyes. With regards to viruses: we do not have any virus protection mechanisms built into the service and therefore do not provide any virus protection[4]. Please install anti-virus software on your PC or phone; you should do that anyway."

use shared secret (MITM)

Used by MessageStreamEncryption, Psiphon

Whether an approach uses shared secret to resist man-in-the-middle attacks.

MSE (URL)

MSE: "It is also designed to provide limited protection against ... portscanning by requiring a weak shared secret to complete the handshake."

PSIPHON (URL)

MISSING_RATIONALE

use strong third-party service (DoS)

Used by Psiphon, Lantern

A censor would have to overcome not just the circumvention deployment, but some third-party that hosts the deployment.

PSIPHON (URL)

Psiphon DESIGN.pdf "Risks": "Denial of Service Attack: An attacker harnesses an automated script or "botnet" to overload a Psiphon server, resulting in a denial of service for legitimate users." "Since Psiphon servers are hosted by 3rd party providers, we rely on the administrators of these services to ensure that the systems are patched and secured. This may be a faulty assumption."

use timestamp (replay)

Used by Telex, Dust, Facade, TapDance, Obfs4, ScrambleSuit

Whether an approach uses timestamp to resist replay attack.

TELEX (URL)

TELEX: Tag replay is prevented by shared secret. "Tag replay The censor might attempt to use various replay attacks to detect Telex usage. The most basic of these attacks is for the censor to initiate its own Telex connection and reuse the nonce from a suspect connec- tion; if this connection receives Telex service, the censor can conclude that the nonce was tagged and the original connection was a Telex request. Our protocol prevents this by requiring the client to prove to the Telex station that it knows the shared secret associated with the tagged nonce. We achieve this by using the shared secret to derive the key exchange param- eter, as described in Section 5. In particular, consider the encrypted Finished message that terminates the TLS handshake. This message must be encrypted using the freshly negotiated key (or else the TLS server will hang up), so it cannot simply be replayed. Second, the key exchange parameter in use must match the shared secret in the tagged nonce, or the Telex station will not be able to verify the MAC on the Finished message. Together, these requirements imply that the client must know the shared secret."

DUST (URL)

Dust: Section 2 "Packet Format": "The ciphertext includes a timestamp to protect against replay attacks." "The ciphertext includes a timestamp to protect against replay attacks, " "Replay attacks are defeated within a certain time window by use of a timestamp. "

FACADE (URL)

Facade Section 5.1 "Active attacks": "Reordering, replaying, dropping, or disrupting HTTP messages." "Facade uses ScrambleSuit's key exchange and inherits the properties of that authentication mechanism (and is thus robust against preplay and replay attacks).

TAPDANCE (URL)

TapDance: Section 5.2 "Replay attacks". "Replay attacks The censor could capture suspected tags and attempt to replay them in a new connection, to determine if the station responds to the tag. To specifically attack TapDance, the adversary could replay the client's tag-containing request packet after the connection has closed and observe if the station appears to send back a response. We note that both Cirripede and Decoy Routing are also vulnerable to tag replay attacks, although Telex provides some limited protection from them. To protect against duplicated tags, the station could record previous tags and refuse to respond to a repeated tag. To avoid saving all tags, the station could require clients to include a recent timestamp in the encrypted payload1. However, such a defense may enable a denial of ser- vice attack: the censor could delay the true request of a suspected client and send it in a different connection first. In this preplay version of the attack, the censor is also able to observe whether the station responds with the ClientHello message. If it does, the censor will know the suspected request contained a tag."

OBFS4 (URL)

OBFS4 specifies that a timestamp be sent in the client handshake, but doesn't say that its purpose is to prevent replay. Section 4: "E = String representation of the number of hours since the UNIX epoch.... Implementations MUST derive and compare multiple values of MAC_C with 'E = {E - 1, E, E + 1}' to account for clock skew between the client and server."

SCRAMBLESUIT (URL)

ScrambleSuit: Section 4.1.2: "Foiling Replay." "We begin to cache a key kt after a new session ticket was issued and the client confirmed that she correctly received the new ticket by using a special ScrambleSuit message type (see \S 4.2). We introduced the confirmation step because otherwise a censor could preplay a ticket, i.e., intercept it and send it before the client. That way, the server would add it to the replay table and would then reject the client's ticket because it would appear to be replayed. This would allow the censor to invalidate the tickets of clients. With the confirmation step, however, censors are no longer able to launch preplay attacks"

use trustworthy proxy

Used by SkyF2F, Collage, FreeWave, uProxy, Psiphon

By using a trustworthy proxy as the forwarder, the approach avoids the risks of a malicious proxy (as long as the proxy remains trustworthy).

SKYF2F (URL)

SkyF2F: Section V.C.: "...we should consider the security inside Skype sys- tem. It is unknown if the design of the Skype network makes it possible for some nodes to monitor all conversation traffic.... It is likely that the Skype system could be compromised by an exceedingly capable engineer..."

COLLAGE (URL)

COLLAGE uses innocuous content hosts (e.g., Flickr) to transfer contents. It uses public-key encryption, where keys are distributed out-of-band.

FREEWAVE (URL)

FreeWave: Section VI.C.: "Security against VoIP providers." Section XI: "Trusting the VoIP provider." "Security against VoIP providers Except for the centralized VoIP services, the VoIP connec- tions between FreeWave clients and servers are encrypted end-to-end using the keys shared through the VoIP protocol. In the case of a centralized VoIP service, like the Google Voice, FreeWave parties can exchange a key using a key sharing mechanism, like the Diffie-Hellman key exchange [52], over the established FreeWave VoIP. As a result, the VoIP provider will not be able to observe the data being communicated, nor the web destinations being browsed. However, the VoIP service provider might be able to identify VoIP IDs that have made VoIP calls to a FreeWave server. As a result, in order to ensure its unobservability FreeWave needs to use VoIP providers that are not colluding with the censors. Note that FreeWave does not rely on a particular VoIP system and any VoIP provider can be used for its operation."

"Trusting the VoIP provider: A VoIP provider colluding with censors can significantly degrade FreeWave's obfusca- tion promises if FreeWave deploys it. On the bright side, FreeWave can choose from a wide range of VoIP providers. In the case of Skype, in particular, Chinese Skype users get provided with a special implementation of Skype, TOM- Skype, which is suspected [64] to have built-in surveillance functionalities such as text message filtering [65]--[68]."

UPROXY (URL)

https://www.uproxy.org/faq.html#whoKnowsThat: "Note that none of these services ever see what sites or pages you're visiting while using uProxy. Only a user you're getting access through would be in a position to monitor your traffic. So again, only get access through friends you trust to share an Internet connection."

PSIPHON (URL)

Psiphon README: "The Psiphon proxy will know where the user is coming from, what their unencrypted traffic is, and what their destination is, and so the user is necessarily putting trust in the entity running the Psiphon proxy." Psiphon DESIGN.pdf "Risks": "If a server is compromised, the attacker may capture all the traffic passing through the server, obtain historical log information, and observe information that isn't logged such as client IP addresses."

resistance to traffic analysis

Used by DEFIANCE, Identity-based Steganographic Tagging, Decoy routing, Telex, SkypeMorph, StegoTorus, Dust, OSS, Marionette, FreeWave, SWEET, Facet, TapDance, CloudTransport, Bit-smuggler, Castle, Rook, CacheBrowser, Rebound, MessageStreamEncryption, Obfs2, Obfs3, Obfs4, ScrambleSuit, Meek, FTE, uProxy, GTunnel, GoHop

An approach is resistant to traffic analysis if an adversary cannot statically use properties of the traffic generated by the approach to detect it. (Some of the metrics used for this goal can also be used for active probing, but they are not inherently active.)

DEFIANCE (URL)

"Section 2: Traffic Camouflage. Once the client establishes con- tact with a DEFIANCE Bridge, its traffic is camouflaged to prevent the adversary from noticing characteristics of the Tor protocol. While a discussion of specific camou- flage techniques is outside the scope of this paper, its objective is to steganographically transform the encrypted Tor stream into one of many unencrypted protocols"

IBST (URL)

The identity-based steganographic tagging scheme has indistinguishable from random.

DECOYROUTING (URL)

4.1 Detection of Decoy Routing: "For instance, if the hijacked path has different latencies, path lengths, or path MTU than the client to decoy destination path, then analysis may reveal that the flow is suspicious. The decoy router can delay packets and adjust the TTL and MTU of the packets it creates in order to attenuate the risk of detection."

TELEX (URL)

Section 6.1 Passive attacks, Traffic analysis: A sophisticated adversary might attempt to detect a use of Telex by detecting anomalous patterns in connection count, packet size, and timing. ... However, this kind of attack would be well beyond the level of sophistication observed in current censors.

SKYPEMORPH (URL)

Introduction: Tor traffic obfuscation: SkypeMorph disguises communication between the bridge and the client as a Skype video call, which is our target protocol. Protocol obfuscation is greatly needed when facing large-scale censorship mechanisms, such as deep packet inspection.

STEGOTORUS (URL)

"To foil analysis of packet contents, Tor\u2019\ s traffic is steganographed to resemble an innocuous cover protocol, such\ \ as HTTP. To foil analysis at the transport level, the Tor circuit is distributed\ \ over many shorter-lived connections with per-packet characteristics that\ \ mimic cover-protocol traffic. Our evaluation demonstrates that StegoTorus\ \ improves the resilience of Tor to fingerprinting attacks and delivers usable\ \ performance.\n" Section 2.2.2 Limits on the Censor: "Since we anticipate that StegoTorus servers will be aggressively blocked with address filters, we are developing a “rendezvous” mechanism for distributing server address updates to StegoTorus users [45]. In this paper we assume that the user knows contact information for server(s) that have not yet been blocked."

DUST (URL)

The goal of Dust is to provide a transport protocol which cannot be filtered with DPI. To accomplish this goal it must not be vulnerable to fingerprinting using static string matching, packet length comparison, or timing profiling.

OSS (URL)

Section 7 Security Analysis considers Incoming connections, URL pattern, Number of redirects, Number of outgoing connections

MARIONETTE (URL)

Section 7.4 Traffic Analysis Resistance

FREEWAVE (URL)

Section VIII.C. Traffic analysis

SWEET (URL)

Section 7.2 Traffic analysis

FACET (URL)

Section 6. TRAFFIC ANALYSIS

TAPDANCE (URL)

Section 5.1 Passive Attacks

CLOUDTRANSPORT (URL)

4.1 Recognizing CloudTransport network traffic 4.4 Performing large-scale flow correlation

BITSMUGGLER (URL)

https://github.com/danoctavian/bit-smuggler#security Slow path analysis will break the undetectability of bit-smuggler.

Bittorrent file integrity is broken. Since we are tunnelling data through a bittorrent file exchange in real-time we are altering file pieces and breaking the checksums of the file pieces.

To actually detect this in real time you need to do TCP packet reconstruction, fetch the original torrent file, compute hashes and detect a high occurence of hash fails. Sounds like a lot of expensive work.

Sounds totally doable on a slow-path where you've recorded all the packets of a bittorrent connection previously.

CASTLE (URL)

CASTLE: 2. Adversary and Threat Model: "...we consider a network-level censor (e.g., an ISP) who is able to perform analysis over all traffic that it forwards from or to clients within its network." CASTLE: 2.1 Network traffic attacks: "Deep-packet inspection: The censor may look for specific patterns in packet headers and payloads (e.g., application payloads indicative of a specific game). Flow-level analysis: The censor may perform statistical analyses of flow-level characteristics such as inter-packet times and packet sizes)."

ROOK (URL)

Section 4.3.2, "Traffic Shape Analysis."

CACHEBROWSER (URL)

MISSING_RATIONALE

REBOUND (URL)

Rebound's main innovation is that downstream channel comes from the decoy host, eliminating side channels that would be caused by the decoy router sending spoofed packets. VIII-A: "3) Timing Analysis: Rebound defeats timing analysis. Packets from the client to the decoy host are always forwarded immediately to the decoy, so the latency of the responses from the decoy is decoupled from the latency of the responses from the disallowed host. The same requests sent to the decoy host by an ordinary client will result in responses with the same latency." VIII-B: "Although Rebound masks the identity of the disallowed host and the data it sends and receives, Rebound may be detectable via traffic analysis because the traffic it generates (a sequence of long GET requests and error responses) has a characteristic pattern that may be identified even when the channel is encrypted. Although these error responses are encrypted by TLS, they will often differ, to an extent that is observable, from ordinary traffic."

MSE (URL)

Protocol Objectives: MSE is designed to provide a completely random-looking header and (optionally) payload to avoid passive protocol identification and traffic shaping.

OBFS2 (URL)

Currently, most attackers in the category described above implement their censorship by one or more firewalls that looking for protocol signatures and block protocols matching those signatures. These signatures are typically in the form of static strings to be matched or regular expressions to be evaluated, over a packet or TCP flow. obfs2 attempts to counter the above attack by removing content signatures from network traffic. obfs2 encrypts the traffic stream with a stream cipher, which results in the traffic looking uniformly random. obfs2 does not try to protect against non-content protocol fingerprints, like the packet size or timing.

OBFS3 (URL)

Similar to obfs2

OBFS4 (URL)

Similar to obfs2/3

SCRAMBLESUIT (URL)

Section 5.1 Blocking Resistance. It computes the packet length distribution and inter-arrival time and compare the distribution with Tor.

MEEK (URL)

Section 8 Traffic analysis

FTE (URL)

Provides resistance to protocol identification using deep packet inspection (DPI)

UPROXY (URL)

https://docs.google.com/document/d/1t_30vX7RcrEGuWwcg0Jub-HiNI0Ko3kBOyqXgrQN3Kw/edit?pref=2&pli=1#heading=h.g3bfo82x608w (Technical Design Objectives): "Supports obfuscation of proxy connections"

GTUNNEL (URL)

"Traffic content is encrypted with industry-strength algorithms between the user's PC and GTunnel servers so the local filtering/censorship systems will not see the content in clear-text format."

GOHOP (URL)

"III. OBFUSCATION TECHNIQUES IN GOHOP" "In order to thwart statistical traffic analysis, we need to disguise traffic properties as much as possible, so three obfuscation methods were put in to practice: pre-shared key encryption to avoid plaintext, traffic shaping to change packet size, and random port communication to disguise inter-arrival time and hide packet direction"

TLS characteristics

Used by Telex, TapDance

Prevents detection by TLS characteristics, like TLS nonce, clienthello or serverhello messages.

TELEX (URL)

Section 6.1 Passive Attacks: Telex deviates from a normal TLS handshake in the client’s nonce (sent in the ClientHello message) and in the client’s key exchange parameters. In Section 4, we showed that an attacker cannot distinguish a Telex tag from a truly random string with more than a negligible advantage. This means that a client’s tagged nonce (using Telex) is indistinguishable from a normal TLS random nonce. Likewise, the Telex-generated key exchange pa- rameters are the output of a secure PRG; they are not distinguishable from truly random strings as a direct result of the security of the PRG.

TAPDANCE (URL)

TLS handshake TLS allows implementations to sup- port many different extensions and cipher suites. As a result, implementations can be easy to differentiate based on the ciphers and extensions they claim to support in their ClientHello or ServerHello messages. In order to prevent this from being used to locate suspicious imple- mentations, our proxy must blend in to or mimic another popular client TLS implementation. For example, we could support the same set of ciphers and extensions as Chrome for the user’s platform. Currently, our client mimics Chrome’s cipher suite list for Linux.

concurrent connection count

Used by Marionette

They measured the number of simultaneous connections to a server.

MARIONETTE (URL)

Marionette Section 7.4: "Simultaneously active connections" and compared with 10 download of amazon using Firefox 35.

connection length

Used by StegoTorus, Castle, Rook, Meek

Measures the duration of flows (e.g., TCP connections) and evaluates whether the duration can be a distinguisher. (If a connection is suspiciously long, for example.)

STEGOTORUS (URL)

StegoTorus measured the length of connections to the top 10 Alexa sites (Figure 4).

CASTLE (URL)

Castle claims that it's normal for video game connections to last a long time (hours).

ROOK (URL)

Castle and Rook claim that it's normal for video game connections to last a long time (hours).

MEEK (URL)

Section 8.2 Connection lifetime: Meek measured the duration of its tunnel connections and compared them to the duration of ordinary TLS connection.

inter-packet timing

Used by SkypeMorph, Dust, FreeWave, TapDance, Castle, Rook, Obfs2, Obfs3, Obfs4, ScrambleSuit, GoHop

Measures the distribution of packet timing (interpacket times or packet rates) to assess whether it is unlike that of a blocked protocol, or like that of an allowed protocol.

SKYPEMORPH (URL)

SkypeMorph: Section 1.1: "Improved traffic shaping... SkypeMorph extends the previous work to fully reproduce the characteristics of Skype calls." Section 5.2: "Traffic Shaping. The modification is done on the packet sizes and inter-arrival times of consecutive packets." Section 7: "Experiments. ...the Kolmogorov-Smirnov test for both the packet sizes and inter-packet delays shows no statistically signicant difference." Appendix of extended TR at http://cacr.uwaterloo.ca/techreports/2012/cacr2012-08.pdf considers higher-order statistics.

DUST (URL)

Section 3, Discussion: "By allow for a full conversation to be transmitted in a single UDP or TCP packet, timing attacks are defeated in the case of sufficiently small messages."

FREEWAVE (URL)

FreeWave: Section VIII.C., "Traffic analysis": "The two traffic patterns that may be used for traffic analysis in this case are packet rates and packet sizes." Section IX: "Traffic analysis."

TAPDANCE (URL)

TapDance: Section 5.1: "Packet timing and length." Although they don't make concrete measurements, they say that normal traffic to a decoy host may have a different distribution, but it's hard to test in practice.

CASTLE (URL)

We find that packet sizes and inter-packet times of Castle's traffic deviate from those of regular human-driven game play by the same amount that different human player's traffic differ from each other.

Fig. 4

ROOK (URL)

Rook: Section 4.3.2, "Traffic Shape Analysis."

OBFS2 (URL)

obfs2 has it as a non-met criterion: "obfs2 does not try to protect against non-content protocol fingerprints, like the packet size or timing."

OBFS3 (URL)

obfs3 has it (mentions, does not satisfy) by reduction to the threat model of obfs2: "The threat model of obfs3 is identical to the threat model of obfs2, with an added goal...".

OBFS4 (URL)

OBFS4: Section 2: "obfs4 offers protection against some non-content protocol fingerprints, specifically the packet size, and optionally packet timing."

SCRAMBLESUIT (URL)

ScrambleSuit: Section 4.3.2, "Inter-Arrival Time Adaption." Selects from discrete bins of times. Section 5.1, "Blocking Resistance."

GOHOP (URL)

GoHop does it in a slightly weird way: by distributing data across multiple ports on the same server, the interarrival times on any single port are obfuscated. III.C: "second, the inter-arrival time of packet on each port would also distribute randomly..."

lack of server response

Used by TapDance

This criterion is specific to TapDance and the way it sends half-finished HTTP requests. If a TapDance station exists along a path, the request is intercepted and a response comes back immediately. If there is no TapDance station, then no response ever comes (or perhaps comes only after a long timeout).

TAPDANCE (URL)

Lack of server response If the TapDance station fails to detect a client’s flow, it will not respond to the client. This may appear suspicious to a censor, as the client sends a request, but there is no response at the application level from the server. To address the last issue, probing clients could send complete requests and tag their requests with a secret nonce.

matching allowed n-gram distribution

Used by Facet, Rook

Considers the distribution of consecutive strings of symbols, for example bytes. This includes 1-grams (e.g., distribution of single byte values).

FACET (URL)

Facet: Their packet analysis classifier uses n-gram of packets as a feature. The $\chi^2$ classifier takes the packet length as input, and adopts n-gram as feature extraction, which is a contiguous sequence of n packet lengths from the time series traffic.

ROOK (URL)

Rook tests 1-grams, 2-grams, and 3-grams in Section 4.3.4, "Game-Specific n-gram Analysis." They looked at the values of mutable fields in consecutive packets.

network stack fingerprinting

Used by TapDance, Rebound

Assesses the fingerprintability of the network stack, for example comparing the TCP options of two different hosts. Relevant when one host spoofs packets on behalf of another.

TAPDANCE (URL)

TapDance Section 5.1, TCP/IP protocol fingerprinting: "The adversary could attempt to observe packets coming from potential decoy servers and build profiles for each server, including the set of TCP options supported by the server, IP TTL values, TCP window sizes, and TCP timestamp slope and offset....server mimicry remains difficult to achieve in practice."

REBOUND (URL)

VIII-A: "1) Stack Fingerprinting: IP and TCP implementations (often referred to as 'network stacks') differ in the way that they implement aspects of protocols that are not completely specified, and in practice each implementation has a distinct fingerprint.... Rebound does not need to mimic the network stack of the decoy host, and therefore is immune to stack fingerprint analysis."

number of HTTP requests/responses

Used by Marionette

Measures the total number of HTTP request-response pairs per TCP connection.

MARIONETTE (URL)

Figure 8.b

packet size distribution

Used by SkypeMorph, StegoTorus, Dust, Facet, TapDance, Castle, Rook, MessageStreamEncryption, Obfs2, Obfs3, Obfs4, ScrambleSuit, Meek, Psiphon, GoHop

Measures the distribution of packet lengths to assess wehether it is unlike that of a blocked protocol, or like that of an allowed protocol.

SKYPEMORPH (URL)

SkypeMorph: Section 1.1: "Improved traffic shaping... SkypeMorph extends the previous work to fully reproduce the characteristics of Skype calls." Section 5.2: "Traffic Shaping. The modification is done on the packet sizes and inter-arrival times of consecutive packets." Section 7: "Experiments. ...the Kolmogorov-Smirnov test for both the packet sizes and inter-packet delays shows no statistically signicant difference." Appendix of extended TR at http://cacr.uwaterloo.ca/techreports/2012/cacr2012-08.pdf considers higher-order statistics.

STEGOTORUS (URL)

StegoTorus: Section 5.1: Compared to the characteristic distribution of 586-byte packets of Tor, and to lengths in a CAIDA trace. Use an O(1) exponential average with a threshold.

DUST (URL)

Dust: Section 3 "Discussion": "By randomizing packet length, length matching is defeated."

FACET (URL)

Figure 3: Traffic Analysis: Chat and YouTube videos have different traffic patterns.

TAPDANCE (URL)

TapDance: Section 5.1: "Packet timing and length." Although they don't make concrete measurements, they say that normal traffic to a decoy host may have a different distribution, but it's hard to test in practice.

CASTLE (URL)

We find that packet sizes and inter-packet times of Castle's traffic deviate from those of regular human-driven game play by the same amount that different human player's traffic differ from each other.

Fig. 3

ROOK (URL)

Rook: Section 4.3.2, "Traffic Shape Analysis." "Rook should not be vulnerable to these approaches because it does not alter the timing or length of game packets to embed its information, it only alters individual data- fields within the packet. Furthermore, using Rook does not cause any additional packets to be sent, or packets to be changed in size, by the game server or client, so the traffic shape should be unaffected."

MSE (URL)

To avoid simple length-pattern detections, various paddings have been added to each phase.

OBFS2 (URL)

obfs2 has it as a non-met criterion: "obfs2 does not try to protect against non-content protocol fingerprints, like the packet size or timing."

OBFS3 (URL)

Obfs3 mentions this criterion but does not meet it: "It does not hide data lengths."

OBFS4 (URL)

Obfs4: "obfs4 offers protection against some non-content protocol fingerprints, specifically the packet size, and optionally packet timing." They reduce to ScrambleSuit's algorithm.

SCRAMBLESUIT (URL)

ScrambleSuit: Section 4.3.1, "Packet Length Adaption." Selects from discrete bins of lengths. Section 5.1, "Blocking Resistance."

MEEK (URL)

Meek: Section 8.1 "Packet length distribution."

PSIPHON (URL)

// Random padding to frustrate fingerprinting at https://github.com/Psiphon-Labs/psiphon-tunnel-core/blob/21604eea06ecded3449b0458eb86f50ad3efa34c/psiphon/tunnel.go#L910

GOHOP (URL)

GoHop III: "packet padding: To hide the flow's packet-size property, packet padding is a easy way."

protocol misclassification rate

Used by Marionette, FTE

Assesses the misclassification rate of the protocol classifiers to see how well the tool can evade the classifiers.

MARIONETTE (URL)

Figure 7: Summary of misclassification using existing FTE for- mats for HTTP, SSH, and SMB.

FTE (URL)

Section 4.2: Misclassification evaluation. The misclassification rates for all 12 formats against the 6 classifiers appears in Figure 3. Here (and throughout this section) the rate is calculated as the number of TCP connections labeled as the target protocol by the classifier, divided by the total number of TCP connections generated when using that FTE format.

serial connection count

Used by OSS, Marionette

Counted the number of connections made in a row to a server.

OSS (URL)

OSS strings together the contents of many HTTP requests to one server. Section 7: "Number of outgoing connections... An large number of outgoing connections may be suspicious."

MARIONETTE (URL)

Marionette Section 7.4: "Messages per TCP connection" (which implies "TCP connections per message").

total TCP connection

Used by Marionette

The total number of TCP connections per session does not stick out.

MARIONETTE (URL)

Figure 8.a (Figure 8: A comparison of the aggregate traffic features for ten downloads of amazon.com using Firefox 35, compared to the traffic generated by ten executions of the Marionette model mimicking amazon.com.)

total payload length

Used by Marionette

The total payload length produced by the tool does not stick out.

MARIONETTE (URL)

Figure 8.c

use encryption to resist traffic analysis

Used by Identity-based Steganographic Tagging, SkypeMorph, StegoTorus, Dust, TapDance, MessageStreamEncryption, Obfs2, Obfs3, Obfs4, ScrambleSuit, GTunnel, GoHop

Whether an approach uses encryption to resist traffic analysis.

IBST (URL)

The IBE tag is indistinguishable from random. Page 5: We say that an identity-based steganographic tagging scheme has indistinguishable tags and shared secrets if for every polynomially bounded adversary A, we have that AdvID - TAG(lambda) is negligible.

SKYPEMORPH (URL)

We argue that on an encrypted communication such as those of Skype calls, every message appears to be random (since we expect the encryption scheme to output a randomly distributed bit string), thus exploiting the channel history is not required for cover traffic and we can perform significantly better than the OneBlock stegosystem, Collage, or TranSteg. The only important characteristics of encrypted channels, as suggested by previous works, are packet sizes and inter-arrival times of consecutive packets [12, 29, 20]. Hence, a protocol obfuscation layer only needs to reproduce these features for an encrypted channel.

STEGOTORUS (URL)

MISSING_RATIONALE

DUST (URL)

Section 3 Design: The Dust protocol is designed to protect against an attacker that utilizes Deep Packet Inspection (DPI) to fingerprint protocols for the purpose of blocking or rate limiting connections. In order to establish protocol unobservability, all packets consist entirely of encrypted or random single-use bytes so as to be indistinguishable from each other and random packets.

TAPDANCE (URL)

MISSING_RATIONALE

MSE (URL)

MSE is designed to provide a completely random-looking header and (optionally) payload to avoid passive protocol identification and traffic shaping. When it is used with the stronger encryption mode (RC4) it also provides reasonable security for the encapsulated content against passive eavesdroppers.

OBFS2 (URL)

Currently, most attackers in the category described above implement their censorship by one or more firewalls that looking for protocol signatures and block protocols matching those signatures. These signatures are typically in the form of static strings to be matched or regular expressions to be evaluated, over a packet or TCP flow. obfs2 attempts to counter the above attack by removing content signatures from network traffic. obfs2 encrypts the traffic stream with a stream cipher, which results in the traffic looking uniformly random.

OBFS3 (URL)

Similar to obfs2

OBFS4 (URL)

Similar to obfs2/3

SCRAMBLESUIT (URL)

The paper states "We employ encryption in order to hide the application protocol, the padding as well as ScrambleSuit's header." in Section 4.2. Note that "traffic analysis" has a different meaning from ours in this paper and it does not use encryption for resisting that form of traffic analysis (Section 4.3).

GTUNNEL (URL)

"Traffic content is encrypted with industry-strength algorithms between the user's PC and GTunnel servers so the local filtering/censorship systems will not see the content in clear-text format."

GOHOP (URL)

"III. OBFUSCATION TECHNIQUES IN GOHOP (A. Pre-shared Key Encryption): Another and more important reason is that with the help of a pre-shared key, all data in the packet can be encrypted, including header, payload and even useless padding bytes. This enables true randomness of packet data distribution. In many protocols [18], only payload data is encrypted while packet headers are still in plaintext, this enables the censoring system to identify the protocol with only some packet header information."

use random port

Used by Obfs2, Obfs3, Obfs4, GoHop

Use a random port number for communications.

GOHOP (URL)

C. Random Port

Although we’re not able to know how a real-world censoring system exactly works, according to common sense and some existing traffic analysis projects [19], we can guess that the adversary’s traffic identifying module has a concept of TCP connection or UDP session. That is, if two packets between two hosts has different ports, they are thought to belong to two different traffic flows.

In GoHop, we break this traditional common logic, that GoHop’s packets are transported in many ports randomly.

There’re three major benefits of random port datagrams: first, traditional 5-tuple based session detection was broken, so that flow properties on “direction” would be leaked minimally; second, the inter-arrival time of packet on each port would also distribute randomly; last but not least, if the random range is large enough, for example, 10,000 ports, then the throughput on each port can be quite low, increasing the difficulty to analyze the traffic’s statistical properties.

resistance to traffic manipulation

Used by DEFIANCE, Infranet, Telex, SkypeMorph, Facade, TapDance, Castle, Rook, CacheBrowser, Rebound, Psiphon

Evaluates the system's resistance to modification of packets, or injecting or dropping packets. This criterion is concerned only with manipulation of client-initiated flows.

DEFIANCE (URL)

"Section 2.1 (draft) - By modifying the [DNS] response, or by replacing the response with entirely false information, they can redirect a user to a different service or site than the user intended."

INFRANET (URL)

Section 5.2.2, "Transaction Tampering: For example, the adversary may change fields in HTTP request or response headers (e.g., changing the value of the Date: field), reorder fields within headers, or even remove or add fields. Infranet is resistant to these attacks because the tunnel protocol does not rely on modifications to the HTTP header." "...the Infranet requester must present a unique user identifier with each HTTP request in order to be recognized across multiple HTTP transactions." Section 5.2.3, "Session Tampering: An adversary might attempt to disrupt tunnel communication by interfering with sequences of HTTP requests. ... However, Infranet responders include the name of the served URL in each response stream, thus enabling the requester to detect session corruption and restart the transmission. ... The requester can also defend against these attacks with error correction techniques that recover from the insertion, deletion, and transposition of bits."

TELEX (URL)

Section 6.2 Active attacks, Traffic manipulation: The censor might attempt to modify messages between the client and the Telex station, but Telex inherits defenses against this from TLS.

SKYPEMORPH (URL)

The first 8 bytes are an HMAC-SHA256-64 message authentication code for the remaining bytes in the packet.

FACADE (URL)

Section 5.1 Security Evaluation (Active attacks)

TAPDANCE (URL)

5.2 Active Attacks

CASTLE (URL)

CASTLE: 2. Adversary and Threat Model: "It may also perform manipulations (e.g., dropping packets, injecting packets) of the network traffic via on-path or in-path middleboxes." CASTLE: 2.1 Network traffic attacks, Active manipulations: "In particular, the censor may drop, insert, or delay packets. Additionally, they may also modify the packet contents and headers. The adversary may perform these manipulations to observe the behavior of flow endpoints to distinguish legitimate game traffic from the covert channel. They may also use these actions to block covert connections ( e.g., sending TCP RST packets, or dropping traffic)."

ROOK (URL)

"2.12 Packet Loss Resilience: The intention of Rook is to serve as a reliable commu- nication channel. However, it is using a UDP network protocol built to be robust to missing data rather than re- transmitting lost packets. Therefore, Rook must include its own layer of reliable delivery to prevent either natu- rally poor network conditions or an active adversary from easily disrupting the communications."

CACHEBROWSER (URL)

CacheBrowser: Previous work [22, 24] shows how active attacks, e.g., strategically dropping packets, can be used to identify and block some circumvention systems. Such at- tacks do not generally apply to CacheBrowser's encrypted HTTP traffic, e.g., the dropped packets will be resent at the TCP layer. Nonetheless, the dependencies between multiple HTML objects in a complex webpage (or across multiple webpages) may be used to devise attacks specific to that webpage. We leave a thorough analysis to future work.

REBOUND (URL)

V-A: "To authenticate the client and decoy router (and provide confidentiality and data integrity), we use TLS, with some slight modifications.... Because this field is protected by integrity checks in the TLS protocol, and is used to generate the session keys, this field cannot be modified without making it impossible for the client to establish a TLS connection with a decoy host.... using this information in a normal TLS handshake gives the connection the authentication and security attributes of TLS."

PSIPHON (URL)

MISSING_RATIONALE

limit service to each user ID (DoS)

See above where this metric is listed under another goal.

use TLS for integrity

Used by Telex, Rebound

Whether an approach uses TLS to provide integrity.

TELEX (URL)

Section 6, Traffic manipulation: The censor might attempt to modify messages between the client and the Telex station, but Telex inherits defenses against this from TLS.

REBOUND (URL)

V-A: "To authenticate the client and decoy router (and provide confidentiality and data integrity), we use TLS, with some slight modifications.... Because this field is protected by integrity checks in the TLS protocol, and is used to generate the session keys, this field cannot be modified without making it impossible for the client to establish a TLS connection with a decoy host.... using this information in a normal TLS handshake gives the connection the authentication and security attributes of TLS."

use UDP with reliability

Used by SkypeMorph, Castle, Rook

Whether an approach uses UDP with reliability.

SKYPEMORPH (URL)

Between smclient and smserver, bytes in Tor streams are exchanged in segments by a simple reliable transmission mechanism over encrypted UDP communication, and they are identified by sequence numbers. Reliable transmission is supported by acknowledgments over sequence numbers.

CASTLE (URL)

Section 6 (Active traffic manipulations.): "Packet dropping and delaying. Although most commercial real-time strategy games make use of UDP as a transport, the presence of reliability implemented in the application layer pre- vents any threats from adversaries that drop, or significantly delay packets in transmission. As a result, attacks (e.g., [19]) that result in denial-of-service for Castle users are not possible without also affecting legitimate game players."

ROOK (URL)

"2.12 Packet Loss Resilience: The intention of Rook is to serve as a reliable commu- nication channel. However, it is using a UDP network protocol built to be robust to missing data rather than re- transmitting lost packets. Therefore, Rook must include its own layer of reliable delivery to prevent either natu- rally poor network conditions or an active adversary from easily disrupting the communications."

use authentication

See above where this metric is listed under another goal.

use error correcting codes

Used by Infranet, Facade

Whether an approach uses error correcting codes.

INFRANET (URL)

Section 5.2.3, "Session Tampering: An adversary might attempt to disrupt tunnel communication by interfering with sequences of HTTP requests." "However, Infranet responders include the name of the served URL in each response stream, thus enabling the requester to detect session corruption and restart the transmission." "The requester can also defend against these attacks with error correction techniques that recover from the insertion, deletion, and transposition of bits."

FACADE (URL)

"Reordering, replaying, dropping, or disrupting HTTP messages. A censor could disrupt the communications channel by manipulating the visible HTTP traffic. However,its options for doing so are limited presuming its unwillingness to disrupt legitimate HTTP transactions. Because modifying the order of search terms or the terms themselves would modify the semantic content of a query, we assume that the censor is unwilling to change the search string. Should this become a significant attack from the censor, an erasure code may also offer additional security at the cost of performance"

self promotion

Used by Tor 10 things

Evaluates whether an approach or tool promotes itself in a way that is likely to attract harmful attention (from the media or from the censor, for example).

TOR10THINGS (URL)

TOR10THINGS: 10 Doesn't promote itself as a circumvention tool.

server obfuscation

Used by CensorSpoofer, FreeWave

Keeping the server used as a forwarder by the circumvention network hidden from the censor.

CENSORSPOOFER (URL)

As for the downstream channel, since the proxy's IP (i.e., source IP) is not used in packet routing, we can adopt IP spoofing to conceal the proxy's IP address.

FREEWAVE (URL)

The second obfuscation performed by FreeWave, which is unique to FreeWave, is server obfuscation, which prevents censors from detecting circumvented traffic by matching the destination addresses of traffic. [...] As we describe later in this paper, the way the FreeWave server is connected to the Internet results in getting FreeWave's VoIP traffic relayed by various, oblivious VoIP peers, preventing a censor from blocking/identifying

indirect connection to forwarder

Used by CensorSpoofer, FreeWave

The circumventor's computer connects indirectly to the circumvention network's forwarders through an innocuous server.

CENSORSPOOFER (URL)

Our key insight is that it is possible to use IP address spoofing to send data from the proxy to a user without revealing its actual origin. Such a spoofed channel allows communication in a single direction only; however, we can exploit the asymmetric nature of web-browsing traf- fic, using a low-bandwidth indirect channel, such as stegano- graphic instant messages or Email, to communicate requests from the user to the proxy.

FREEWAVE (URL)

The second obfuscation performed by FreeWave, which is unique to FreeWave, is server obfuscation, which prevents censors from detecting circumvented traffic by matching the destination addresses of traffic. [...] As we describe later in this paper, the way the FreeWave server is connected to the Internet results in getting FreeWave's VoIP traffic relayed by various, oblivious VoIP peers, preventing a censor from blocking/identifying

sustainable network and development

Used by Freedom House 2011, Circumvention is not privacy, Tor 10 things

Whether the system has funds and other resources to continue operating for the long term.

FREEDOMHOUSE_2011 (URL)

FREEDOMHOUSE_2011: Appendix 1, Performance, Purpose built infrastructure and development: "Circumvention tools require long-term funding both in terms of infrastructure (proxy servers, bandwidth) and software development (updates, bug fixing, new features) to keep up with new demands. Resources normally come either from volunteers and donors or from an arrangement which would add profitability to the tool. Either way, where the business model of the tool is geared towards the purpose of circumvention, better long term results ought to be expected, while other tools, currently used to circumvent, may be rendered useless as time goes by. We have therefore assessed whether a tool was built for the purpose of circumvention and created the tools accordingly."

CIRCUMVENTIONNOTPRIVACY (URL)

CIRCUMVENTIONNOTPRIVACY: 7.1.1 Funding of infrastructure and development: "Circumvention tools need long term funding both in terms of infrastructure... and software development..."

TOR10THINGS (URL)

TOR10THINGS: 3 Has a sustainable network and software development strategy. "If you're going to invest the time to figure out how to use a given tool, you want to make sure it's going to be around for a while.

usability

Used by DEFIANCE, SkyF2F, Flash Proxy, SWEET, Facet, Castle, CacheBrowser, Freedom House 2011, Circumvention is not privacy, Berkman 2011, Tor 10 things, MailMyWeb, Meek, uProxy, CGIProxy, Ultrasurf, FreeGate, Psiphon, Lantern, GTunnel, Hotspot Shield, JAP, Your Freedom, Green Simurgh

Assesses the additional effort that the circumvention tool client user must expand to use the system.

DEFIANCE (URL)

"Section 3 - The DEFIANCE rendezvous protocol (RP) lets a user in a censored region of the network receive a small amount of information, leading to the DEFIANCE gateways, from servers outside the censored region. Since a censor may control a non-negligible fraction of our clients, it should be difficult for a client to automatically harvest a large number of entry point addresses. Thus an ideal rendezvous scheme would require human involvement (proof-of-life), machine time (proof-of-work), and artifi- cial delays to discover multiple entry points. There is a fundamental trade-off here between system usability and resilience to harvesting attacks."

SKYF2F (URL)

Section IV.B, Design Goals: "Easy to use: As the Skype clients are widespread over the Internet, user can use our system easily. If a user with restricted internet access (call her Alice) to a censored server, she contacts a user (maybe his friend, call him Bob) with free internet access, Bob serves as a router for Alice and transparently forwards all communication data between Alice and the censored server."

FLASHPROXY (URL)

Section 5.2 Usability

SWEET (URL)

"User convenience: As mentioned before, a recent study [10] surveying the use of circumvention tools in censored countries shows that users give the most pref- erence to the ease of use when choosing a circumvention tool. The use of SWEET is simple and requires few resources from a client. A SWEET client only needs to install the provided client software, that can be ob- tained from out-of-band channels like social networks or downloaded from the Internet. Due to its simple de- sign, an expert user can also develop the client software herself. In addition to SWEET software, the user needs to have an email account with a public email provider, and needs to know the public information related to SWEET, e.g., the email addresses of SWEET. "

FACET (URL)

"No deployment at client side. For Facet clients, there is no need to install any client software (which is often blocked), or to pre-share secrets with the server. This property makes Facet easier to use and maintain, since software updates only need to be applied by servers outside of the censored region."

CASTLE (URL)

Deniability and ease of distribution.

Castle's small core size also makes it easy to distribute through hard to block methods - e.g., via the text body in emails and even through instant messaging services.

CACHEBROWSER (URL)

MISSING_RATIONALE

FREEDOMHOUSE_2011 (URL)

FREEDOMHOUSE_2011: Appendix 1, Usability: subdivided into Price, Availability, Accessibility (portability), GUI, Documentation, Localization, Applications supported. Appendix II, Part 1, 9: "Which is the *most* important to you in choosing a circumvention tool? Ease of use." Appendix II, Part 1, 10: "Which is the *second* most important to you in choosing a circumvention tool? Ease of use." Appendix II, Part II, 11: "Ease of finding: How easy is it to find the abovementioned tools?" Appendix II, Part II, 12: "Ease of operating: how easy is it to work with abovementioned tools?" Appendix II, Part II, 17: "Problems: How often have you encountered operational problems using the abovementioned tools?"

CIRCUMVENTIONNOTPRIVACY (URL)

CIRCUMVENTIONNOTPRIVACY: 7.3 Usability: subdivided into Documentation, Localization, Access to software, Software updates, Operating system, Portability, Applications.

BERKMAN_2011 (URL)

BERKMAN_2011: Preface: "Additionally, we address concerns about security, usability and openness when appropriate." Summary of Findings: "We evaluated the tools in terms of ... accuracy (did they correctly download webpages?)... The popular sites test the usability of the tool for use in routine browsing..."

TOR10THINGS (URL)

TOR10THINGS: 9 Makes it easy to get the software and updates.

MAILMYWEB (URL)

Does not require download/installation

MEEK (URL)

MISSING_RATIONALE

UPROXY (URL)

https://docs.google.com/document/d/1t_30vX7RcrEGuWwcg0Jub-HiNI0Ko3kBOyqXgrQN3Kw/edit#heading=h.rykn8f4tnrsc (Product Overview): "Goals: Useful to users: provide a reasonably fast proxy service that can be widely used." "Strategy: Make it easy to: Setup a proxy server for selected friends to use, and connect to a proxy provided by your friends." https://docs.google.com/document/d/1t_30vX7RcrEGuWwcg0Jub-HiNI0Ko3kBOyqXgrQN3Kw/edit?pref=2&pli=1#heading=h.g3bfo82x608w (Technical Design Objectives): "Usable: Minimize user-effort needed to setup a proxy, and to access a proxy provided by a contact."

CGIPROXY (URL)

Easy installation and small download (http://www.jmarshall.com/tools/cgiproxy/install.html)

ULTRASURF (URL)

http://ultrasurf.us/faq.html: lightweight: ultrasurf is a small program, it is easy to download and share portable: no installation necessary: can be run, e.g. in a cybercafe, off of removable media such as a USB thumbdrive or the SD card used in cameras

FREEGATE (URL)

Freegate is free and requires no installation.

PSIPHON (URL)

Zero Install: Psiphon is delivered to users as a minimal footprint, zero install application that can be downloaded from any webpage, file sharing site or shared by e-mail and passed around on a USB key. We keep the file size small and avoid the overhead of having to install an application.

LANTERN (URL)

Small download, and no installation

GTUNNEL (URL)

"Easy to use user interface, English-Chinese dual language support, automatic recognition of OS language"

HOTSPOTSHIELD (URL)

"Small download, free and easy to use"

JAP (URL)

Section 6.4 Usability of the extended JAP

YOURFREEDOM (URL)

MISSING_RATIONALE

GREENSIMURGH (URL)

Free, small download and easy to install.

application support

Used by Freedom House 2011, Circumvention is not privacy

Assesses the system's usefulness for a wide variety of applications (e.g. web browsing, chat, email).

FREEDOMHOUSE_2011 (URL)

FREEDOMHOUSE_2011: Appendix 1, Usability, Applications supported: "While some tools were designed to allow web-surfing only, many have support for other tools built in, allowing user unrestricted usage of service such as email and instant messaging directly from the client, without the need for specialist settings or other intermediate steps that would make the tool prone to configuration errors. We assessed the number of tools supported without intermediate steps to access the tools access capabilities." Appendix 1, Privacy/Security, Applications: "Most circumvention tools focus mainly on web traffic, but there are also tools that allow the routing of other protocols inside the proxy network. Support for mail, instant messaging (IM), and file transfer protocols makes a tool more flexible. This review searched for tools that effectively support more types of internet applications."

CIRCUMVENTIONNOTPRIVACY (URL)

CIRCUMVENTIONNOTPRIVACY: 7.3.7 Applications: "Most circumvention tools focus mainly on web traffic, but there are also tools that allow route other protocols inside of the proxy network. Support for mail, instant messengering (IM) and file transfer protocols makes a tool more flexible and all round."

availability of documentation

Used by Freedom House 2011, Circumvention is not privacy, Tor 10 things

Assesses the quality of user and developer documentation.

FREEDOMHOUSE_2011 (URL)

FREEDOMHOUSE_2011: Appendix 1, Usability, Documentation: "Documentation should cover at least what the tool does, how the tool works, what the known limitations of the tool are, and why anyone should use it. The number of languages in which it is offered is also considered." Appendix II, Part 1, 9: "Which is the *most* important to you in choosing a circumvention tool? Support, if I have questions or need help." Appendix II, Part 1, 10: "Which is the *second* most important to you in choosing a circumvention tool? Support, if I have questions or need help." Appendix II, Part II, 18: "Solutions: When you have encountered a problem, how easy was it for you to obtain help?" Appendix II, Part II, 19: "Support Validity: How frequently does the help you find come directly from the tool's developers or the tool's network?"

CIRCUMVENTIONNOTPRIVACY (URL)

CIRCUMVENTIONNOTPRIVACY: 7.3.1 Documentation: "No matter how simple and intuitive a circumvention tool is, extra documentation never hurts. Documentation should cover at least: what the tool does, how the tool works, what are the known limitations and why anyone should use it." 7.3.2 Localization: "While official documentation is a must, we are also paying special attention to the existing unofficial documentation including community contributions, discussion forums and mailing lists."

TOR10THINGS (URL)

TOR10THINGS: 4 Has an Open Design: "Trustworthy circumvention tools need to provide clear, complete documentation for other security experts -- not just how it's built but what features and goals its developers aimed for."

clean uninstall

Used by Freedom House 2011, Circumvention is not privacy

Assesses whether the client software leaves traces after being uninstalled.

FREEDOMHOUSE_2011 (URL)

FREEDOMHOUSE_2011: Appendix 1, Privacy/Security, Tool fingerprints and plausible deniability: "We have assessed whether a tool leaves tell-tale signs of its operation or installation on the computer of the user after use and un-installation."

CIRCUMVENTIONNOTPRIVACY (URL)

CIRCUMVENTIONNOTPRIVACY: 7.3.6 Portability: "In our review we were looking for tools that do not leave traces during operation and after being uninstalled."

free/low cost

Used by Freedom House 2011, Berkman 2011, Ultrasurf, FreeGate, Psiphon, Lantern, GTunnel, Hotspot Shield, JAP, Your Freedom, Green Simurgh

Cost in USD to use the system.

FREEDOMHOUSE_2011 (URL)

FREEDOMHOUSE_2011: Appendix 1, Usability, Price: "We have assessed whether the tool is paid, has premium service for a fee, or is generally free to use." Appendix 1, Performance, Start-up: "whether usage can start instantly or requires a burdensome installation and/or payment."

BERKMAN_2011 (URL)

BERKMAN_2011: Discussion: "The fastest tools we analyzed require a substantial financial investment to access.... Free tools that are not supported by ads are not without cost, of course."

ULTRASURF (URL)

http://ultrasurf.us/faq.html: Free: Ultrasurf is free to users

FREEGATE (URL)

http://www.dongtaiwang.com/loc/faq_en.php: What is Freegate, what is it for? Freegate is a free anti-censorship software for secure and fast Internet access.

PSIPHON (URL)

Psiphon is free.

LANTERN (URL)

Lantern is Free

GTUNNEL (URL)

GTUNNEL does not mention low cost as a feature but it is a free download.

HOTSPOTSHIELD (URL)

Has free and non-free versions. Shows advertisement to the users.

JAP (URL)

JAP has both free and non-free version

YOURFREEDOM (URL)

YOURFREEDOM: A rudimentary service is available for free. It will provide a bit more bandwidth than a modem connection and up to 2 hours of usage per day (up to 5 hours per week), and will probably be enough for all casual users -- it's certainly enough to visit blocked web pages and join chats, and if it suits your needs you are welcome to use it as much as you like.

GREENSIMURGH (URL)

Free

has a GUI

Used by Freedom House 2011, GTunnel

Assesses whether the client software has a graphical user interface.

FREEDOMHOUSE_2011 (URL)

FREEDOMHOUSE_2011: Appendix 1, Usability, GUI: "Although preferences towards the look of a tool (GUI stands for Graphical User Interface) may be of little concern to a casual user, it is important that to note that a more transparent GUI will prevent mistakes, and helps users to understand the tool better. We have assessed the GUI for this factor." Appendix 1, Performance, GUI: "the Gui design is not only an indicator of usability but also of performance of a tools design team. We have included the GUI criteria in the performance section to highlight tools where ongoing development and investment in ease of use appears to be taking place."

GTUNNEL (URL)

Not mentioned as a benefit but http://gardennetworks.org/products has screenshots of a GUI.

localization

Used by Freedom House 2011, Circumvention is not privacy, Tor 10 things, uProxy, GTunnel

Assesses whether the software and documentation are localized to relevant languages.

FREEDOMHOUSE_2011 (URL)

FREEDOMHOUSE_2011: Appendix 1, Usability, Localization: "To facilitate worldwide usage, documentation and graphical user interface of the tool should be localized to relevant languages. In our review, we looked for tools with proper multilingual graphical interfaces and extensive documentation. While official documentation is a must, we also payed special attention to the existing unofficial documentation, including community contributions, discussion forums, and mailing lists." Appendix II, Part II, 13: "Ability to function in different languages: How well do the abovementioned tools function in the language that you use the most online?"

CIRCUMVENTIONNOTPRIVACY (URL)

CIRCUMVENTIONNOTPRIVACY: 7.3.2 Localization: "To facilitate worldwide usage, documentation and graphical user interface of the tool should be localized to relevant languages."

TOR10THINGS (URL)

TOR10THINGS: 1 Has a diverse set of users: "Whether a tool is translated into some languages but not others can also direct (or hamper) which users it will attract."

UPROXY (URL)

https://docs.google.com/document/d/1t_30vX7RcrEGuWwcg0Jub-HiNI0Ko3kBOyqXgrQN3Kw/edit?pref=2&pli=1#heading=h.z157kd9m8itg (Localization): "Many parts of the uProxy UI are generic to the platform. We use a custom data-store that can translate to Firefox, Chrome, or another localization environment. More in the uProxy UI Localization doc."

GTUNNEL (URL)

http://gardennetworks.org/products: "Easy to use user interface, English-Chinese dual language support, automatic recognition of OS language".

no installation

See above where this metric is listed under another goal.

no usage limitation

Used by Freedom House 2011, Circumvention is not privacy, Tor 10 things

Assesses whether an approach artificially limits who can use it and for which service.

FREEDOMHOUSE_2011 (URL)

FREEDOMHOUSE_2011: Appendix 1, Usability, Availability: "Some tools are designed to grant access to the circumvention service only from within countries where blocking is highly pervasive, such as China and Iran. Others can be used globally. We have assessed how available tools are, granting higher scores for global or high availability." Appendix II, Part II, 14: "Scope: Of the blocked websites, the abovementioned tools allow you to access?"

CIRCUMVENTIONNOTPRIVACY (URL)

CIRCUMVENTIONNOTPRIVACY: 7.1.2 Accessibility: "Can the tool be used in your country, or is the service only available for users in certain countries?"

TOR10THINGS (URL)

TOR10THINGS: 2 Works in your country: "The next question to consider is whether the tool operator articially restricts which countries can use it."

number of errors per webpage

Used by Berkman 2011

This criterion is specific to link-rewriting web proxies like CGIProxy that actually have to interpret HTML and JavaScript and change links so they point back into the proxy and not to their original location.

BERKMAN_2011 (URL)

BERKMAN_2011: Results: "We calculated errors by specifying a specific text string on target pages and checking to see whether the tool accurately loaded the string."

portability

Used by Freedom House 2011, Circumvention is not privacy, Tor 10 things, GTunnel

Assesses the system's portability to different operating systems and devices.

FREEDOMHOUSE_2011 (URL)

FREEDOMHOUSE_2011: Appendix 1, Performance, Operating system: "Software that is supported on more than one platform covers a wider audience than solutions that can only run on one platform. In our review, we looked for tools that are multi-platform. A tool that also provides the possibility of running on mobile devices would have a clear advantage in this respect. The ability to run privacy-friendly circumventing tools on mobile devices is especially important in countries where 3G data networks are becoming more accessible in terms of price and availability."

CIRCUMVENTIONNOTPRIVACY (URL)

CIRCUMVENTIONNOTPRIVACY: 7.3.5 Operating system: "In our review we were looking for tools that are multi-platform including the possibility to run in Mobile devices."

TOR10THINGS (URL)

TOR10THINGS: 9 Makes it easy to get the software and updates: "First, which operating systems are supported? Psiphon does well here too by not requiring any extra client software. Ultrareach and Freegate are so specialized that they only work on Windows, whereas Tor and its accompanying software can run pretty much everywhere."

GTUNNEL (URL)

http://gardennetworks.org/products: "Runs on Linux through Wine."

small download file

Used by Castle, Freedom House 2011, Circumvention is not privacy, Tor 10 things, MailMyWeb, CGIProxy, Ultrasurf, FreeGate, Psiphon, Lantern, GTunnel, Green Simurgh

The size of the tool's client program file is small.

CASTLE (URL)

Castle’s small code base also makes it easy to distribute via hard to block asynchronous methods

FREEDOMHOUSE_2011 (URL)

FREEDOMHOUSE_2011: Appendix 1, Usability, Accessibility (portability): "As another approach, a small tool can be mailed or transferred via the internet from one user to another, while larger ones might need to be passed on via a portable USB drive."

CIRCUMVENTIONNOTPRIVACY (URL)

CIRCUMVENTIONNOTPRIVACY: 7.3.3 Access to software: "A small tool that can be mailed or transfered via Internet Messengering from one user to another, while larger ones might need to be passed on via a portable USB drive."

TOR10THINGS (URL)

TOR10THINGS: 9 Makes it easy to get the software and updates: "Another approach is a tiny program like Ultrareach or Freegate that you can instant message to your friends."

MAILMYWEB (URL)

No download is required

CGIPROXY (URL)

As of Mar 2016, the size of CGIProxy 2.1.16 is 332 kb.

ULTRASURF (URL)

ULTRASURF, FREEGATE have a small software bundle.

FREEGATE (URL)

ULTRASURF, FREEGATE have a small software bundle.

PSIPHON (URL)

Size of Psiphon is less than 5MB (last checked Mar 2, 2016)

LANTERN (URL)

LANTERN has a small bundle

GTUNNEL (URL)

GTUNNEL does not mention a small download but http://gardennetworks.com/download/GTunnel.zip is only 1.0 MB.

GREENSIMURGH (URL)

Green Simurgh has a small software bundle: "file size is less than a megabyte"

software updates

Used by Circumvention is not privacy, Tor 10 things, GTunnel

Assesses the availability of software updates.

CIRCUMVENTIONNOTPRIVACY (URL)

CIRCUMVENTIONNOTPRIVACY: 7.3.4 Software updates: "In our review we were looking for tools that require very simple or no software updates."

TOR10THINGS (URL)

TOR10THINGS: 9 Makes it easy to get the software and updates.

GTUNNEL (URL)

http://gardennetworks.org/products: "Automatic software upgrade".

usage

Used by Flash Proxy, Circumvention is not privacy, Tor 10 things, ScrambleSuit, Meek, FTE, VPN Gate, JAP, Your Freedom, GoHop

Assesses real world usage of an approach.

FLASHPROXY (URL)

Test deployment (https://trac.torproject.org/projects/tor/wiki/FlashProxyHowto)

CIRCUMVENTIONNOTPRIVACY (URL)

CIRCUMVENTIONNOTPRIVACY: 7.2.3 Track record: "A tool that has been around for several years, and still have a large community of users has probably a good track record of avoiding attempts to stop their service."

TOR10THINGS (URL)

TOR10THINGS: 9 Makes it easy to get the software and updates: "Last, does the tool have a track record for responding to blocking?"

SCRAMBLESUIT (URL)

Deployed with Tor Browser Bundle (https://bridges.torproject.org/bridges?transport=scramblesuit)

MEEK (URL)

Deployed in Tor, Lantern and Psiphon and used by users

FTE (URL)

Deployed on Tor (https://trac.torproject.org/projects/tor/wiki/doc/fte/setup)

VPNGATE (URL)

Already used by users

JAP (URL)

Deployed (https://anonymous-proxy-servers.net/)

YOURFREEDOM (URL)

"https://docs.google.com/document/d/1fROW15y2nO8LoE3heU7slgE6lAsWerAK4vCc4DGfqKE/pub#h.m049q7jaixrc: This point is subject to change frequently. At the time of writing we have 23 servers online, in 9 different countries. All will be able to support basic web surfing or chatting but some will refuse P2P connections (particularly the ones located in the United States) to comply with provider policies. Some can handle more traffic than others. Have a look at the live statistics page at https://www.your-freedom.net/?id=servers; servers that are not in the“p2p” server group are not well suited for P2P applications, servers that are not in the “volume” group are not suitable for large file transfers, and so on – you’ll get the drift. Everyone may use all servers in the “free” group, the others are reserved to paying customers. Some servers may not be available to users connecting from certain countries, or only available to users connecting from some countries. The Your Freedom client will tell you about such restrictions when you connect (“authentication not valid for your country of residence”). If this happens to you, please use another server. We only do this when we need to defend ourselves, i.e. not at all if we can avoid it. Look at the server load too. The higher the number, the more loaded the server. Loads below 40000 are considered low, loads above 125000 are considered high, and very high numbers indicate you’ll likely only get a degraded service. We use a traffic light scheme to quickly indicate the server state. A “green” light indicates that the server is fine and can accept your connection. A “yellow” light would indicate that the server is up and running but currently rather busy, already slightly overloaded or otherwise in trouble (connectivity problems are a possible reason) and probably won’t be able to provide the best service to you – you are still welcome to use it, and the service may still be pretty good. A “red” light indicates that the server is down or otherwise unable to serve you."

GOHOP (URL)

"Ready-to-use implementation: We published GoHop under an open-source license 1, GoHop currently supports Linux operat- ing system, and we have been using it to bypass censorship for several months."

number of unique connections

Used by VPN Gate

Discusses the number unique of IP addresses that connect to the system on a daily basis.

VPNGATE (URL)

Figure 6. Number of daily unique IP addresses for VPN clients.

number of users

Used by Meek, VPN Gate, Your Freedom

The number of users the tool has.

MEEK (URL)

Section 5, 6 and 7 describe deployment on Tor, Lantern and Psiphon

VPNGATE (URL)

Section 6.1. Statistics of users and volunteers

YOURFREEDOM (URL)

YOURFREEDOM specifies the number of users on their page.

test deployment

Used by Flash Proxy, Circumvention is not privacy, Tor 10 things, ScrambleSuit, Meek, FTE, VPN Gate, JAP, GoHop

An approach proposed in an academic paper that is deployed in the real world and used by users.

FLASHPROXY (URL)

https://trac.torproject.org/projects/tor/wiki/FlashProxyHowto

CIRCUMVENTIONNOTPRIVACY (URL)

CIRCUMVENTIONNOTPRIVACY: 7.2.3 Track record: "A tool that has been around for several years, and still have a large community of users has probably a good track record of avoiding attempts to stop their service. New technologies tend to attract media attention but is that desirable in all scenarios?"

TOR10THINGS (URL)

TOR10THINGS: 9 Makes it easy to get the software and updates: "Last, does the tool have a track record for responding to blocking?"

SCRAMBLESUIT (URL)

Deployed with Tor Browser Bundle (https://bridges.torproject.org/bridges?transport=scramblesuit)

MEEK (URL)

Deployed in Tor https://trac.torproject.org/projects/tor/wiki/doc/meek

FTE (URL)

Deployed on Tor (https://trac.torproject.org/projects/tor/wiki/doc/fte/setup)

VPNGATE (URL)

http://www.vpngate.net/en/

JAP (URL)

https://anonymous-proxy-servers.net/index.html

GOHOP (URL)

"Ready-to-use implementation: We published GoHop under an open-source license 1, GoHop currently supports Linux operat- ing system, and we have been using it to bypass censorship for several months."

veracity of claims

Used by Circumvention is not privacy, Tor 10 things

Evaluates whether the claims of about an approach by the its provider match reality.

CIRCUMVENTIONNOTPRIVACY (URL)

CIRCUMVENTIONNOTPRIVACY: 7.2.2 Level of protection: "A trustworthy tool needs to provide clear specifications of what the software can do, and what it can not do. Bold statements are insufficient when trying to find clear answers for questions like: What level of privacy, anonymity, and unlinkability can be guaranteed? What types of attacks can the tool sustain? Which risks can a user expect from using the tool?

TOR10THINGS (URL)

TOR10THINGS: 7 Doesn't promise to magically encrypt the entire Internet: "Anybody who promises '100% security' is selling something."

Tools

DEFIANCE

For an overview, go to the top of the page. For their documentation see (URL). We believe this tool mentioned the following evaluation criteria:

GOAL: availability of infrastructure

Definition: This criterion considers the availability of the infrastructure used by an approach for users and the feasibility of deployment.

Rationale for inclusion: "Section 2 (paper) - Address Pools frustrate address blocking by sheer size and diversity: any address in a pool can be (perhaps only briefly) the address of a DEFIANCE Gateway."

Associated metrics:

  • number of proxies

    Definition: The number of proxies usable with the tool.

    Rationale for inclusion: DEFIANCE: Section 1: "Address Pools are provisioned with sufficient *quantity*, quality, and diversity..." Section 3: "Rather than a few thousand well-known access entry points, tens (or hundreds) of thousands of ephemeral IP addresses are coordinated by Address Pool Operators via central APRAdb servers and regional Gateways."

GOAL: resistance to active probing

Definition: Active probing attacks involve the censor initiating connections to hosts to determine whether the host runs a given circumvention protocol, typically then blocking the host's IP address upon finding that it does. A system is resistant to active probing if an adversary cannot discover the use of the system using this technique.

Rationale for inclusion: "Section 1...current protocols are easy to circumvent... by scanning suspect IP addresses or address blocks for service response fingerprints and preemptively blocking them." Section 2.1: "If their traffic analysis leads them to suspect IP addresses or address blocks are being used for censorship bypass, they can scan those network address blocks. These scans might appear from anywhere in the world using contractors or other assets." Section 3.1: "An adversary scanning IP address blocks will not discover the contact and/or bridge relay Gateways. Without the correct sequence and timing, the Gateway does not respond to the contact or returns an innocuous response."

Associated metrics:

  • use authentication

    Definition: Whether a client needs authentication to connect to the server.

    Rationale for inclusion: DEFIANCE Section 1: "...current protocols are easy to circumvent... by scanning suspect IP addresses or address blocks for service response fingerprints and preemptively blocking them." Section 2.1: "If their traffic analysis leads them to suspect IP addresses or address blocks are being used for censorship bypass, they can scan those network address blocks. These scans might appear from anywhere in the world using contractors or other assets." Section 3.1: "An adversary scanning IP address blocks will not discover the contact and/or bridge relay Gateways. Without the correct sequence and timing, the Gateway does not respond to the contact or returns an innocuous response." Section 6.4: "These ephemeral Bridge Relays are the 'crown jewel', the goal of Address-Change Signaling. This step requires confidentiality, mutual authentication, and Perfect Forward Secrecy.... Separate identities and secrets prevent impersonation of another user and subsequent breaches of confidentiality. Proofs of security for key exchange require authentication of the ephemeral secret key by both parties."

GOAL: resistance to blocking

Definition: A system resists blocking if it is hard to block the protocol or IP address of the infrastructure that the approach uses, even given a method of identifying it. For example, if blocking would cause substantial collateral damage.

Rationale for inclusion: DEFIANCE: "The DEFIANCE Rendezvous Protocol specifies a series of network interactions and local calculations that ultimately reveal to each DEFIANCE user one of the many addresses of a DEFIANCE Gateway." DEFIANCE Section 1: "Address Pools are provisioned with sufficient quantity, quality, and diversity, frustrating efforts of censors to predict, map, or block the IP addresses." "...current protocols are easy to circumvent... by blocking direct communication with the service itself, by blocking communication with a service discovery component, and by blocking access entry points distributed by service discovery and/or listed in a communal service directory." Section 2.1: "They control access to the Domain Name System (DNS)."

Associated metrics:

  • use many access points

    Definition: Whether an approach uses too many hosts to make it hard for a censor to block all of them.

    Rationale for inclusion: DEFIANCE: Section 1: "Address Pools are provisioned with sufficient *quantity*, quality, and diversity..." Section 3: "Rather than a few thousand well-known access entry points, tens (or hundreds) of thousands of ephemeral IP addresses are coordinated by Address Pool Operators via central APRAdb servers and regional Gateways."

GOAL: resistance to security attacks

Definition: This criterion considers different measures that a paper uses to avoid security attacks such as man-in-the-middle, denial of service, malicious proxy, key reuse and replay attack.

Rationale for inclusion: DEFIANCE Section 2.1: "They can create counterfeit certificates used for Transport Layer Security (TLS)... By modifying the response, or by replacing the response with entirely false information, they can perform a Monkey-In-The- Middle (MITM) interception."

Associated metrics:

  • use encryption for confidentiality

    Definition: Whether an approach uses encryption for confidentiality (and/or integrity).

    Rationale for inclusion: DEFIANCE Section 6.4: "These ephemeral Bridge Relays are the 'crown jewel', the goal of Address-Change Signaling. This step requires confidentiality, mutual authentication, and Perfect Forward Secrecy."

GOAL: resistance to traffic analysis

Definition: An approach is resistant to traffic analysis if an adversary cannot statically use properties of the traffic generated by the approach to detect it. (Some of the metrics used for this goal can also be used for active probing, but they are not inherently active.)

Rationale for inclusion: "Section 2: Traffic Camouflage. Once the client establishes con- tact with a DEFIANCE Bridge, its traffic is camouflaged to prevent the adversary from noticing characteristics of the Tor protocol. While a discussion of specific camou- flage techniques is outside the scope of this paper, its objective is to steganographically transform the encrypted Tor stream into one of many unencrypted protocols"

Associated metrics:

GOAL: resistance to traffic manipulation

Definition: Evaluates the system's resistance to modification of packets, or injecting or dropping packets. This criterion is concerned only with manipulation of client-initiated flows.

Rationale for inclusion: "Section 2.1 (draft) - By modifying the [DNS] response, or by replacing the response with entirely false information, they can redirect a user to a different service or site than the user intended."

Associated metrics:

  • use authentication

    Definition: Whether a client needs authentication to connect to the server.

    Rationale for inclusion: DEFIANCE Section 1: "...current protocols are easy to circumvent... by scanning suspect IP addresses or address blocks for service response fingerprints and preemptively blocking them." Section 2.1: "If their traffic analysis leads them to suspect IP addresses or address blocks are being used for censorship bypass, they can scan those network address blocks. These scans might appear from anywhere in the world using contractors or other assets." Section 3.1: "An adversary scanning IP address blocks will not discover the contact and/or bridge relay Gateways. Without the correct sequence and timing, the Gateway does not respond to the contact or returns an innocuous response." Section 6.4: "These ephemeral Bridge Relays are the 'crown jewel', the goal of Address-Change Signaling. This step requires confidentiality, mutual authentication, and Perfect Forward Secrecy.... Separate identities and secrets prevent impersonation of another user and subsequent breaches of confidentiality. Proofs of security for key exchange require authentication of the ephemeral secret key by both parties."

GOAL: usability

Definition: Assesses the additional effort that the circumvention tool client user must expand to use the system.

Rationale for inclusion: "Section 3 - The DEFIANCE rendezvous protocol (RP) lets a user in a censored region of the network receive a small amount of information, leading to the DEFIANCE gateways, from servers outside the censored region. Since a censor may control a non-negligible fraction of our clients, it should be difficult for a client to automatically harvest a large number of entry point addresses. Thus an ideal rendezvous scheme would require human involvement (proof-of-life), machine time (proof-of-work), and artifi- cial delays to discover multiple entry points. There is a fundamental trade-off here between system usability and resilience to harvesting attacks."

Associated metrics:

Infranet

For an overview, go to the top of the page. For their documentation see (URL). We believe this tool mentioned the following evaluation criteria:

GOAL: network performance

Definition: Assesses the system's performance in terms of goodput, latency and overhead.

Rationale for inclusion: Section 7 (Performance Evaluation)

Associated metrics:

  • byte overhead

    Definition: How many extra bytes are introduced by the tool.

    Rationale for inclusion: "Figure 13. The overhead of running Infranet on Web server performance."

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

  • number of requests needed to retrieve data

    Definition: Assesses the number of requests that a requester must make to retrieve hidden messages.

    Rationale for inclusion: "Figure 12. Number of requests required to retrieve data of various sizes."

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

GOAL: openness of design

Definition: Assesses whether the source code available (client and server) and whether the design public or relies on security through obscurity.

Rationale for inclusion: Source code is available \\url{http://nms.csail.mit.edu/infranet/\\#research}

Associated metrics:

  • open source

    Definition: The tool's source code is open.

    Rationale for inclusion: Source code is available \\url{http://nms.csail.mit.edu/infranet/\\#research}

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

GOAL: resistance to active probing

Definition: Active probing attacks involve the censor initiating connections to hosts to determine whether the host runs a given circumvention protocol, typically then blocking the host's IP address upon finding that it does. A system is resistant to active probing if an adversary cannot discover the use of the system using this technique.

Rationale for inclusion: Section 5.1, "Discovery Attacks: A censor might attempt to discover Infranet requesters or responders by joining Infranet as a requester or a responder."

Associated metrics:

  • use authentication

    Definition: Whether a client needs authentication to connect to the server.

    Rationale for inclusion: Infranet resists active probing by using authentication (similar to obfs4). The censor needs to discover the IP address and public key of an Infranet responder (server). Section 5.1, "Once the client joins, all information exchanged with a responder is specific to that requester. Thus, by joining the network as a requester, the censor gains no additional information other than that which must already have been obtained out-of-band."

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

GOAL: resistance to blocking

Definition: A system resists blocking if it is hard to block the protocol or IP address of the infrastructure that the approach uses, even given a method of identifying it. For example, if blocking would cause substantial collateral damage.

Rationale for inclusion: Section 5.2.1- Infranets success against filtering attacks depends on the pervasiveness of Infranet responders throughout the Web... The wider the deployment of responders on Web servers around the world, the more likely it is that Infranet will succeed.

Associated metrics:

  • use many access points

    Definition: Whether an approach uses too many hosts to make it hard for a censor to block all of them.

    Rationale for inclusion: "Infranet's success against filtering attacks depends on the pervasiveness of Infranet responders throughout the Web."

    "The wider the deployment of responders on Web servers around the world, the more likely it is that Infranet will succeed."

    Infranet and CGIPROXY sort of satisfy this metric because depends on how many other people used the tool.

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

GOAL: resistance to traffic manipulation

Definition: Evaluates the system's resistance to modification of packets, or injecting or dropping packets. This criterion is concerned only with manipulation of client-initiated flows.

Rationale for inclusion: Section 5.2.2, "Transaction Tampering: For example, the adversary may change fields in HTTP request or response headers (e.g., changing the value of the Date: field), reorder fields within headers, or even remove or add fields. Infranet is resistant to these attacks because the tunnel protocol does not rely on modifications to the HTTP header." "...the Infranet requester must present a unique user identifier with each HTTP request in order to be recognized across multiple HTTP transactions." Section 5.2.3, "Session Tampering: An adversary might attempt to disrupt tunnel communication by interfering with sequences of HTTP requests. ... However, Infranet responders include the name of the served URL in each response stream, thus enabling the requester to detect session corruption and restart the transmission. ... The requester can also defend against these attacks with error correction techniques that recover from the insertion, deletion, and transposition of bits."

Associated metrics:

  • use authentication

    Definition: Whether a client needs authentication to connect to the server.

    Rationale for inclusion: Infranet resists active probing by using authentication (similar to obfs4). The censor needs to discover the IP address and public key of an Infranet responder (server). Section 5.1, "Once the client joins, all information exchanged with a responder is specific to that requester. Thus, by joining the network as a requester, the censor gains no additional information other than that which must already have been obtained out-of-band."

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

  • use error correcting codes

    Definition: Whether an approach uses error correcting codes.

    Rationale for inclusion: Section 5.2.3, "Session Tampering: An adversary might attempt to disrupt tunnel communication by interfering with sequences of HTTP requests." "However, Infranet responders include the name of the served URL in each response stream, thus enabling the requester to detect session corruption and restart the transmission." "The requester can also defend against these attacks with error correction techniques that recover from the insertion, deletion, and transposition of bits."

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

Identity-based Steganographic Tagging

For an overview, go to the top of the page. For their documentation see (URL). We believe this tool mentioned the following evaluation criteria:

GOAL: resistance to traffic analysis

Definition: An approach is resistant to traffic analysis if an adversary cannot statically use properties of the traffic generated by the approach to detect it. (Some of the metrics used for this goal can also be used for active probing, but they are not inherently active.)

Rationale for inclusion: The identity-based steganographic tagging scheme has indistinguishable from random.

Associated metrics:

  • use encryption to resist traffic analysis

    Definition: Whether an approach uses encryption to resist traffic analysis.

    Rationale for inclusion: The IBE tag is indistinguishable from random. Page 5: We say that an identity-based steganographic tagging scheme has indistinguishable tags and shared secrets if for every polynomially bounded adversary A, we have that AdvID - TAG(lambda) is negligible.

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

Message in a Bottle

For an overview, go to the top of the page. For their documentation see (URL). We believe this tool mentioned the following evaluation criteria:

GOAL: infrastructure cost

Definition: Assesses the cost of infrastructure required to deploy an approach in real world.

Rationale for inclusion: Unobtrusive deployment. With our proof-of-concept ap- plication, we have demonstrated that it is possible to run a miab instance on a single modern machine with a fast domestic Internet connection. We recommend a 100Mbps connection, such as the one provided by Comcast in the US, also considering the fluctuations in the speed achievable at rush hours. Therefore, any private citizen with some disposable income, and living in a country with a modern offering for Internet connectivity, can run a miab instance. Moreover, this burden is sustained only by Bob; Alice has minimal requirements to participate in the protocol.

Associated metrics:

  • cost of external services

    Definition: Estimates the cost of external services, e.g., cloud services, CDNs, that are required to deploy an approach.

    Rationale for inclusion: MIAB discusses "unobtusive deployment". "Unobtrusive deployment. With our proof-of-concept ap- plication, we have demonstrated that it is possible to run a miab instance on a single modern machine with a fast domestic Internet connection. We recommend a 100Mbps connection, such as the one provided by Comcast in the US, also considering the fluctuations in the speed achievable at rush hours. Therefore, any private citizen with some disposable income, and living in a country with a modern offering for Internet connectivity, can run a miab instance. Moreover, this burden is sustained only by Bob; Alice has minimal requirements to participate in the protocol."

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

GOAL: network performance

Definition: Assesses the system's performance in terms of goodput, latency and overhead.

Rationale for inclusion: Section 5.1, Performance

Associated metrics:

  • latency

    Definition: Assesses the round-trip time for a request.

    Rationale for inclusion: MIAB Section 5.4.1: "Therefore, the maximum latency between the publishing of a post with MIAB content and our tweeting is ten minutes (five minutes in the ping server's queue, and another five before we process the post)."

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

  • time overhead

    Definition: How much extra time it takes to use the tool.

    Rationale for inclusion: Section 5.1, Performance: "On average, it takes 0.56 seconds per image to embed a message, and 0.02 seconds to recover it. In particular, performing exclusively our steganographic extraction on a 5- minute pings chunk takes, on average, 2m:51s on a Intel-i7 eight- core laptop. Performing exclusively the RSA decryption takes 2m:35s. Fetching all the images from the blogs takes an average of 4m:17s. Since the steganographic test is CPU bound, and the blogs fetching is I/O bound, the two operations can execute simultaneously with an acceptable loss in performance: processing a five-minutes chunk of pings with the full miab, with either scheme, completes under five minutes on average, with a processor load under 90%."

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

GOAL: openness of design

Definition: Assesses whether the source code available (client and server) and whether the design public or relies on security through obscurity.

Rationale for inclusion: Open-source (http://www.message-in-a-bottle.us/)

Associated metrics:

  • open source

    Definition: The tool's source code is open.

    Rationale for inclusion: Open-source (http://www.message-in-a-bottle.us/)

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

GOAL: resistance to blocking

Definition: A system resists blocking if it is hard to block the protocol or IP address of the infrastructure that the approach uses, even given a method of identifying it. For example, if blocking would cause substantial collateral damage.

Rationale for inclusion: MIAB Section 5.6: "The Censor might attempt to block all blogs by blacklisting their domain names, or IP addresses. It is essential to MIAB's availability that the blocking set (that is, the set of domains or IP addresses to block) is large, as this makes the maintenance of a blacklist impractical..."

Associated metrics:

  • use many access points

    Definition: Whether an approach uses too many hosts to make it hard for a censor to block all of them.

    Rationale for inclusion: MIAB Section 5.6: "The Censor might attempt to block all blogs by blacklisting their domain names, or IP addresses. It is essential to MIAB's availability that the blocking set (that is, the set of domains or IP addresses to block) is large, as this makes the maintenance of a blacklist impractical..."

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

Trist

For an overview, go to the top of the page. For their documentation see (URL). We believe this tool mentioned the following evaluation criteria:

SkyF2F

For an overview, go to the top of the page. For their documentation see (URL). We believe this tool mentioned the following evaluation criteria:

GOAL: end-user protection

Definition: Assesses whether an approach protects user's privacy from intermediate and end nodes.

Rationale for inclusion: However, Skype does not guarantee strong anonymity. To improve anonymity, existing anonymity systems could be tailored to our system.

Associated metrics:

GOAL: infrastructure cost

Definition: Assesses the cost of infrastructure required to deploy an approach in real world.

Rationale for inclusion: Section III.B.: "Low resources cost: Our system should be easily deployed and used in the real world. Unlike other censorship resistant design that need to deploy a number of nodes or need volunteers, our system is built on existing overlay network, users just install a plug-in for Skype client."

Associated metrics:

  • cost of external services

    Definition: Estimates the cost of external services, e.g., cloud services, CDNs, that are required to deploy an approach.

    Rationale for inclusion: SkyF2F: Section III.B.: "Low resources cost: Our system should be easily deployed and used in the real world. Unlike other censorship resistant design that need to deploy a number of nodes or need volunteers, our system is built on existing overlay network, users just install a plug-in for Skype client.

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

GOAL: network performance

Definition: Assesses the system's performance in terms of goodput, latency and overhead.

Rationale for inclusion: Section IV.B, Design Goals: "Performance: we seek to achieve acceptable bandwidth for web browsing experiences."

Associated metrics:

  • goodput

    Definition: The amount of useful throughput the tool enables.

    Rationale for inclusion: SkyF2F: Section III.B.: "Performance: we seek to achieve acceptable bandwidth for web browsing experiences." (Though they never actually measure it.)

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

GOAL: resistance to blocking

Definition: A system resists blocking if it is hard to block the protocol or IP address of the infrastructure that the approach uses, even given a method of identifying it. For example, if blocking would cause substantial collateral damage.

Rationale for inclusion: Section V.C. "...because Skype relies on a central login server, Skype can still be blocked. However, we think blocking a major service like Google or Skype can do actual economic damage."

Associated metrics:

  • use a popular protocol

    Definition: Whether an approach sends traffic using a popular protocol, such as the Skype protocol, to force the censor to either block a popular protocol or identify the circumventing usage of the protocol from normal usage.

    Rationale for inclusion: Another idea is all or nothing which assumes that it is hard to decide based on observing if certain communication data belongs to censored content or not. For example, if all emails are encrypted around the world, then a censor could not scan them by certain words. We investigate how to utilize this idea to design a low-cost system for circumventing Internet censorship. We are aware of the fact that building on top of existing overlays will make the job easier. For example, we could use the Skype overlay network as a messaging transport, a popular plug-in application for Skype client could spread from user to user through the network.

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

  • use many access points

    Definition: Whether an approach uses too many hosts to make it hard for a censor to block all of them.

    Rationale for inclusion: Rejects, but mentions, the idea: "Many censorship resistant systems have been proposed, which rely on deploying many access points to the censored domain. Therefore they face the problem of discovering available nodes and deploying a large number of nodes. Opposite to many access point approach, we present a system building on existing overlay network,"

  • use popular hosts

    Definition: Whether an approach uses popular hosts, such as Skype nodes and CDNs, to resist address blocking.

    Rationale for inclusion: Section V.C, Limitations - "... because Skype relies on a central login server, Skype can still be blocked. However, we think blocking a major service like Google or Skype can do actual economic damage."

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

GOAL: resistance to security attacks

Definition: This criterion considers different measures that a paper uses to avoid security attacks such as man-in-the-middle, denial of service, malicious proxy, key reuse and replay attack.

Rationale for inclusion: Section V.A, Attacks, "A censor might setup a SkyF2F server and publish it to public, in the hope that some user might connect it." "A censor might host a supernode in the Skype network." "A censor might mount DoS attacks against a target SkyF2F server. By attacking the server to shut it down, reduce its reliability. "

Associated metrics:

  • limit service to each user ID (DoS)

    Definition: Avoid DoS by limiting the amount of service the approach will provide to each user.

    Rationale for inclusion: SkyF2F: Section V.B.: "A censor might mount DoS attacks against a target SkyF2F server. By attacking the server to shut it down, reduce its reliability." "s a public service, this is a real problem. we take a simple measure of limiting each client's connections and bandwidth."

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

  • use trustworthy proxy

    Definition: By using a trustworthy proxy as the forwarder, the approach avoids the risks of a malicious proxy (as long as the proxy remains trustworthy).

    Rationale for inclusion: SkyF2F: Section V.C.: "...we should consider the security inside Skype sys- tem. It is unknown if the design of the Skype network makes it possible for some nodes to monitor all conversation traffic.... It is likely that the Skype system could be compromised by an exceedingly capable engineer..."

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

GOAL: usability

Definition: Assesses the additional effort that the circumvention tool client user must expand to use the system.

Rationale for inclusion: Section IV.B, Design Goals: "Easy to use: As the Skype clients are widespread over the Internet, user can use our system easily. If a user with restricted internet access (call her Alice) to a censored server, she contacts a user (maybe his friend, call him Bob) with free internet access, Bob serves as a router for Alice and transparently forwards all communication data between Alice and the censored server."

Associated metrics:

  • no installation

    Definition: Using the tool does not require installing special software.

    Rationale for inclusion: Section IV.C, SYSTEM DESCRIPTION, "Our system is a plug-in application Skype Client. As Skype clients are widespread over the Internet, low deployment costs become available and user can use the system easily (without installing any additional software)."

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

Collage

For an overview, go to the top of the page. For their documentation see (URL). We believe this tool mentioned the following evaluation criteria:

GOAL: availability of infrastructure

Definition: This criterion considers the availability of the infrastructure used by an approach for users and the feasibility of deployment.

Rationale for inclusion: Section 7.1 Availability: "A censor may try to prevent clients from sending and re- ceiving messages. Our strongest argument for Collage’s availability depends on a censor’s unwillingness to block large quantities of legitimate content."

Associated metrics:

  • preponderance of suitable servers

    Definition: Some tools rely on finding servers with a specific property at large in the Internet. For example, servers that accept user-posted content, or servers with specific network protocol quirks. This criterion means that the study measured how common such servers really are.

    Rationale for inclusion: COLLAGE can use any available content hosts to transfer messages, e.g., Flickr, blogspot.

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

GOAL: deniability under computer inspection

Definition: Whether the circumvention tool users can plausibly deny using it even when their computers are inspected.

Rationale for inclusion: While Collage discusses "deniability", it is in the sense of resistence to traffic analysis.

Associated metrics:

GOAL: network performance

Definition: Assesses the system's performance in terms of goodput, latency and overhead.

Rationale for inclusion: Section 5, Performance Evaluation

Associated metrics:

  • byte overhead

    Definition: How many extra bytes are introduced by the tool.

    Rationale for inclusion: Figure 5(b) shows Per-task Traffic Overhead

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

  • time overhead

    Definition: How much extra time it takes to use the tool.

    Rationale for inclusion: Figure 5(c) shows Transfer time, for various network connectivity rates (download/upload)

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

GOAL: openness of design

Definition: Assesses whether the source code available (client and server) and whether the design public or relies on security through obscurity.

Rationale for inclusion: Source code available (http://noise-lab.net/projects/old-projects/collage/)

Associated metrics:

  • open source

    Definition: The tool's source code is open.

    Rationale for inclusion: Source code available (http://noise-lab.net/projects/old-projects/collage/)

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

GOAL: resistance to blocking

Definition: A system resists blocking if it is hard to block the protocol or IP address of the infrastructure that the approach uses, even given a method of identifying it. For example, if blocking would cause substantial collateral damage.

Rationale for inclusion: COLLAGE is resistant to address blocking as it uses popular content hosts used by regular users, e.g., Flickr and it is hard to distinguish Collage content from regular content.

Associated metrics:

  • use a popular protocol

    Definition: Whether an approach sends traffic using a popular protocol, such as the Skype protocol, to force the censor to either block a popular protocol or identify the circumventing usage of the protocol from normal usage.

    Rationale for inclusion: The censor might instead block traffic patterns resembling Collage's tasks. From the censor's perspective, doing so may allow legitimate users access to content as long as they do not use one of the many tasks in the task database to retrieve the content. Because tasks in the database are "popular" among innocuous users by deign, blocking a task may also disrupt the activities of legitimate users.

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

  • use many access points

    Definition: Whether an approach uses too many hosts to make it hard for a censor to block all of them.

    Rationale for inclusion: The sheer number of sites that users could use to exchange messages, and the many different ways they could hide content, makes it difficult for a censor to successfully monitor and block all of them.

    Hiding messages in photos, text, and video across a wide range of host sites makes it more difficult for censors to block all possible sources of censored content.

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

GOAL: resistance to security attacks

Definition: This criterion considers different measures that a paper uses to avoid security attacks such as man-in-the-middle, denial of service, malicious proxy, key reuse and replay attack.

Rationale for inclusion: Considers malicious hosts. See "Use_innocuous_proxy"

Associated metrics:

  • use encryption for confidentiality

    Definition: Whether an approach uses encryption for confidentiality (and/or integrity).

    Rationale for inclusion: Section 6.2, Web Content Proxy: "Once the client knows the publisher’s public key, it sends a message requesting registration. The message identifier is the publisher’s public key and the message payload contains the public key of the client encrypted using the publisher’s public key. This encryption ensures that only the publisher knows the client’s public key. The publisher receives and decrypts the client’s registration request using his own private key."

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

  • use trustworthy proxy

    Definition: By using a trustworthy proxy as the forwarder, the approach avoids the risks of a malicious proxy (as long as the proxy remains trustworthy).

    Rationale for inclusion: COLLAGE uses innocuous content hosts (e.g., Flickr) to transfer contents. It uses public-key encryption, where keys are distributed out-of-band.

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

Cirripede

For an overview, go to the top of the page. For their documentation see (URL). We believe this tool mentioned the following evaluation criteria:

GOAL: availability of infrastructure

Definition: This criterion considers the availability of the infrastructure used by an approach for users and the feasibility of deployment.

Rationale for inclusion: Section 6.3 DR deployment simulation

Associated metrics:

GOAL: client performance

Definition: Assesses an approach's client program efficiency in terms of CPU and memory usage.

Rationale for inclusion: Section 6, Evaluation discusses CPU and memory utilization

Associated metrics:

  • CPU usage by users

    Definition: Assesses the percentage of CPU cycles consumed by the client or server part of the system.

    Rationale for inclusion: Cirripede: Section 6.1 "Registration performance": "the load on the RS (in particular, CPU and memory utilization).... the average CPU utilization is 56% and the max 73%. The average memory utilization is 1.1 GB and the max 1.6 GB."

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

  • memory usage by users

    Definition: Assesses the memory requirements to run the system.

    Rationale for inclusion: Cirripede: Section 6.1 "Registration performance": "the load on the RS (in particular, CPU and memory utilization).... the average CPU utilization is 56% and the max 73%. The average memory utilization is 1.1 GB and the max 1.6 GB."

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

GOAL: end-user protection

Definition: Assesses whether an approach protects user's privacy from intermediate and end nodes.

Rationale for inclusion: Using Cirripede alone provides unobservability from the warden ISP, but it does not provide destination-anonymity from the Cirripede system itself, the service proxy knows the covert destination being targeted by a client.

Associated metrics:

  • hide user information from end host

    Definition: The tool hides information about the user from the end host (destination) to which the user connects to provide some degree of anonymity.

    Rationale for inclusion: Cirripede: Using Cirripede alone provides unobservability from the warden ISP, but it does not provide destination-anonymity from the Cirripede system itself: the service proxy knows the covert destination being targeted by a client.

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

GOAL: network performance

Definition: Assesses the system's performance in terms of goodput, latency and overhead.

Rationale for inclusion: Section 6, Evaluation discusses overheads of the system

Associated metrics:

  • fraction of clients that can utilize the network

    Definition: Assesses the number of clients (source hosts) in the Internet that would be able to join a system.

    Rationale for inclusion: (copied from Cirripede) Fraction of clients that can utilize the network (Figure 5): First, we studied how many clients (source hosts) in the Internet would be able to join Cirripede, while varying the extensiveness of DR deployment. Figure 5(a) shows this result under the assumption that a random subset of ASes in the Internet act as DRs. We also vary the fraction of overt destinations the client is allowed to probe (in practice, the client may wish to limit the set of overt destinations probed, to reduce potential suspicion).

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

  • registration performance

    Definition: Some systems need to apply a special distinguisher or mark to traffic destined for circumvention. For example, end-to-middle proxying systems need to tag flows at the client side and recognize them at the station. This criterion considers the performance of the registration method.

    Rationale for inclusion: Section 6.1 Registration performance: We are interested in the ability of the RS to handle real traffic load. The two main metrics are: (1) the fraction of registration signals that the RS can detect, and (2) the load on the RS (in particular, CPU and memory utilization).

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

  • throughput

    Definition: The amount of throughput/bandwidth the tool enables.

    Rationale for inclusion: Section 6.2 Throughput performance: For these experiments, we only measure the performance of downloading data from a web server (thus all clients are pre-registered with Cirripede before each experiment).

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

GOAL: resistance to blocking

Definition: A system resists blocking if it is hard to block the protocol or IP address of the infrastructure that the approach uses, even given a method of identifying it. For example, if blocking would cause substantial collateral damage.

Rationale for inclusion: Introduction - "By strategically placing deflecting routers in the Internet core, it is possible to make the Cirripede service available to a large user population, we show that using only two tier-1 ASes can deliver Cirripede service to all Internet hosts. In this case, censors cannot block access to Cirripede without blocking a significant fraction of all Internet sites. Cirripede can operate on the existing router infrastructure using off-the-shelf networking tools, with low-cost commodity servers providing the registration and proxy services." Section 7.2, Blocking Circumvention - "A key difference between Cirripede and the above proxybased approaches is that, in our case, the proxy is embedded within the network itself, and blocking individual web sites is ineffective against Cirripede."

Associated metrics:

  • use network infrastructure

    Definition: Whether an approach uses infrastructure within a network, e.g., router, to avoid address blocking.

    Rationale for inclusion: CIRRIPEDE: To address these issues, we need technologies that provide unobservable communication that circumvent monitoring and censorship technologies. As a first step in that direction, we describe Cirripede, a platform for unobservable communication with Internet destinations. From the perspective of a monitoring entity, a user of Cirripede appears to be making regular network connections, while the user is actually getting connected to destinations that are forbidden by that monitoring entity. To do this, Cirripede requires in-network support, through configuration changes and deployment of overlay nodes outside of the repressive regime's network. We envision these in-network changes may be offered as a service by some participating ISPs, or mandated/supported by non-repressive governments (or NGOs) to encourage the freedom of speech abroad"

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

GOAL: resistance to security attacks

Definition: This criterion considers different measures that a paper uses to avoid security attacks such as man-in-the-middle, denial of service, malicious proxy, key reuse and replay attack.

Rationale for inclusion: Section 4.3 Security analysis: considers "Malicious participating ISPs" and "Honest but curious participating ISPs".

Associated metrics:

  • use encryption for confidentiality

    Definition: Whether an approach uses encryption for confidentiality (and/or integrity).

    Rationale for inclusion: CIRRIPEDE: as the communication of Cirripede is encrypted using a key shared between Cirripede and a client, a par- ticipating ISP will not be able to disclose either the covert destination address or the communicated content.

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

Decoy routing

For an overview, go to the top of the page. For their documentation see (URL). We believe this tool mentioned the following evaluation criteria:

GOAL: resistance to active probing

Definition: Active probing attacks involve the censor initiating connections to hosts to determine whether the host runs a given circumvention protocol, typically then blocking the host's IP address upon finding that it does. A system is resistant to active probing if an adversary cannot discover the use of the system using this technique.

Rationale for inclusion: A more active adversary can replay or preplay sentinels. If the adversary observes a TLS client hello, it can replay the hello message to the same destination to see whether the response is the expected response or appears to be from a decoy proxy. If the session fails in an unexpected manner but the TCP connection is not closed or reset, then the adversary may suspect that the client is using decoy routing.

Associated metrics:

GOAL: resistance to blocking

Definition: A system resists blocking if it is hard to block the protocol or IP address of the infrastructure that the approach uses, even given a method of identifying it. For example, if blocking would cause substantial collateral damage.

Rationale for inclusion: Abstract: "Unlike other circumvention techniques, decoy routing does not require a client to connect to a specific IP address (which is easily blocked) in order to provide circumvention. We show that if it is possible for a client to connect to any unblocked host/service, then decoy routing could be used to connect them to a blocked destination without cooperation from the host. This is accomplished by placing the circumvention service in the network itself - where a single device could proxy traffic between a significant fraction of hosts - instead of at the edge."

Associated metrics:

  • use network infrastructure

    Definition: Whether an approach uses infrastructure within a network, e.g., router, to avoid address blocking.

    Rationale for inclusion: Abstract: "Unlike other circumvention techniques, decoy routing does not require a client to connect to a specific IP address (which is easily blocked) in order to provide circumvention. We show that if it is possible for a client to connect to any unblocked host/service, then decoy routing could be used to connect them to a blocked destination without cooperation from the host. This is accomplished by placing the circumvention service in the network itself - where a single device could proxy traffic between a significant fraction of hosts - instead of at the edge."

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

GOAL: resistance to security attacks

Definition: This criterion considers different measures that a paper uses to avoid security attacks such as man-in-the-middle, denial of service, malicious proxy, key reuse and replay attack.

Rationale for inclusion: 4.2 Denial of Access to Decoy Routing

Associated metrics:

GOAL: resistance to traffic analysis

Definition: An approach is resistant to traffic analysis if an adversary cannot statically use properties of the traffic generated by the approach to detect it. (Some of the metrics used for this goal can also be used for active probing, but they are not inherently active.)

Rationale for inclusion: 4.1 Detection of Decoy Routing: "For instance, if the hijacked path has different latencies, path lengths, or path MTU than the client to decoy destination path, then analysis may reveal that the flow is suspicious. The decoy router can delay packets and adjust the TTL and MTU of the packets it creates in order to attenuate the risk of detection."

Associated metrics:

Telex

For an overview, go to the top of the page. For their documentation see (URL). We believe this tool mentioned the following evaluation criteria:

GOAL: end-user protection

Definition: Assesses whether an approach protects user's privacy from intermediate and end nodes.

Rationale for inclusion: Unlike Tor, we separate the problem of censorship resistance from that of anonymous communication and concentrate on re- sisting blocking; users who require increased anonymity can use Telex as a gateway to the Tor network.

Associated metrics:

  • hide user information from end host

    Definition: The tool hides information about the user from the end host (destination) to which the user connects to provide some degree of anonymity.

    Rationale for inclusion: Mentions but does not satisfy. TELEX: "Unlike Tor, we separate the problem of censorship resistance from that of anonymous communication and concentrate on re- sisting blocking; users who require increased anonymity can use Telex as a gateway to the Tor network."

GOAL: network performance

Definition: Assesses the system's performance in terms of goodput, latency and overhead.

Rationale for inclusion: Section 8 Evaluation

Associated metrics:

  • registration performance

    Definition: Some systems need to apply a special distinguisher or mark to traffic destined for circumvention. For example, end-to-middle proxying systems need to tag flows at the client side and recognize them at the station. This criterion considers the performance of the registration method.

    Rationale for inclusion: Section 8.2 Tagging performance: We evaluated our tagging implementation by generating and verifying tags in bulk using a single CPU core on the Telex station. We performed ten trials, each of which processed a batch of 100, 000 tags. The mean time to gen- erate a batch was 18.24 seconds with a standard deviation of 0.016 seconds, and the mean time to verify a batch was 9.03 seconds with a standard deviation of 0.0083 seconds. This corresponds to a throughput of approximately 5482 tags generated per second and 11074 tags verified per second. As our TLS throughput experiments show, tag verification appears very unlikely to be a bottleneck in our system.

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

  • throughput

    Definition: The amount of throughput/bandwidth the tool enables.

    Rationale for inclusion: Figure 4: Client Request Throughput: We measured the rate at which two client machines could complete HTTP requests for a 1 kB page over a laboratory network, using either TLS or our Telex prototype. The prototype’s performance was competitive with that of unmodified TLS.

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

  • time overhead

    Definition: How much extra time it takes to use the tool.

    Rationale for inclusion: We also compared the time taken to load the 83 unblocked sites with and without Telex. While this metric was difficult to measure accurately due to varying network conditions, we observed a median overhead of approximately 60%.

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

GOAL: openness of design

Definition: Assesses whether the source code available (client and server) and whether the design public or relies on security through obscurity.

Rationale for inclusion: Code available, https://github.com/ewust/telex

Associated metrics:

  • open source

    Definition: The tool's source code is open.

    Rationale for inclusion: Code available, https://github.com/ewust/telex

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

GOAL: resistance to blocking

Definition: A system resists blocking if it is hard to block the protocol or IP address of the infrastructure that the approach uses, even given a method of identifying it. For example, if blocking would cause substantial collateral damage.

Rationale for inclusion: Introduction: Today, the most widely-used tools for circumventing Internet censorship take the form of encrypted tunnels and proxies, ... these systems inevitably lead to a cat-and-mouse game in which the censor attempts to discover and block the services’ IP addresses. To overcome this problem, we propose Telex: an end- to-middle proxy with no IP address, located within the network infrastructure. Clients invoke the proxy by using public-key steganography to tag otherwise ordinary TLS sessions destined for uncensored websites.

Associated metrics:

  • use network infrastructure

    Definition: Whether an approach uses infrastructure within a network, e.g., router, to avoid address blocking.

    Rationale for inclusion: TELEX: To overcome this problem, we propose Telex: an end- to-middle proxy with no IP address, located within the network infrastructure. Clients invoke the proxy by using public-key steganography to "tag" otherwise ordinary TLS sessions destined for uncensored websites.

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

GOAL: resistance to security attacks

Definition: This criterion considers different measures that a paper uses to avoid security attacks such as man-in-the-middle, denial of service, malicious proxy, key reuse and replay attack.

Rationale for inclusion: Section 6, Security Analysis

Associated metrics:

  • use block cipher (key reuse)

    Definition: Whether an approach uses block cipher to resist key reuse attack.

    Rationale for inclusion: Section 6 Security Analysis, Stream cipher weakness: TLS supports several stream cipher modes for encrypting data sent over the connec- tion. Normally, the key stream is used once per session, to avoid vulnerability to a reused key attack. However, the Telex station and NotBlocked.com use the same shared secret when sending data to the client, so the same key stream is used to encrypt two different plaintexts. An attacker (possibly different from the censor) with the abil- ity to receive both of the resulting ciphertexts can simply XOR them together to obtain the equivalent of the plain- texts XORed together. To mitigate this issue, Telex sends a TCP RST to NotBlocked.com to quickly stop it from returning data. In addition, our implementation uses a block cipher in CBC mode, for which TLS helps mitigate these issues further by providing for the communication of a random per-record IV.

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

  • use client puzzle (DoS)

    Definition: Require clients to solve a puzzle to prevent DoS.

    Rationale for inclusion: TELEX: "First, it may attempt to exhaust Telex's bandwidth to proxy to Blocked.com. Second, it may attempt to exhaust a Telex station's tag detection capabilities by creating a large amount of ClientHello messages for the station to check. " "To com- bat the first attack, we can implement a client puzzle [20]," "To combat the second attack, we can implement our tag checking in hardware to increase throughput if necessary."

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

  • use timestamp (replay)

    Definition: Whether an approach uses timestamp to resist replay attack.

    Rationale for inclusion: TELEX: Tag replay is prevented by shared secret. "Tag replay The censor might attempt to use various replay attacks to detect Telex usage. The most basic of these attacks is for the censor to initiate its own Telex connection and reuse the nonce from a suspect connec- tion; if this connection receives Telex service, the censor can conclude that the nonce was tagged and the original connection was a Telex request. Our protocol prevents this by requiring the client to prove to the Telex station that it knows the shared secret associated with the tagged nonce. We achieve this by using the shared secret to derive the key exchange param- eter, as described in Section 5. In particular, consider the encrypted Finished message that terminates the TLS handshake. This message must be encrypted using the freshly negotiated key (or else the TLS server will hang up), so it cannot simply be replayed. Second, the key exchange parameter in use must match the shared secret in the tagged nonce, or the Telex station will not be able to verify the MAC on the Finished message. Together, these requirements imply that the client must know the shared secret."

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

GOAL: resistance to traffic analysis

Definition: An approach is resistant to traffic analysis if an adversary cannot statically use properties of the traffic generated by the approach to detect it. (Some of the metrics used for this goal can also be used for active probing, but they are not inherently active.)

Rationale for inclusion: Section 6.1 Passive attacks, Traffic analysis: A sophisticated adversary might attempt to detect a use of Telex by detecting anomalous patterns in connection count, packet size, and timing. ... However, this kind of attack would be well beyond the level of sophistication observed in current censors.

Associated metrics:

  • TLS characteristics

    Definition: Prevents detection by TLS characteristics, like TLS nonce, clienthello or serverhello messages.

    Rationale for inclusion: Section 6.1 Passive Attacks: Telex deviates from a normal TLS handshake in the client’s nonce (sent in the ClientHello message) and in the client’s key exchange parameters. In Section 4, we showed that an attacker cannot distinguish a Telex tag from a truly random string with more than a negligible advantage. This means that a client’s tagged nonce (using Telex) is indistinguishable from a normal TLS random nonce. Likewise, the Telex-generated key exchange pa- rameters are the output of a secure PRG; they are not distinguishable from truly random strings as a direct result of the security of the PRG.

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

GOAL: resistance to traffic manipulation

Definition: Evaluates the system's resistance to modification of packets, or injecting or dropping packets. This criterion is concerned only with manipulation of client-initiated flows.

Rationale for inclusion: Section 6.2 Active attacks, Traffic manipulation: The censor might attempt to modify messages between the client and the Telex station, but Telex inherits defenses against this from TLS.

Associated metrics:

  • use TLS for integrity

    Definition: Whether an approach uses TLS to provide integrity.

    Rationale for inclusion: Section 6, Traffic manipulation: The censor might attempt to modify messages between the client and the Telex station, but Telex inherits defenses against this from TLS.

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

CensorSpoofer

For an overview, go to the top of the page. For their documentation see (URL). We believe this tool mentioned the following evaluation criteria:

GOAL: availability of infrastructure

Definition: This criterion considers the availability of the infrastructure used by an approach for users and the feasibility of deployment.

Rationale for inclusion: Table 2: Usable dummy hosts based on AS paths and Figure 3(e)-(f): stability of the dummy hosts over a short and long time period

Associated metrics:

  • preponderance of suitable servers

    Definition: Some tools rely on finding servers with a specific property at large in the Internet. For example, servers that accept user-posted content, or servers with specific network protocol quirks. This criterion means that the study measured how common such servers really are.

    Rationale for inclusion: CensorSpoofer uses the term "dummy host"; they did an Nmap scan to find hosts with particular SIP port characteristics that they need (see Algorithm 1 and Section 7.2.2).

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

  • stability of decoy hosts

    Definition: Examines how long a decoy host is available to carry on a conversation.

    Rationale for inclusion: Figure 3(e) and 3(f)

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

GOAL: network performance

Definition: Assesses the system's performance in terms of goodput, latency and overhead.

Rationale for inclusion: Section 7.2.1 Performance Evaluation

Associated metrics:

  • goodput

    Definition: The amount of useful throughput the tool enables.

    Rationale for inclusion: Figure 3(a)

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

  • speed of downloading a webpage

    Definition: Assesses the time required to download a webpage. This is really a combination of goodput and latency, but it is specifically applied so often that we made it its own criterion.

    Rationale for inclusion: Figure 3

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

GOAL: resistance to blocking

Definition: A system resists blocking if it is hard to block the protocol or IP address of the infrastructure that the approach uses, even given a method of identifying it. For example, if blocking would cause substantial collateral damage.

Rationale for inclusion: CensorSpoofer: Section 1: "Our key insight is that it is possible to use IP address spoofing to send data from the proxy to a user without revealing its actual origin."

Associated metrics:

  • use a popular protocol

    Definition: Whether an approach sends traffic using a popular protocol, such as the Skype protocol, to force the censor to either block a popular protocol or identify the circumventing usage of the protocol from normal usage.

    Rationale for inclusion: To avoid identification by the censor, CensorSpoofer mimics an encrypted VoIP session to tunnel the downstream data

    However, the censor is motivated to allow citizens to normally access basic Internet services, such as IM, Email and VoIP, as blocking such services would lead to economic losses and political pressure. More specifically, we assume the censor is unwilling to interfere with the Internet connections of a user, e.g., an ongoing VoIP conversation, unless it has evidence that a particular connection is being used for bypassing censorship.

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

GOAL: resistance to insider attacks

Definition: Considers whether the system continues to work even if the censor joins the circumvention network and attempts to disrupt it.

Rationale for inclusion: Perfect resistance to insider attacks: The censor should not be able to break unblockability or unobservability of CensorSpoofer even if nearly all users are compromised.

Associated metrics:

GOAL: server obfuscation

Definition: Keeping the server used as a forwarder by the circumvention network hidden from the censor.

Rationale for inclusion: As for the downstream channel, since the proxy's IP (i.e., source IP) is not used in packet routing, we can adopt IP spoofing to conceal the proxy's IP address.

Associated metrics:

  • indirect connection to forwarder

    Definition: The circumventor's computer connects indirectly to the circumvention network's forwarders through an innocuous server.

    Rationale for inclusion: Our key insight is that it is possible to use IP address spoofing to send data from the proxy to a user without revealing its actual origin. Such a spoofed channel allows communication in a single direction only; however, we can exploit the asymmetric nature of web-browsing traf- fic, using a low-bandwidth indirect channel, such as stegano- graphic instant messages or Email, to communicate requests from the user to the proxy.

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

Flash Proxy

For an overview, go to the top of the page. For their documentation see (URL). We believe this tool mentioned the following evaluation criteria:

GOAL: availability of infrastructure

Definition: This criterion considers the availability of the infrastructure used by an approach for users and the feasibility of deployment.

Rationale for inclusion: Section 4.3 Capacity

Associated metrics:

  • rate of proxy churn

    Definition: Measures or estimates the rate at which new proxies appear and old proxies go away.

    Rationale for inclusion: Section 4.3 Capacity. Figure 6 shows the number of simultaneous visitors to the web page for each day of the experiment. There were at times as many as three visitors viewing the page at once, but only about 17% of the time was there even one visitor. This web page acting alone would not be able to provide good proxy service, because of the long periods during which there are no visitors and hence no flash proxies. It would take several such pages working together to fill in the gaps and provide continuous service with high probability.

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

GOAL: end-user protection

Definition: Assesses whether an approach protects user's privacy from intermediate and end nodes.

Rationale for inclusion: Uses Tor for anonymity

Associated metrics:

  • hide user information from end host

    Definition: The tool hides information about the user from the end host (destination) to which the user connects to provide some degree of anonymity.

    Rationale for inclusion: Uses Tor for anonymity

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

GOAL: network performance

Definition: Assesses the system's performance in terms of goodput, latency and overhead.

Rationale for inclusion: Section 4

Associated metrics:

  • throughput

    Definition: The amount of throughput/bandwidth the tool enables.

    Rationale for inclusion: Section 4.1 Throughput

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

GOAL: openness of design

Definition: Assesses whether the source code available (client and server) and whether the design public or relies on security through obscurity.

Rationale for inclusion: Open-source (https://crypto.stanford.edu/flashproxy/)

Associated metrics:

  • open source

    Definition: The tool's source code is open.

    Rationale for inclusion: https://crypto.stanford.edu/flashproxy/#source-code

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

GOAL: resistance to blocking

Definition: A system resists blocking if it is hard to block the protocol or IP address of the infrastructure that the approach uses, even given a method of identifying it. For example, if blocking would cause substantial collateral damage.

Rationale for inclusion: Proxy creation. The circumvention system relies on proxies outside the fil- tered region to relay tra c from the client to the desired site. In response the censor can masquerade as legitimate users to discover proxy addresses and promptly block them. One way to combat this Sybil attack is to constantly create new proxies outside the filtered region. As proxies get blocked, new ones take their place.

Associated metrics:

  • use many access points

    Definition: Whether an approach uses too many hosts to make it hard for a censor to block all of them.

    Rationale for inclusion: Flashproxy uses many hosts

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

GOAL: usability

Definition: Assesses the additional effort that the circumvention tool client user must expand to use the system.

Rationale for inclusion: Section 5.2 Usability

Associated metrics:

  • no installation

    Definition: Using the tool does not require installing special software.

    Rationale for inclusion: Relay operators. On the part of Tor relay operators, the only additional requirement is to run the flash proxy server transport plugin. This is a matter of installing the plugin and adding a line to the relay's configuration file. Clients. Our programs are designed to work with the Tor pluggable transports design, so configuration is fairly easy. A user must run the transport plugin, add a few lines to the Tor configuration file, and then be able to register with the facilitator. Our transport plugin is written in Python, which is an additional requirement beyond plain Tor. If the user is not able to receive direct TCP connections, the more technical step of enabling port forwarding must be taken. A Windows installer can automate this process and we plan to build one as interest increases.

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

GOAL: usage

Definition: Assesses real world usage of an approach.

Rationale for inclusion: Test deployment (https://trac.torproject.org/projects/tor/wiki/FlashProxyHowto)

Associated metrics:

  • test deployment

    Definition: An approach proposed in an academic paper that is deployed in the real world and used by users.

    Rationale for inclusion: https://trac.torproject.org/projects/tor/wiki/FlashProxyHowto

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

SkypeMorph

For an overview, go to the top of the page. For their documentation see (URL). We believe this tool mentioned the following evaluation criteria:

GOAL: deniability under computer inspection

Definition: Whether the circumvention tool users can plausibly deny using it even when their computers are inspected.

Rationale for inclusion: Claims to not have this property: "Plausible deniability: The only way to prove that a node is actually using SkypeMorph software is to break into a user’s machine or to coerce him to divulge his information. Otherwise, communicating through SkypeMorph should look like a normal Skype video chat."

Associated metrics:

GOAL: end-user protection

Definition: Assesses whether an approach protects user's privacy from intermediate and end nodes.

Rationale for inclusion: Uses Tor for anonymity

Associated metrics:

  • hide user information from end host

    Definition: The tool hides information about the user from the end host (destination) to which the user connects to provide some degree of anonymity.

    Rationale for inclusion: Uses Tor for anonymity

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

GOAL: network performance

Definition: Assesses the system's performance in terms of goodput, latency and overhead.

Rationale for inclusion: Section 7. EXPERIMENTS, Table 1

Associated metrics:

  • byte overhead

    Definition: How many extra bytes are introduced by the tool.

    Rationale for inclusion: Table 1, "..the raw data shows that normal bridge tra c con- sistently incurs a 12% overhead, due to overheads incurred by Tor, TLS, and TCP/IP. The overhead of SkypeMorph is a little more than twice that; we incur the extra cost of sending padding when not enough data is available to fill the packet size informed by the tra c shaping oracle."

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

  • goodput

    Definition: The amount of useful throughput the tool enables.

    Rationale for inclusion: Table 1: Download speed (goodput), network bandwidth used, and overhead imposed by (a) Normal Tor-over-TCP, (b) SkypeMorph-over-UDP with naive traffic shaping, and (c) SkypeMorph-over-UDP with our enhanced Traffic Morphing

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

  • throughput

    Definition: The amount of throughput/bandwidth the tool enables.

    Rationale for inclusion: Table 1: Download speed (goodput), network bandwidth used, and overhead imposed by (a) Normal Tor-over-TCP, (b) SkypeMorph-over-UDP with naive traffic shaping, and (c) SkypeMorph-over-UDP with our enhanced Traffic Morphing

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

GOAL: openness of design

Definition: Assesses whether the source code available (client and server) and whether the design public or relies on security through obscurity.

Rationale for inclusion: Code available (https://crysp.uwaterloo.ca/software/CodeTalkerTunnel.html)

Associated metrics:

  • open source

    Definition: The tool's source code is open.

    Rationale for inclusion: Code available (https://crysp.uwaterloo.ca/software/CodeTalkerTunnel.html)

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

GOAL: resistance to blocking

Definition: A system resists blocking if it is hard to block the protocol or IP address of the infrastructure that the approach uses, even given a method of identifying it. For example, if blocking would cause substantial collateral damage.

Rationale for inclusion: "Hard to block: Since the outputs of SkypeMorph greatly resemble Skype video calls, in order to block SkypeMorph, the censor would need to block Skype calls altogether, which we assume it is unwilling to do."

Associated metrics:

  • use a popular protocol

    Definition: Whether an approach sends traffic using a popular protocol, such as the Skype protocol, to force the censor to either block a popular protocol or identify the circumventing usage of the protocol from normal usage.

    Rationale for inclusion: Uses Skype. "Hard to block: Since the outputs of SkypeMorph greatly resemble Skype video calls, in order to block SkypeMorph, the censor would need to block Skype calls altogether, which we assume it is unwilling to do."

    "Skype enables users to make free, unlimited and encrypted voice and video calls over the Internet which has led to its huge popularity [3] and therefore the amount of Skype traffic in today’s Internet is relatively high"

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

GOAL: resistance to security attacks

Definition: This criterion considers different measures that a paper uses to avoid security attacks such as man-in-the-middle, denial of service, malicious proxy, key reuse and replay attack.

Rationale for inclusion: Employing a steganographic technique, one needs to consider two major factors: the security and efficiency of the method.

Associated metrics:

  • use encryption for confidentiality

    Definition: Whether an approach uses encryption for confidentiality (and/or integrity).

    Rationale for inclusion: Skype encrypts messages using the AES cipher and uses RSA-based certificates for authentication [2, 11]. Also our experiments showed that Skype utilizes some form of message authentication and would not accept altered messages. Thus an eavesdropper is neither able to access the content of a packet nor can he alter them in such a way that is not detectable.

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

GOAL: resistance to traffic analysis

Definition: An approach is resistant to traffic analysis if an adversary cannot statically use properties of the traffic generated by the approach to detect it. (Some of the metrics used for this goal can also be used for active probing, but they are not inherently active.)

Rationale for inclusion: Introduction: Tor traffic obfuscation: SkypeMorph disguises communication between the bridge and the client as a Skype video call, which is our target protocol. Protocol obfuscation is greatly needed when facing large-scale censorship mechanisms, such as deep packet inspection.

Associated metrics:

  • inter-packet timing

    Definition: Measures the distribution of packet timing (interpacket times or packet rates) to assess whether it is unlike that of a blocked protocol, or like that of an allowed protocol.

    Rationale for inclusion: SkypeMorph: Section 1.1: "Improved traffic shaping... SkypeMorph extends the previous work to fully reproduce the characteristics of Skype calls." Section 5.2: "Traffic Shaping. The modification is done on the packet sizes and inter-arrival times of consecutive packets." Section 7: "Experiments. ...the Kolmogorov-Smirnov test for both the packet sizes and inter-packet delays shows no statistically signicant difference." Appendix of extended TR at http://cacr.uwaterloo.ca/techreports/2012/cacr2012-08.pdf considers higher-order statistics.

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

  • packet size distribution

    Definition: Measures the distribution of packet lengths to assess wehether it is unlike that of a blocked protocol, or like that of an allowed protocol.

    Rationale for inclusion: SkypeMorph: Section 1.1: "Improved traffic shaping... SkypeMorph extends the previous work to fully reproduce the characteristics of Skype calls." Section 5.2: "Traffic Shaping. The modification is done on the packet sizes and inter-arrival times of consecutive packets." Section 7: "Experiments. ...the Kolmogorov-Smirnov test for both the packet sizes and inter-packet delays shows no statistically signicant difference." Appendix of extended TR at http://cacr.uwaterloo.ca/techreports/2012/cacr2012-08.pdf considers higher-order statistics.

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

  • use encryption to resist traffic analysis

    Definition: Whether an approach uses encryption to resist traffic analysis.

    Rationale for inclusion: We argue that on an encrypted communication such as those of Skype calls, every message appears to be random (since we expect the encryption scheme to output a randomly distributed bit string), thus exploiting the channel history is not required for cover traffic and we can perform significantly better than the OneBlock stegosystem, Collage, or TranSteg. The only important characteristics of encrypted channels, as suggested by previous works, are packet sizes and inter-arrival times of consecutive packets [12, 29, 20]. Hence, a protocol obfuscation layer only needs to reproduce these features for an encrypted channel.

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

GOAL: resistance to traffic manipulation

Definition: Evaluates the system's resistance to modification of packets, or injecting or dropping packets. This criterion is concerned only with manipulation of client-initiated flows.

Rationale for inclusion: The first 8 bytes are an HMAC-SHA256-64 message authentication code for the remaining bytes in the packet.

Associated metrics:

  • use UDP with reliability

    Definition: Whether an approach uses UDP with reliability.

    Rationale for inclusion: Between smclient and smserver, bytes in Tor streams are exchanged in segments by a simple reliable transmission mechanism over encrypted UDP communication, and they are identified by sequence numbers. Reliable transmission is supported by acknowledgments over sequence numbers.

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

StegoTorus

For an overview, go to the top of the page. For their documentation see (URL). We believe this tool mentioned the following evaluation criteria:

GOAL: end-user protection

Definition: Assesses whether an approach protects user's privacy from intermediate and end nodes.

Rationale for inclusion: "StegoTorus preserves Tor\u2019s basic design goals: Unlinkability:\ \ The censor should not be able to determine which Internet users communicate\ \ with which remote hosts via Tor.\n"

Associated metrics:

  • hide user information from end host

    Definition: The tool hides information about the user from the end host (destination) to which the user connects to provide some degree of anonymity.

    Rationale for inclusion: StegoTorus preserves Tor’s basic design goals: Unlinkability: The censor should not be able to determine which Internet users communicate with which remote hosts via Tor.

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

GOAL: network performance

Definition: Assesses the system's performance in terms of goodput, latency and overhead.

Rationale for inclusion: Section 6. PERFORMANCE

Associated metrics:

  • goodput

    Definition: The amount of useful throughput the tool enables.

    Rationale for inclusion: Stegotorus measures mean goodput by downloading different files of 100 kB to 1 MB size (section 6).

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

  • latency

    Definition: Assesses the round-trip time for a request.

    Rationale for inclusion: Stegotorus computes Round-trip latency (ms)

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

GOAL: openness of design

Definition: Assesses whether the source code available (client and server) and whether the design public or relies on security through obscurity.

Rationale for inclusion: Code available (https://sri-csl.github.io/stegotorus/)

Associated metrics:

  • open source

    Definition: The tool's source code is open.

    Rationale for inclusion: Code available (https://sri-csl.github.io/stegotorus/)

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

GOAL: resistance to blocking

Definition: A system resists blocking if it is hard to block the protocol or IP address of the infrastructure that the approach uses, even given a method of identifying it. For example, if blocking would cause substantial collateral damage.

Rationale for inclusion: Section 2.1 Design Goals, Unblockability: The censor should not be able to block StegoTorus without also blocking a great deal of unrelated traffic.

Associated metrics:

GOAL: resistance to traffic analysis

Definition: An approach is resistant to traffic analysis if an adversary cannot statically use properties of the traffic generated by the approach to detect it. (Some of the metrics used for this goal can also be used for active probing, but they are not inherently active.)

Rationale for inclusion: "To foil analysis of packet contents, Tor\u2019\ s traffic is steganographed to resemble an innocuous cover protocol, such\ \ as HTTP. To foil analysis at the transport level, the Tor circuit is distributed\ \ over many shorter-lived connections with per-packet characteristics that\ \ mimic cover-protocol traffic. Our evaluation demonstrates that StegoTorus\ \ improves the resilience of Tor to fingerprinting attacks and delivers usable\ \ performance.\n" Section 2.2.2 Limits on the Censor: "Since we anticipate that StegoTorus servers will be aggressively blocked with address filters, we are developing a “rendezvous” mechanism for distributing server address updates to StegoTorus users [45]. In this paper we assume that the user knows contact information for server(s) that have not yet been blocked."

Associated metrics:

  • connection length

    Definition: Measures the duration of flows (e.g., TCP connections) and evaluates whether the duration can be a distinguisher. (If a connection is suspiciously long, for example.)

    Rationale for inclusion: StegoTorus measured the length of connections to the top 10 Alexa sites (Figure 4).

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

  • packet size distribution

    Definition: Measures the distribution of packet lengths to assess wehether it is unlike that of a blocked protocol, or like that of an allowed protocol.

    Rationale for inclusion: StegoTorus: Section 5.1: Compared to the characteristic distribution of 586-byte packets of Tor, and to lengths in a CAIDA trace. Use an O(1) exponential average with a threshold.

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

  • use encryption to resist traffic analysis

    Definition: Whether an approach uses encryption to resist traffic analysis.

    Rationale for inclusion: MISSING_RATIONALE

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

Dust

For an overview, go to the top of the page. For their documentation see (URL). We believe this tool mentioned the following evaluation criteria:

GOAL: openness of design

Definition: Assesses whether the source code available (client and server) and whether the design public or relies on security through obscurity.

Rationale for inclusion: Code available (https://github.com/blanu/Dust)

Associated metrics:

  • open source

    Definition: The tool's source code is open.

    Rationale for inclusion: Code available (https://github.com/blanu/Dust)

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

GOAL: resistance to security attacks

Definition: This criterion considers different measures that a paper uses to avoid security attacks such as man-in-the-middle, denial of service, malicious proxy, key reuse and replay attack.

Rationale for inclusion: Section 3, Discussion: Additionally, protection is provided against a number of specific attacks on the protocol. Packet corruption is defeated by use of a MAC. Replay attacks are defeated within a certain time window by use of a timestamp. Brute force decryption of invite packets are defeated by use of salt and a PBKDF.

Associated metrics:

  • use timestamp (replay)

    Definition: Whether an approach uses timestamp to resist replay attack.

    Rationale for inclusion: Dust: Section 2 "Packet Format": "The ciphertext includes a timestamp to protect against replay attacks." "The ciphertext includes a timestamp to protect against replay attacks, " "Replay attacks are defeated within a certain time window by use of a timestamp. "

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

GOAL: resistance to traffic analysis

Definition: An approach is resistant to traffic analysis if an adversary cannot statically use properties of the traffic generated by the approach to detect it. (Some of the metrics used for this goal can also be used for active probing, but they are not inherently active.)

Rationale for inclusion: The goal of Dust is to provide a transport protocol which cannot be filtered with DPI. To accomplish this goal it must not be vulnerable to fingerprinting using static string matching, packet length comparison, or timing profiling.

Associated metrics:

  • inter-packet timing

    Definition: Measures the distribution of packet timing (interpacket times or packet rates) to assess whether it is unlike that of a blocked protocol, or like that of an allowed protocol.

    Rationale for inclusion: Section 3, Discussion: "By allow for a full conversation to be transmitted in a single UDP or TCP packet, timing attacks are defeated in the case of sufficiently small messages."

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

  • packet size distribution

    Definition: Measures the distribution of packet lengths to assess wehether it is unlike that of a blocked protocol, or like that of an allowed protocol.

    Rationale for inclusion: Dust: Section 3 "Discussion": "By randomizing packet length, length matching is defeated."

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

  • use encryption to resist traffic analysis

    Definition: Whether an approach uses encryption to resist traffic analysis.

    Rationale for inclusion: Section 3 Design: The Dust protocol is designed to protect against an attacker that utilizes Deep Packet Inspection (DPI) to fingerprint protocols for the purpose of blocking or rate limiting connections. In order to establish protocol unobservability, all packets consist entirely of encrypted or random single-use bytes so as to be indistinguishable from each other and random packets.

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

OSS

For an overview, go to the top of the page. For their documentation see (URL). We believe this tool mentioned the following evaluation criteria:

GOAL: availability of infrastructure

Definition: This criterion considers the availability of the infrastructure used by an approach for users and the feasibility of deployment.

Rationale for inclusion: Section 3 is a short catalog of online scanning services and states that there are many more and they are easy to find.

Associated metrics:

  • preponderance of suitable servers

    Definition: Some tools rely on finding servers with a specific property at large in the Internet. For example, servers that accept user-posted content, or servers with specific network protocol quirks. This criterion means that the study measured how common such servers really are.

    Rationale for inclusion: OSS: Section 3 is a short catalog of online scanning services and states that there are many more and they are easy to find.

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

GOAL: end-user protection

Definition: Assesses whether an approach protects user's privacy from intermediate and end nodes.

Rationale for inclusion: Section 7: Eavesdropping by the OSS. Our threat model assumes that the OSS is not colluding with the censor; however it is not necessarily a trusted entity. An OSS can intercept all communications between the user and the cooperating proxy. In this sense the OSS resembles an ISP, Tor entry relay, or other network router that lies on the path between the user and the cooperating proxy. Traffic should be encrypted and authenticated, as the Tor protocol is, to prevent eavesdropping and tampering by the OSS.

Associated metrics:

  • hide user information from end host

    Definition: The tool hides information about the user from the end host (destination) to which the user connects to provide some degree of anonymity.

    Rationale for inclusion: Section 7: Eavesdropping by the OSS. Our threat model assumes that the OSS is not colluding with the censor; however it is not necessarily a trusted entity. An OSS can intercept all communications between the user and the cooperating proxy. In this sense the OSS resembles an ISP, Tor entry relay, or other network router that lies on the path between the user and the cooperating proxy. Traffic should be encrypted and authenticated, as the Tor protocol is, to prevent eavesdropping and tampering by the OSS.

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

GOAL: network performance

Definition: Assesses the system's performance in terms of goodput, latency and overhead.

Rationale for inclusion: Section 5.2 Throughput Measurements

Associated metrics:

  • goodput

    Definition: The amount of useful throughput the tool enables.

    Rationale for inclusion: 5.2 Throughput Measurements

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

GOAL: openness of design

Definition: Assesses whether the source code available (client and server) and whether the design public or relies on security through obscurity.

Rationale for inclusion: Code available (https://gitweb.torproject.org/user/dcf/oss.git)

Associated metrics:

  • open source

    Definition: The tool's source code is open.

    Rationale for inclusion: Code available (https://gitweb.torproject.org/user/dcf/oss.git)

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

GOAL: resistance to blocking

Definition: A system resists blocking if it is hard to block the protocol or IP address of the infrastructure that the approach uses, even given a method of identifying it. For example, if blocking would cause substantial collateral damage.

Rationale for inclusion: "We show that OSSes are widely available on the Internet and blocking all of them can be difficult and harmful."

Associated metrics:

  • use many access points

    Definition: Whether an approach uses too many hosts to make it hard for a censor to block all of them.

    Rationale for inclusion: OSS uses large number of available webhosts.

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

GOAL: resistance to security attacks

Definition: This criterion considers different measures that a paper uses to avoid security attacks such as man-in-the-middle, denial of service, malicious proxy, key reuse and replay attack.

Rationale for inclusion: Section 7 Security Analysis

Associated metrics:

  • use encryption for confidentiality

    Definition: Whether an approach uses encryption for confidentiality (and/or integrity).

    Rationale for inclusion: MISSING_RATIONALE

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

GOAL: resistance to traffic analysis

Definition: An approach is resistant to traffic analysis if an adversary cannot statically use properties of the traffic generated by the approach to detect it. (Some of the metrics used for this goal can also be used for active probing, but they are not inherently active.)

Rationale for inclusion: Section 7 Security Analysis considers Incoming connections, URL pattern, Number of redirects, Number of outgoing connections

Associated metrics:

  • serial connection count

    Definition: Counted the number of connections made in a row to a server.

    Rationale for inclusion: OSS strings together the contents of many HTTP requests to one server. Section 7: "Number of outgoing connections... An large number of outgoing connections may be suspicious."

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

Marionette

For an overview, go to the top of the page. For their documentation see (URL). We believe this tool mentioned the following evaluation criteria:

GOAL: adaptability to blocking

Definition: Assesses the system's resilience to unexpected blocking events and new kinds of blocking.

Rationale for inclusion: Despite the progress these obfuscation systems represent, each of them suffers from one or more shortcomings that severely limit their ability to adapt to new network environments or censorship strategies.

Marionette is a network-traffic obfuscation system that empowers users to rapidly explore a rich design space, without the need to deploy new code or re-design the underlying system.

Associated metrics:

GOAL: network performance

Definition: Assesses the system's performance in terms of goodput, latency and overhead.

Rationale for inclusion: Section 7.6 Performance

Associated metrics:

  • goodput

    Definition: The amount of useful throughput the tool enables.

    Rationale for inclusion: Marionette Section 7: "Downstream and upstream goodput was measured by transmitting a 1MB file, and averaged across 100 trials." Figure 2: "High Throughput."

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

  • time overhead

    Definition: How much extra time it takes to use the tool.

    Rationale for inclusion: Figure 11: Summary of case study formats and time spent blocking on network I/O for both client and server.

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

GOAL: openness of design

Definition: Assesses whether the source code available (client and server) and whether the design public or relies on security through obscurity.

Rationale for inclusion: Marionette Introduction: "To encourage adoption and use of Marionette it has been made available as free and open source software."

Associated metrics:

  • open source

    Definition: The tool's source code is open.

    Rationale for inclusion: Code available (https://github.com/marionette-tg/marionette)

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

GOAL: resistance to active probing

Definition: Active probing attacks involve the censor initiating connections to hosts to determine whether the host runs a given circumvention protocol, typically then blocking the host's IP address upon finding that it does. A system is resistant to active probing if an adversary cannot discover the use of the system using this technique.

Rationale for inclusion: MARIONETTE: Introduction: "...the automata admit distinguished error states, thereby providing an explicit mechanism for handling active attacks, such as censor-initiated "probing attacks."

Associated metrics:

  • respond to probes like something else

    Definition: When probed, respond similar to how some allowed server would respond so that a censor deciding to block such responses will incur false positives.

    Rationale for inclusion: MARIONETTE allows for error states that fall back to normal application-layer traffic if a malformed message is received. They discuss mimicking real servers like Apache. MARIONETTE: Introduction: "...the automata admit distinguished error states, thereby providing an explicit mechanism for handling active attacks, such as censor-initiated "probing attacks." Section 7.5.1: " This error transition is traversed if all other potential transitions encounter fatal errors in their action blocks, which occur if an invalid message is received." If the client uses the wrong key (Section 6.1) it also induces an error transition."

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

GOAL: resistance to blocking

Definition: A system resists blocking if it is hard to block the protocol or IP address of the infrastructure that the approach uses, even given a method of identifying it. For example, if blocking would cause substantial collateral damage.

Rationale for inclusion: Another popular approach is to mimic certain characteristics of popular protocols, such as HTTP or Skype, so that blocking traffic with those characteristics would result in significant collateral damage.

That is, even a tiny false positive rate can generate an overwhelming amount of collateral damage when we consider traffic volumes in the 1 Gbps range.

Associated metrics:

GOAL: resistance to traffic analysis

Definition: An approach is resistant to traffic analysis if an adversary cannot statically use properties of the traffic generated by the approach to detect it. (Some of the metrics used for this goal can also be used for active probing, but they are not inherently active.)

Rationale for inclusion: Section 7.4 Traffic Analysis Resistance

Associated metrics:

  • concurrent connection count

    Definition: They measured the number of simultaneous connections to a server.

    Rationale for inclusion: Marionette Section 7.4: "Simultaneously active connections" and compared with 10 download of amazon using Firefox 35.

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

  • number of HTTP requests/responses

    Definition: Measures the total number of HTTP request-response pairs per TCP connection.

    Rationale for inclusion: Figure 8.b

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

  • protocol misclassification rate

    Definition: Assesses the misclassification rate of the protocol classifiers to see how well the tool can evade the classifiers.

    Rationale for inclusion: Figure 7: Summary of misclassification using existing FTE for- mats for HTTP, SSH, and SMB.

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

  • serial connection count

    Definition: Counted the number of connections made in a row to a server.

    Rationale for inclusion: Marionette Section 7.4: "Messages per TCP connection" (which implies "TCP connections per message").

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

  • total TCP connection

    Definition: The total number of TCP connections per session does not stick out.

    Rationale for inclusion: Figure 8.a (Figure 8: A comparison of the aggregate traffic features for ten downloads of amazon.com using Firefox 35, compared to the traffic generated by ten executions of the Marionette model mimicking amazon.com.)

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

  • total payload length

    Definition: The total payload length produced by the tool does not stick out.

    Rationale for inclusion: Figure 8.c

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

FreeWave

For an overview, go to the top of the page. For their documentation see (URL). We believe this tool mentioned the following evaluation criteria:

GOAL: availability of infrastructure

Definition: This criterion considers the availability of the infrastructure used by an approach for users and the feasibility of deployment.

Rationale for inclusion: Deployment feasibility: An important feature of a circumvention system is the amount of resources (e.g., hardware, network bandwidth, etc.) required for it to be deployed in real world. A circumvention system is also desired to have few dependencies on other systems and entities in order to make it more reliable, secure, and cost-effective.

Associated metrics:

  • independent deployment

    Definition: Can deploy the circumvention approach without needing the help of third-parties, such as friendly ISPs.

    Rationale for inclusion: Deployment feasibility: The real-world deployment of FreeWave does not rely on other entities. This is in contrast to some recent designs that need collaboration from third parties for their operation. For instance, Infranet [5] requires support from some web destinations that host the circumvention servers. As another example, several recent proposals [10], [11], [51] rely on the collaboration from friendly ISPs for their operation.

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

GOAL: end-user protection

Definition: Assesses whether an approach protects user's privacy from intermediate and end nodes.

Rationale for inclusion: A FreeWave server only knows the VoIP IDs of its client, but not their IP addresses since the VoIP connections are being relayed through intermediate VoIP nodes. As a result, unless the VoIP service (e.g., the Google Voice server, or a Skype supernode owned by a FreeWave server) is colluding with the FreeWave server, the FreeWave server will not be able to link VoIP IDs to IP addresses, i.e., the client is anonymous to the server.

Associated metrics:

  • hide user information from end host

    Definition: The tool hides information about the user from the end host (destination) to which the user connects to provide some degree of anonymity.

    Rationale for inclusion: A FreeWave server only knows the VoIP IDs of its client, but not their IP addresses since the VoIP connections are being relayed through intermediate VoIP nodes. As a result, unless the VoIP service (e.g., the Google Voice server, or a Skype supernode owned by a FreeWave server) is colluding with the FreeWave server, the FreeWave server will not be able to link VoIP IDs to IP addresses, i.e., the client is anonymous to the server.

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

GOAL: network performance

Definition: Assesses the system's performance in terms of goodput, latency and overhead.

Rationale for inclusion: Section VIII. PROTOTYPE AND EVALUATION

Associated metrics:

  • goodput

    Definition: The amount of useful throughput the tool enables.

    Rationale for inclusion: Table I EVALUATION RESULTS OF FREEWAVE.

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

  • latency

    Definition: Assesses the round-trip time for a request.

    Rationale for inclusion: Two important factors are connection bandwidth, and browsing latency.

GOAL: resistance to blocking

Definition: A system resists blocking if it is hard to block the protocol or IP address of the infrastructure that the approach uses, even given a method of identifying it. For example, if blocking would cause substantial collateral damage.

Rationale for inclusion: FREEWAVE calls it "server obfuscation": "...prevents censors from detecting circumvented traffic by matching the destination addresses of traffic." "even if a censor identifies the IP address belonging to a FreeWave server it will not be able to block connections to it since users' connection to that FreeWave server are not direct connections, but are relayed through varying, oblivious VoIP nodes."

Associated metrics:

  • use a popular protocol

    Definition: Whether an approach sends traffic using a popular protocol, such as the Skype protocol, to force the censor to either block a popular protocol or identify the circumventing usage of the protocol from normal usage.

    Rationale for inclusion: We implement a prototype of FreeWave over the popular VoIP service of Skype

    VoIP constitutes an important part of today’s Internet communications [36]–[38]; a recent report [37] shows that about one-third of U.S. businesses use VoIP solutions to reduce their telecommunications expenses, and the report predicts the VoIP penetration to reach 79% by 2013, a 50% increase compared to 2009.

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

  • use many access points

    Definition: Whether an approach uses too many hosts to make it hard for a censor to block all of them.

    Rationale for inclusion: FreeWave’s availability is tied to the availability of the VoIP service: since the operation of FreeWave is not bound to a specific VoIP provider, in order to block FreeWave a censor needs to block all VoIP connections with the outside world.

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

GOAL: resistance to security attacks

Definition: This criterion considers different measures that a paper uses to avoid security attacks such as man-in-the-middle, denial of service, malicious proxy, key reuse and replay attack.

Rationale for inclusion: Section VI. SECURITY ANALYSIS

Associated metrics:

  • limit service to each user ID (DoS)

    Definition: Avoid DoS by limiting the amount of service the approach will provide to each user.

    Rationale for inclusion: FreeWave: Section XI: "Denial of service." "Different approaches can be taken to limit the effect of such attempts such as the existing sybil defense mechanisms [69], as well as usage limitation enforcement per VoIP caller."

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

  • use trustworthy proxy

    Definition: By using a trustworthy proxy as the forwarder, the approach avoids the risks of a malicious proxy (as long as the proxy remains trustworthy).

    Rationale for inclusion: FreeWave: Section VI.C.: "Security against VoIP providers." Section XI: "Trusting the VoIP provider." "Security against VoIP providers Except for the centralized VoIP services, the VoIP connec- tions between FreeWave clients and servers are encrypted end-to-end using the keys shared through the VoIP protocol. In the case of a centralized VoIP service, like the Google Voice, FreeWave parties can exchange a key using a key sharing mechanism, like the Diffie-Hellman key exchange [52], over the established FreeWave VoIP. As a result, the VoIP provider will not be able to observe the data being communicated, nor the web destinations being browsed. However, the VoIP service provider might be able to identify VoIP IDs that have made VoIP calls to a FreeWave server. As a result, in order to ensure its unobservability FreeWave needs to use VoIP providers that are not colluding with the censors. Note that FreeWave does not rely on a particular VoIP system and any VoIP provider can be used for its operation."

    "Trusting the VoIP provider: A VoIP provider colluding with censors can significantly degrade FreeWave's obfusca- tion promises if FreeWave deploys it. On the bright side, FreeWave can choose from a wide range of VoIP providers. In the case of Skype, in particular, Chinese Skype users get provided with a special implementation of Skype, TOM- Skype, which is suspected [64] to have built-in surveillance functionalities such as text message filtering [65]--[68]."

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

GOAL: resistance to traffic analysis

Definition: An approach is resistant to traffic analysis if an adversary cannot statically use properties of the traffic generated by the approach to detect it. (Some of the metrics used for this goal can also be used for active probing, but they are not inherently active.)

Rationale for inclusion: Section VIII.C. Traffic analysis

Associated metrics:

  • inter-packet timing

    Definition: Measures the distribution of packet timing (interpacket times or packet rates) to assess whether it is unlike that of a blocked protocol, or like that of an allowed protocol.

    Rationale for inclusion: FreeWave: Section VIII.C., "Traffic analysis": "The two traffic patterns that may be used for traffic analysis in this case are packet rates and packet sizes." Section IX: "Traffic analysis."

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

GOAL: server obfuscation

Definition: Keeping the server used as a forwarder by the circumvention network hidden from the censor.

Rationale for inclusion: The second obfuscation performed by FreeWave, which is unique to FreeWave, is server obfuscation, which prevents censors from detecting circumvented traffic by matching the destination addresses of traffic. [...] As we describe later in this paper, the way the FreeWave server is connected to the Internet results in getting FreeWave's VoIP traffic relayed by various, oblivious VoIP peers, preventing a censor from blocking/identifying

Associated metrics:

  • indirect connection to forwarder

    Definition: The circumventor's computer connects indirectly to the circumvention network's forwarders through an innocuous server.

    Rationale for inclusion: The second obfuscation performed by FreeWave, which is unique to FreeWave, is server obfuscation, which prevents censors from detecting circumvented traffic by matching the destination addresses of traffic. [...] As we describe later in this paper, the way the FreeWave server is connected to the Internet results in getting FreeWave's VoIP traffic relayed by various, oblivious VoIP peers, preventing a censor from blocking/identifying

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

SWEET

For an overview, go to the top of the page. For their documentation see (URL). We believe this tool mentioned the following evaluation criteria:

GOAL: adaptability to blocking

Definition: Assesses the system's resilience to unexpected blocking events and new kinds of blocking.

Rationale for inclusion: Section 5.2 Availability: IP filtering and DNS hijacking techniques would not be able to stop SWEET traffic as a SWEET user’s traffic is destined to her public email provider, but not to an IP address or nameserver belonging to SWEET system. Another technique used by today’s sophisticated censors is deep packet inspection (DPI). The use of encryption-enabled email renders DPI ineffective, as the email headers get encrypted and the DPI will not be able to analyze the email headers in order to detect the email addresses of SWEET, to hence block the traffic. In the case of plaintext emails, to defeat DPI SWEET server can provide different email aliases to different users or to change its public email address frequently. Note that generating email aliases has no cost for SWEET server and can be done with no limit. In the worst case, a user can obtain her specialized email address through an out of band channel, or by connecting through a encryption-enabled email account (as mentioned before the DPI is ineffective on encryption- enabled emails).

Associated metrics:

GOAL: availability of infrastructure

Definition: This criterion considers the availability of the infrastructure used by an approach for users and the feasibility of deployment.

Rationale for inclusion: Section 5.2 Availability: SWEET’s availability is tied to the assumption dis- cussed previously that a censor is not willing to block all email communications, as it would degrade the usability of the Internet for its users. As the use of SWEET does not require an email account with any specific email provider, users can always find an email service to get connected to SWEET.

Associated metrics:

GOAL: infrastructure cost

Definition: Assesses the cost of infrastructure required to deploy an approach in real world.

Rationale for inclusion: Section 5.3 Other properties of SWEET (Ease of deployment)

Associated metrics:

  • cost of external services

    Definition: Estimates the cost of external services, e.g., cloud services, CDNs, that are required to deploy an approach.

    Rationale for inclusion: Ease of deployment: We argue that SWEET can be easily deployed on the Internet and provide service to a wide range of users. First of all, SWEET is low-cost and needs few resources for deployment. It can be de- ployed using a single server that runs a few light-weight processes, including a mail server and a SOCKS proxy. To service in a large scale SWEET server can be de- ployed in a distributed manner by several machines in different geographic locations. Secondly, the operation of SWEET is standalone and does not rely on collabo- ration from other entities, e.g., end-hosts or ISPs. This provides a significant advantage to recent research that relies on collaboration from ISPs [20, 24, 37], or end- hosts [9, 18]. In fact, the easy setup and low-resources of SWEET’s deployment allows it to be implemented by individuals with different levels of technical exper- tise.

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

GOAL: network performance

Definition: Assesses the system's performance in terms of goodput, latency and overhead.

Rationale for inclusion: Section 7. EVALUATION

Associated metrics:

  • latency

    Definition: Assesses the round-trip time for a request.

    Rationale for inclusion: Sweet measures the end-to-end web browsing latency for the client to reach different web destinations.

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

  • number of requests needed to retrieve data

    Definition: Assesses the number of requests that a requester must make to retrieve hidden messages.

    Rationale for inclusion: 7.2 Traffic analysis (Fig. 11. The number of emails sent and received by a SWEET client to get one of the websites from Alexa’s top ten ranking.)

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

  • speed of downloading a webpage

    Definition: Assesses the time required to download a webpage. This is really a combination of goodput and latency, but it is specifically applied so often that we made it its own criterion.

    Rationale for inclusion: Figure 9: The CDF of the TBT time using SWEET.

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

GOAL: resistance to blocking

Definition: A system resists blocking if it is hard to block the protocol or IP address of the infrastructure that the approach uses, even given a method of identifying it. For example, if blocking would cause substantial collateral damage.

Rationale for inclusion: SWEET provides several key advantages as compared to the existing circumvention systems. First, since email is an essential service in today’s Internet it is very unlikely that a censorship authority will block all email communications to the outside world, due to different financial and political reasons. This, along the fact that SWEET can be reached through any email service, pro- vides a high degree of availability for SWEET since a censor will need to block all email traffic to the Inter- net in order to block SWEET.

Associated metrics:

  • use a popular protocol

    Definition: Whether an approach sends traffic using a popular protocol, such as the Skype protocol, to force the censor to either block a popular protocol or identify the circumventing usage of the protocol from normal usage.

    Rationale for inclusion: "First, since email is an essential service in today’s Internet it is very unlikely that a censorship authority will block all email communications to the outside world, due to different financial and political reasons. This, along the fact that SWEET can be reached through any email service, provides a high degree of availability for SWEET since a censor will need to block all email traffic to the Internet in order to block SWEET. "

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

GOAL: resistance to security attacks

Definition: This criterion considers different measures that a paper uses to avoid security attacks such as man-in-the-middle, denial of service, malicious proxy, key reuse and replay attack.

Rationale for inclusion: "As another approach for disrupting the operation of SWEET, a censor might try to launch a denial-of-service (DoS) attack on SWEET server. The common tech- niques for DoS attacks, e.g., ICMP flooding and SYN flooding, can be mitigated by protecting the SWEET server using up-to-date firewalls. Alternatively, a ma- licious entity (e.g., a censor) can try to exhaust the SWEET service by sending disruptive traffic through the email communication channel of SWEET. In other words, a censor can play the role of a SWEET client and send Internet traffic through its SWEET client software in a way that breaks or overloads the SWEET server. As an example, the attacker can flood the SWEET’s SOCKS proxy by initiating many incomplete SOCKS connections, or sending SYN floods. A censor could send such attacking requests on behalf of a number of rogue (non-existing) email addresses, to render an email blacklist maintained by SWEET server ineffective in preventing such attacks. As a result, SWEET server should deploy effective mechanisms to protect against possible DoS attacks. One effective mechanism is to require a new user to register her email address with SWEET server prior to her first use of SWEET. Such registration can be performed in an unobservable man- ner by SWEET’s client software through the email com- munication channel (see Section 4.1). Also, to ensure the quality of service for all users, the SWEET server can limit the use of SWEET by putting a cap on the volume of traffic communicated by each registered email address."

Associated metrics:

  • limit service to each user ID (DoS)

    Definition: Avoid DoS by limiting the amount of service the approach will provide to each user.

    Rationale for inclusion: "As another approach for disrupting the operation of SWEET, a censor might try to launch a denial-of-service (DoS) attack on SWEET server. The common tech- niques for DoS attacks, e.g., ICMP flooding and SYN flooding, can be mitigated by protecting the SWEET server using up-to-date firewalls. Alternatively, a ma- licious entity (e.g., a censor) can try to exhaust the SWEET service by sending disruptive traffic through the email communication channel of SWEET. In other words, a censor can play the role of a SWEET client and send Internet traffic through its SWEET client software in a way that breaks or overloads the SWEET server. As an example, the attacker can flood the SWEET’s SOCKS proxy by initiating many incomplete SOCKS connections, or sending SYN floods. A censor could send such attacking requests on behalf of a number of rogue (non-existing) email addresses, to render an email blacklist maintained by SWEET server ineffective in preventing such attacks. As a result, SWEET server should deploy effective mechanisms to protect against possible DoS attacks. One effective mechanism is to require a new user to register her email address with SWEET server prior to her first use of SWEET. Such registration can be performed in an unobservable man- ner by SWEET’s client software through the email com- munication channel (see Section 4.1). Also, to ensure the quality of service for all users, the SWEET server can limit the use of SWEET by putting a cap on the volume of traffic communicated by each registered email address."

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

  • use client puzzle (DoS)

    Definition: Require clients to solve a puzzle to prevent DoS.

    Rationale for inclusion: SWEET: Each client has to register "to prevent denial-of-service (DoS) attacks " "For any new registration request, the registration agent generates and sends an email to the requesting email address (through the email agent) that contains a unique computational challenge"

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

GOAL: resistance to traffic analysis

Definition: An approach is resistant to traffic analysis if an adversary cannot statically use properties of the traffic generated by the approach to detect it. (Some of the metrics used for this goal can also be used for active probing, but they are not inherently active.)

Rationale for inclusion: Section 7.2 Traffic analysis

Associated metrics:

GOAL: usability

Definition: Assesses the additional effort that the circumvention tool client user must expand to use the system.

Rationale for inclusion: "User convenience: As mentioned before, a recent study [10] surveying the use of circumvention tools in censored countries shows that users give the most pref- erence to the ease of use when choosing a circumvention tool. The use of SWEET is simple and requires few resources from a client. A SWEET client only needs to install the provided client software, that can be ob- tained from out-of-band channels like social networks or downloaded from the Internet. Due to its simple de- sign, an expert user can also develop the client software herself. In addition to SWEET software, the user needs to have an email account with a public email provider, and needs to know the public information related to SWEET, e.g., the email addresses of SWEET. "

Associated metrics:

Facade

For an overview, go to the top of the page. For their documentation see (URL). We believe this tool mentioned the following evaluation criteria:

GOAL: adaptability to blocking

Definition: Assesses the system's resilience to unexpected blocking events and new kinds of blocking.

Rationale for inclusion: Robust: The tool should be able to continue operation despite attacks from the censor.

Associated metrics:

GOAL: network performance

Definition: Assesses the system's performance in terms of goodput, latency and overhead.

Rationale for inclusion: Section 5.2 Performance Evaluation

Associated metrics:

  • byte overhead

    Definition: How many extra bytes are introduced by the tool.

    Rationale for inclusion: Entropy of Facade encodings. Using standard entropy calculations, we can quantify the maximum amount of information that Facade can encode in a single HTTP request and still remain deniable. Using the AOL search corpus [8], we calculated that the average length of a search query was 17.83 bytes and that each byte has an entropy of 2.28 bits. Thus, a search query can encode 40.65 bits of information while maintaining deniability.

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

  • latency

    Definition: Assesses the round-trip time for a request.

    Rationale for inclusion: Real-time: Latency between the client and server should be at most on the order of seconds.

GOAL: openness of design

Definition: Assesses whether the source code available (client and server) and whether the design public or relies on security through obscurity.

Rationale for inclusion: Code available (https://github.com/ben-jones/facade)

Associated metrics:

  • open source

    Definition: The tool's source code is open.

    Rationale for inclusion: Code available (https://github.com/ben-jones/facade)

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

GOAL: resistance to active probing

Definition: Active probing attacks involve the censor initiating connections to hosts to determine whether the host runs a given circumvention protocol, typically then blocking the host's IP address upon finding that it does. A system is resistant to active probing if an adversary cannot discover the use of the system using this technique.

Rationale for inclusion: FACADE: 2 Threat Model: "Active identification, on the other hand, includes probing and scanning potential Facade clients and servers; for example, an attacker might actively probe clients or modify traffic to determine how clients respond to error conditions."

Associated metrics:

  • use authentication

    Definition: Whether a client needs authentication to connect to the server.

    Rationale for inclusion: Facade Section 5.1 "Active attacks": "Server discovery via session initiation probing. The censor cannot detect Facade servers with active scanning that attempts to initiate Facade sessions because Facade uses a pre-shared secret for authentication.

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

GOAL: resistance to blocking

Definition: A system resists blocking if it is hard to block the protocol or IP address of the infrastructure that the approach uses, even given a method of identifying it. For example, if blocking would cause substantial collateral damage.

Rationale for inclusion: Blacklisting and filtering. A censor could block traffic using IP or port blacklists. Deploying Facade on legitimate web servers would make it difficult for a censor to deploy a blacklist that blocks Facade, presuming that the censor does not want to also block access to the legitimate site and the legitimate site has sufficient cover search traffic.

Associated metrics:

  • use a popular protocol

    Definition: Whether an approach sends traffic using a popular protocol, such as the Skype protocol, to force the censor to either block a popular protocol or identify the circumventing usage of the protocol from normal usage.

    Rationale for inclusion: Web service protocols are ubiquitous, so there is significant legitimate traffic for each protocol, making this covert channel more difficult to distinguish.

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

  • use popular hosts

    Definition: Whether an approach uses popular hosts, such as Skype nodes and CDNs, to resist address blocking.

    Rationale for inclusion: Blacklisting and filtering. A censor could block traffic using IP or port blacklists. Deploying Facade on legitimate web servers would make it difficult for a censor to deploy a blacklist that blocks Facade, presuming that the censor does not want to also block access to the legitimate site and the legitimate site has sufficient cover search traffic.

GOAL: resistance to security attacks

Definition: This criterion considers different measures that a paper uses to avoid security attacks such as man-in-the-middle, denial of service, malicious proxy, key reuse and replay attack.

Rationale for inclusion: Section 5.1 Security Evaluation

Associated metrics:

  • use timestamp (replay)

    Definition: Whether an approach uses timestamp to resist replay attack.

    Rationale for inclusion: Facade Section 5.1 "Active attacks": "Reordering, replaying, dropping, or disrupting HTTP messages." "Facade uses ScrambleSuit's key exchange and inherits the properties of that authentication mechanism (and is thus robust against preplay and replay attacks).

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

GOAL: resistance to traffic manipulation

Definition: Evaluates the system's resistance to modification of packets, or injecting or dropping packets. This criterion is concerned only with manipulation of client-initiated flows.

Rationale for inclusion: Section 5.1 Security Evaluation (Active attacks)

Associated metrics:

  • use authentication

    Definition: Whether a client needs authentication to connect to the server.

    Rationale for inclusion: Facade Section 5.1 "Active attacks": "Server discovery via session initiation probing. The censor cannot detect Facade servers with active scanning that attempts to initiate Facade sessions because Facade uses a pre-shared secret for authentication.

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

  • use error correcting codes

    Definition: Whether an approach uses error correcting codes.

    Rationale for inclusion: "Reordering, replaying, dropping, or disrupting HTTP messages. A censor could disrupt the communications channel by manipulating the visible HTTP traffic. However,its options for doing so are limited presuming its unwillingness to disrupt legitimate HTTP transactions. Because modifying the order of search terms or the terms themselves would modify the semantic content of a query, we assume that the censor is unwilling to change the search string. Should this become a significant attack from the censor, an erasure code may also offer additional security at the cost of performance"

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

Facet

For an overview, go to the top of the page. For their documentation see (URL). We believe this tool mentioned the following evaluation criteria:

GOAL: adaptability to blocking

Definition: Assesses the system's resilience to unexpected blocking events and new kinds of blocking.

Rationale for inclusion: Our approach is provider independent. Since the emulator devices in Facet are built independently from the videoconferencing systems, Facet can be adopted widely on any conferencing platform, such as Google Hangout, Skype, FaceTime or QQ.

Scalability. The design of Facet should be independent from the specific videoconferencing systems. This scalability will make Facet applicable to a wide range of videoconferencing systems. This property not only makes Facet accessible for the client to use, but also makes it difficult for the censor to block.

Associated metrics:

GOAL: client performance

Definition: Assesses an approach's client program efficiency in terms of CPU and memory usage.

Rationale for inclusion: Section 9.5 Performance Analysis

Associated metrics:

  • CPU usage by users

    Definition: Assesses the percentage of CPU cycles consumed by the client or server part of the system.

    Rationale for inclusion: Facet (9.5 Performance Analysis) Facet computed CPU cycle with 106 YouTube videos (with length below 180s). For Facet server, CPU costs comes from making a Skype video call (Skype), downloading and redirecting video & audio stream (Gstreamer), and executing a Skype wrapper (Python). The Facet server consumes more CPU cycles (18.7%) than Squid (0.4%) (most of which comes from the Skype video call).

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

  • memory usage by users

    Definition: Assesses the memory requirements to run the system.

    Rationale for inclusion: Facet (9.5 Performance Analysis) Facet computed memory usage with 106 YouTube videos (with length below 180s). For Facet server, the costs comes from making a Skype video call (Skype), downloading and redirecting video & audio stream (Gstreamer), and executing a Skype wrapper (Python). The Facet server consumes more memory (3%) than Squid (0.3%) (most of which comes from the Skype video call).

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

GOAL: network performance

Definition: Assesses the system's performance in terms of goodput, latency and overhead.

Rationale for inclusion: Section 9.5 Performance Analysis

Associated metrics:

  • goodput

    Definition: The amount of useful throughput the tool enables.

    Rationale for inclusion: Table 3: Facet Traffic Break Down (kbit/s)

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

  • latency

    Definition: Assesses the round-trip time for a request.

    Rationale for inclusion: Real-time Delivery. Facet should provide real-time delivery.

GOAL: openness of design

Definition: Assesses whether the source code available (client and server) and whether the design public or relies on security through obscurity.

Rationale for inclusion: Code available (https://github.com/magicle/Facet)

Associated metrics:

  • open source

    Definition: The tool's source code is open.

    Rationale for inclusion: Code available (https://github.com/magicle/Facet)

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

GOAL: resistance to active probing

Definition: Active probing attacks involve the censor initiating connections to hosts to determine whether the host runs a given circumvention protocol, typically then blocking the host's IP address upon finding that it does. A system is resistant to active probing if an adversary cannot discover the use of the system using this technique.

Rationale for inclusion: FACET: Centralized service cannot be discovered, but decentralized can be.

"Even though the censor may proactively probe the service, it can not pinpoint the Facet server IP address, because this address is hidden behind the videoconferencing server.

For decentralized videoconferencing systems such as Skype, the two entities send traffic to each other di- rectly. Consequently, the Facet server ID should only be distributed privately. Otherwise, the censor can pinpoint and block the Facet server IP address by proactively probing the service. "

Associated metrics:

  • respond to probes like something else

    Definition: When probed, respond similar to how some allowed server would respond so that a censor deciding to block such responses will incur false positives.

    Rationale for inclusion: FACET: Centralized service cannot be discovered, but decentralized can be.

    "Even though the censor may proactively probe the service, it can not pinpoint the Facet server IP address, because this address is hidden behind the videoconferencing server.

    For decentralized videoconferencing systems such as Skype, the two entities send traffic to each other di- rectly. Consequently, the Facet server ID should only be distributed privately. Otherwise, the censor can pinpoint and block the Facet server IP address by proactively probing the service. "

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

GOAL: resistance to blocking

Definition: A system resists blocking if it is hard to block the protocol or IP address of the infrastructure that the approach uses, even given a method of identifying it. For example, if blocking would cause substantial collateral damage.

Rationale for inclusion: Hard to block without blocking legitimate traffic. "using the best known traffic analysis methods, a censor seeking to block 90% of Facet calls would need to block over 40% of all Skype calls."

Associated metrics:

  • use a popular protocol

    Definition: Whether an approach sends traffic using a popular protocol, such as the Skype protocol, to force the censor to either block a popular protocol or identify the circumventing usage of the protocol from normal usage.

    Rationale for inclusion: Facet uses popoular video conferencing services: 'Like all proxy steganography systems, it relies on the assumption that the censor is unwilling to indiscriminately block all or most sessions of the cover protocol (Skype) to avoid "collateral damage".'

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

GOAL: resistance to security attacks

Definition: This criterion considers different measures that a paper uses to avoid security attacks such as man-in-the-middle, denial of service, malicious proxy, key reuse and replay attack.

Rationale for inclusion: Section 8. SECURITY ANALYSIS

Associated metrics:

  • ignore invalid connections (DoS)

    Definition: Whether an approach ignores invalid connections to avoid denial of service attacks.

    Rationale for inclusion: FACET: To prevent denial-of-service (DoS) attacks, the Facet server is con- figured to not accept strangers' requests. Thus, a potential Facet client is required to register with the server, by sending an "add contact" request to the server's conferencing ID. Only after this request is proved by the Facet server, can the client access to the service. Also, the Facet server enforces usage limits on each regis- tered client ID to further defend against DoS attacks

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

  • limit service to each user ID (DoS)

    Definition: Avoid DoS by limiting the amount of service the approach will provide to each user.

    Rationale for inclusion: Facet: Denial of Service Attack. When Facet server ID is distributed publicly, the censor may launch a DoS attack. CAPTCHA [11] can be used to mitigate the censor's enumeration. In addition, the server can enforce usage limitations on each client ID. Besides, puzzles can be used to defeat the Sibil identify attack.

  • use client puzzle (DoS)

    Definition: Require clients to solve a puzzle to prevent DoS.

    Rationale for inclusion: Facet: Denial of Service Attack. When Facet server ID is distributed publicly, the censor may launch a DoS attack. CAPTCHA [11] can be used to mitigate the censor's enumeration. In addition, the server can enforce usage limitations on each client ID. Besides, puzzles can be used to defeat the Sibil identify attack.

GOAL: resistance to traffic analysis

Definition: An approach is resistant to traffic analysis if an adversary cannot statically use properties of the traffic generated by the approach to detect it. (Some of the metrics used for this goal can also be used for active probing, but they are not inherently active.)

Rationale for inclusion: Section 6. TRAFFIC ANALYSIS

Associated metrics:

  • matching allowed n-gram distribution

    Definition: Considers the distribution of consecutive strings of symbols, for example bytes. This includes 1-grams (e.g., distribution of single byte values).

    Rationale for inclusion: Facet: Their packet analysis classifier uses n-gram of packets as a feature. The $\chi^2$ classifier takes the packet length as input, and adopts n-gram as feature extraction, which is a contiguous sequence of n packet lengths from the time series traffic.

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

  • packet size distribution

    Definition: Measures the distribution of packet lengths to assess wehether it is unlike that of a blocked protocol, or like that of an allowed protocol.

    Rationale for inclusion: Figure 3: Traffic Analysis: Chat and YouTube videos have different traffic patterns.

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

GOAL: usability

Definition: Assesses the additional effort that the circumvention tool client user must expand to use the system.

Rationale for inclusion: "No deployment at client side. For Facet clients, there is no need to install any client software (which is often blocked), or to pre-share secrets with the server. This property makes Facet easier to use and maintain, since software updates only need to be applied by servers outside of the censored region."

Associated metrics:

  • no installation

    Definition: Using the tool does not require installing special software.

    Rationale for inclusion: FACET: No deployment at client side. For Facet clients, there is no need to install any client software (which is often blocked), or to pre-share secrets with the server. This property makes Facet easier to use and maintain, since software updates only need to be applied by servers outside of the censored region.

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

TapDance

For an overview, go to the top of the page. For their documentation see (URL). We believe this tool mentioned the following evaluation criteria:

GOAL: availability of infrastructure

Definition: This criterion considers the availability of the infrastructure used by an approach for users and the feasibility of deployment.

Rationale for inclusion: Server support: In order to measure how many servers can act as decoy destinations, we probed samples of the IPv4 address space as well as the Alexa top million hosts with tests to indicate support for TapDance.

Associated metrics:

  • preponderance of suitable servers

    Definition: Some tools rely on finding servers with a specific property at large in the Internet. For example, servers that accept user-posted content, or servers with specific network protocol quirks. This criterion means that the study measured how common such servers really are.

    Rationale for inclusion: In TapDance, Section 8 "Server support", they probed 1% of the IPv4 space to find the number of TLS servers that had a long enough timeout and acknowledge out-of-order data in a particular way.

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

GOAL: client performance

Definition: Assesses an approach's client program efficiency in terms of CPU and memory usage.

Rationale for inclusion: 8 Evaluation

Associated metrics:

  • CPU usage by users

    Definition: Assesses the percentage of CPU cycles consumed by the client or server part of the system.

    Rationale for inclusion: TapDance looked at CPU usage by the proxy station and the client. Section 8: "We find that the CPU performance is bottlenecked by our single-threaded client. During our tests, the client consumes 100% CPU on a single core, while each of the 8 processes on the ISP station consume between 4-7% CPU."

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

GOAL: network performance

Definition: Assesses the system's performance in terms of goodput, latency and overhead.

Rationale for inclusion: Section 8 Evaluation

Associated metrics:

  • registration performance

    Definition: Some systems need to apply a special distinguisher or mark to traffic destined for circumvention. For example, end-to-middle proxying systems need to tag flows at the client side and recognize them at the station. This criterion considers the performance of the registration method.

    Rationale for inclusion: Section 8 Evaluation (Tag creation and processing)

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

  • speed of downloading a webpage

    Definition: Assesses the time required to download a webpage. This is really a combination of goodput and latency, but it is specifically applied so often that we made it its own criterion.

    Rationale for inclusion: TapDance: Section 8: "We used Apache Benchmark in order to issue 5,000 requests through our station proxy, with a concurrency of 100, and compared the performance for fetching a simple page over HTTP and over HTTPS. We also compare fetching the same pages directly from the server and through a single-hop proxy."

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

GOAL: openness of design

Definition: Assesses whether the source code available (client and server) and whether the design public or relies on security through obscurity.

Rationale for inclusion: Code available (https://github.com/ewust/tapdance/)

Associated metrics:

  • open source

    Definition: The tool's source code is open.

    Rationale for inclusion: Code available (https://github.com/ewust/tapdance/)

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

GOAL: resistance to active probing

Definition: Active probing attacks involve the censor initiating connections to hosts to determine whether the host runs a given circumvention protocol, typically then blocking the host's IP address upon finding that it does. A system is resistant to active probing if an adversary cannot discover the use of the system using this technique.

Rationale for inclusion: TAPDANCE: Section 5.2, Packet injection. TAPDANCE: Section 5.2, Active defense.

Associated metrics:

  • respond to probes like something else

    Definition: When probed, respond similar to how some allowed server would respond so that a censor deciding to block such responses will incur false positives.

    Rationale for inclusion: TapDance resists active probing by increasing the censor's false positive rates. Every time a TapDance station observes an active probe it always responds as if the connection as if it is a proxy connection, even if the connection was not a proxy connection. TAPDANCE: Section 5.2, Active defense: "As an example, consider a censor that injects a stale ACK for suspected proxy connections. Connections that are actually proxy connections will respond with a stale ACK from the server, revealing the connection to the censor. However, the station could detect the original probe, and if it is not a proxied connection, respond with a stale ACK so as to make it appear to the censor as if it were. In this way, for every probe the censor makes, they will detect, sometimes incorrectly, that the connection was a proxy connection."

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

GOAL: resistance to blocking

Definition: A system resists blocking if it is hard to block the protocol or IP address of the infrastructure that the approach uses, even given a method of identifying it. For example, if blocking would cause substantial collateral damage.

Rationale for inclusion: Uses network infrastructure

Associated metrics:

  • use network infrastructure

    Definition: Whether an approach uses infrastructure within a network, e.g., router, to avoid address blocking.

    Rationale for inclusion: Uses End-to-middle proxying

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

GOAL: resistance to security attacks

Definition: This criterion considers different measures that a paper uses to avoid security attacks such as man-in-the-middle, denial of service, malicious proxy, key reuse and replay attack.

Rationale for inclusion: TAPDANCE is vulnerable to this attack but considers the attack to be expensive for a censor. (5.2 Active Attacks, TLS attacks)

Associated metrics:

  • ignore invalid connections (DoS)

    Definition: Whether an approach ignores invalid connections to avoid denial of service attacks.

    Rationale for inclusion: TapDance: Section 5.2 "Denial of service". "Because ISPs com- monly perform load balancing by flow-based hashing, we can scale our deployment linearly to multiple branches of machines and use standard intrusion detection techniques to ignore packets that do not belong to valid connections or that come from spoofed or blacklisted sources "

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

  • limit service to each user ID (DoS)

    Definition: Avoid DoS by limiting the amount of service the approach will provide to each user.

    Rationale for inclusion: 7.3 Connection Limits

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

  • use TLS for confidentiality

    Definition: Whether an approach uses TLS to provide confidentiality.

    Rationale for inclusion: While TapDance and previous designs are vulnerable to this attack, there may be external political pressure that discourages a censor from this attack, as it may be disrup- tive to foreign e-commerce in particular. We also argue that as the number of sites using TLS continues to in- crease, this attack becomes more expensive for the censor to perform without impacting performance. Finally, decoy servers that use certificate pinning or other CA-protection mechanisms such as Perspectives [45], CAge [27], or CA country pinning [42], can potentially avoid such attacks.

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

  • use certificate pinning (MITM)

    Definition: Whether an approach uses certificate pinning to avoid MiTM.

    Rationale for inclusion: Tapdance: Finally, decoy servers that use certificate pinning or other CA-protection mechanisms such as Perspectives [45], CAge [27], or CA country pinning [42], can potentially avoid such attacks.

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

  • use timestamp (replay)

    Definition: Whether an approach uses timestamp to resist replay attack.

    Rationale for inclusion: TapDance: Section 5.2 "Replay attacks". "Replay attacks The censor could capture suspected tags and attempt to replay them in a new connection, to determine if the station responds to the tag. To specifically attack TapDance, the adversary could replay the client's tag-containing request packet after the connection has closed and observe if the station appears to send back a response. We note that both Cirripede and Decoy Routing are also vulnerable to tag replay attacks, although Telex provides some limited protection from them. To protect against duplicated tags, the station could record previous tags and refuse to respond to a repeated tag. To avoid saving all tags, the station could require clients to include a recent timestamp in the encrypted payload1. However, such a defense may enable a denial of ser- vice attack: the censor could delay the true request of a suspected client and send it in a different connection first. In this preplay version of the attack, the censor is also able to observe whether the station responds with the ClientHello message. If it does, the censor will know the suspected request contained a tag."

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

GOAL: resistance to traffic analysis

Definition: An approach is resistant to traffic analysis if an adversary cannot statically use properties of the traffic generated by the approach to detect it. (Some of the metrics used for this goal can also be used for active probing, but they are not inherently active.)

Rationale for inclusion: Section 5.1 Passive Attacks

Associated metrics:

  • TLS characteristics

    Definition: Prevents detection by TLS characteristics, like TLS nonce, clienthello or serverhello messages.

    Rationale for inclusion: TLS handshake TLS allows implementations to sup- port many different extensions and cipher suites. As a result, implementations can be easy to differentiate based on the ciphers and extensions they claim to support in their ClientHello or ServerHello messages. In order to prevent this from being used to locate suspicious imple- mentations, our proxy must blend in to or mimic another popular client TLS implementation. For example, we could support the same set of ciphers and extensions as Chrome for the user’s platform. Currently, our client mimics Chrome’s cipher suite list for Linux.

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

  • inter-packet timing

    Definition: Measures the distribution of packet timing (interpacket times or packet rates) to assess whether it is unlike that of a blocked protocol, or like that of an allowed protocol.

    Rationale for inclusion: TapDance: Section 5.1: "Packet timing and length." Although they don't make concrete measurements, they say that normal traffic to a decoy host may have a different distribution, but it's hard to test in practice.

  • lack of server response

    Definition: This criterion is specific to TapDance and the way it sends half-finished HTTP requests. If a TapDance station exists along a path, the request is intercepted and a response comes back immediately. If there is no TapDance station, then no response ever comes (or perhaps comes only after a long timeout).

    Rationale for inclusion: Lack of server response If the TapDance station fails to detect a client’s flow, it will not respond to the client. This may appear suspicious to a censor, as the client sends a request, but there is no response at the application level from the server. To address the last issue, probing clients could send complete requests and tag their requests with a secret nonce.

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

  • network stack fingerprinting

    Definition: Assesses the fingerprintability of the network stack, for example comparing the TCP options of two different hosts. Relevant when one host spoofs packets on behalf of another.

    Rationale for inclusion: TapDance Section 5.1, TCP/IP protocol fingerprinting: "The adversary could attempt to observe packets coming from potential decoy servers and build profiles for each server, including the set of TCP options supported by the server, IP TTL values, TCP window sizes, and TCP timestamp slope and offset....server mimicry remains difficult to achieve in practice."

  • packet size distribution

    Definition: Measures the distribution of packet lengths to assess wehether it is unlike that of a blocked protocol, or like that of an allowed protocol.

    Rationale for inclusion: TapDance: Section 5.1: "Packet timing and length." Although they don't make concrete measurements, they say that normal traffic to a decoy host may have a different distribution, but it's hard to test in practice.

  • use encryption to resist traffic analysis

    Definition: Whether an approach uses encryption to resist traffic analysis.

    Rationale for inclusion: MISSING_RATIONALE

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

GOAL: resistance to traffic manipulation

Definition: Evaluates the system's resistance to modification of packets, or injecting or dropping packets. This criterion is concerned only with manipulation of client-initiated flows.

Rationale for inclusion: 5.2 Active Attacks

Associated metrics:

  • limit service to each user ID (DoS)

    Definition: Avoid DoS by limiting the amount of service the approach will provide to each user.

    Rationale for inclusion: 7.3 Connection Limits

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

CloudTransport

For an overview, go to the top of the page. For their documentation see (URL). We believe this tool mentioned the following evaluation criteria:

GOAL: end-user protection

Definition: Assesses whether an approach protects user's privacy from intermediate and end nodes.

Rationale for inclusion: Table 2 shows what information CloudTransport aims to hide from, respectively, the censoring ISP, cloud storage provider, and CloudTransport bridges. The cloud storage provider is trusted not to reveal to the censors the identities and network locations of its customers who are using CloudTransport. The bridges are trusted not to perform flow correlation (see Section 4.4). In the tunnel mode, the bridges must also be trusted not to reveal the contents and destinations of CloudTransport traffic; this assumption is not required in the proxified modes.

Associated metrics:

  • hide user information from end host

    Definition: The tool hides information about the user from the end host (destination) to which the user connects to provide some degree of anonymity.

    Rationale for inclusion: Table 2 shows what information CloudTransport aims to hide from, respectively, the censoring ISP, cloud storage provider, and CloudTransport bridges. The cloud storage provider is trusted not to reveal to the censors the identities and network locations of its customers who are using CloudTransport. The bridges are trusted not to perform flow correlation (see Section 4.4). In the tunnel mode, the bridges must also be trusted not to reveal the contents and destinations of CloudTransport traffic; this assumption is not required in the proxified modes.

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

GOAL: infrastructure cost

Definition: Assesses the cost of infrastructure required to deploy an approach in real world.

Rationale for inclusion: Table 1. Prices charged by cloud storage providers (2013)

Associated metrics:

  • cost of external services

    Definition: Estimates the cost of external services, e.g., cloud services, CDNs, that are required to deploy an approach.

    Rationale for inclusion: Table 1. Prices charged by cloud storage providers (2013)

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

GOAL: network performance

Definition: Assesses the system's performance in terms of goodput, latency and overhead.

Rationale for inclusion: Section 5 Performance

Associated metrics:

  • byte overhead

    Definition: How many extra bytes are introduced by the tool.

    Rationale for inclusion: CloudTransport connections have minimal bandwidth overhead per message: 350-400 bytes for S3, 700-800 for CloudFiles, and 375-450 for Google Cloud Storage. HTTPS uploads and downloads have extra 2-3% overhead. When Cirriform polls an S3 account 3 times per second and 5 times per second per connection, its total overhead is 1.2KB + 2KB/connection per second.

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

  • latency

    Definition: Assesses the round-trip time for a request.

    Rationale for inclusion: Cumuliform is noticeably slower because it buffers messages for all connec- tions (as many as 30 when browsing). The variance for CloudTransport is much lower than for Tor+Obfsproxy, mainly because delays in CloudTransport are due to waiting for data to become available in the rendezvous account and S3 has fairly consistent delays in propagating small files used by CloudTransport. Uploading files involves a lot of back-and-forth communication to set up the SCP connection. This puts CloudTransport at a disadvantage because of its per- message overheads, but Fig. 8 shows that it still outperforms Tor+Obfsproxy in all modes but one.

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

  • speed of downloading a webpage

    Definition: Assesses the time required to download a webpage. This is really a combination of goodput and latency, but it is specifically applied so often that we made it its own criterion.

    Rationale for inclusion: Fig. 7. Browsing (different usage modes).

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

GOAL: resistance to blocking

Definition: A system resists blocking if it is hard to block the protocol or IP address of the infrastructure that the approach uses, even given a method of identifying it. For example, if blocking would cause substantial collateral damage.

Rationale for inclusion: "Censorship circumvention systems such as Tor are highly vulnerable to network-level filtering. Because the traffic generated by these systems is disjoint from normal network traffic, it is easy to recog- nize and block, and once the censors identify network servers (e.g., Tor bridges) assisting in circumvention, they can locate all of their users. CloudTransport is a new censorship-resistant communication system that hides users’ network traffic by tunneling it through a cloud storage ser- vice such as Amazon S3."

Associated metrics:

  • use popular hosts

    Definition: Whether an approach uses popular hosts, such as Skype nodes and CDNs, to resist address blocking.

    Rationale for inclusion: Cloudtransport: "By contrast, blacklisting the IP addresses of CloudTransport bridges has no effect on CloudTransport, while blacklisting the IP addresses of cloud servers used by CloudTransport disrupts other cloud-based applications using the same servers."

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

GOAL: resistance to security attacks

Definition: This criterion considers different measures that a paper uses to avoid security attacks such as man-in-the-middle, denial of service, malicious proxy, key reuse and replay attack.

Rationale for inclusion: 4.2 Abusing the CloudTransport bootstrapping protocol 4.3 Attacking a CloudTransport bridge

Associated metrics:

  • use encryption for confidentiality

    Definition: Whether an approach uses encryption for confidentiality (and/or integrity).

    Rationale for inclusion: CLOUDTRANSPORT: The traffic between the user's CloudTransport client and the bridge is encrypted, preventing the cloud provider from observing traffic contents.

    (Cloudtransport has other modes where the traffic is not encrypted)

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

GOAL: resistance to traffic analysis

Definition: An approach is resistant to traffic analysis if an adversary cannot statically use properties of the traffic generated by the approach to detect it. (Some of the metrics used for this goal can also be used for active probing, but they are not inherently active.)

Rationale for inclusion: 4.1 Recognizing CloudTransport network traffic 4.4 Performing large-scale flow correlation

Associated metrics:

Bit-smuggler

For an overview, go to the top of the page. For their documentation see (URL). We believe this tool mentioned the following evaluation criteria:

GOAL: network performance

Definition: Assesses the system's performance in terms of goodput, latency and overhead.

Rationale for inclusion: BITSMUGGLER: Problems, Performance.

Associated metrics:

  • latency

    Definition: Assesses the round-trip time for a request.

    Rationale for inclusion: BITSMUGGLER: Problems, Performance: "Has poor latency since the stream of data is broken down to fit in bittorrent piece messages. (high throughput on the upside though)"

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

  • throughput

    Definition: The amount of throughput/bandwidth the tool enables.

    Rationale for inclusion: BITSMUGGLER: Problems, Performance: "Has poor latency since the stream of data is broken down to fit in bittorrent piece messages. (high throughput on the upside though)"

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

GOAL: openness of design

Definition: Assesses whether the source code available (client and server) and whether the design public or relies on security through obscurity.

Rationale for inclusion: Code available (https://github.com/danoctavian/bit-smuggler)

Associated metrics:

  • open source

    Definition: The tool's source code is open.

    Rationale for inclusion: BITSMUGGLER does not mention that it has source code available but it does (https://github.com/danoctavian/bit-smuggler)

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

GOAL: resistance to active probing

Definition: Active probing attacks involve the censor initiating connections to hosts to determine whether the host runs a given circumvention protocol, typically then blocking the host's IP address upon finding that it does. A system is resistant to active probing if an adversary cannot discover the use of the system using this technique.

Rationale for inclusion: BITSMUGGLER: Why use real bittorrent clients: "A common attack agains Tor bridges used to unmask their dientity is to active probe them see bottom of page here. Using real bittorrent clients means that probing attacks are hard to get right since the proxy (Tor bridge or just a proxy) responds like a normal bittorrent client since it actually runs one."

Associated metrics:

  • respond to probes like something else

    Definition: When probed, respond similar to how some allowed server would respond so that a censor deciding to block such responses will incur false positives.

    Rationale for inclusion: BITSMUGGLER: Why use real bittorrent clients: "A common attack agains Tor bridges used to unmask their dientity is to active probe them see bottom of page here. Using real bittorrent clients means that probing attacks are hard to get right since the proxy (Tor bridge or just a proxy) responds like a normal bittorrent client since it actually runs one."

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

GOAL: resistance to traffic analysis

Definition: An approach is resistant to traffic analysis if an adversary cannot statically use properties of the traffic generated by the approach to detect it. (Some of the metrics used for this goal can also be used for active probing, but they are not inherently active.)

Rationale for inclusion: https://github.com/danoctavian/bit-smuggler#security Slow path analysis will break the undetectability of bit-smuggler.

Bittorrent file integrity is broken. Since we are tunnelling data through a bittorrent file exchange in real-time we are altering file pieces and breaking the checksums of the file pieces.

To actually detect this in real time you need to do TCP packet reconstruction, fetch the original torrent file, compute hashes and detect a high occurence of hash fails. Sounds like a lot of expensive work.

Sounds totally doable on a slow-path where you've recorded all the packets of a bittorrent connection previously.

Associated metrics:

Castle

For an overview, go to the top of the page. For their documentation see (URL). We believe this tool mentioned the following evaluation criteria:

GOAL: adaptability to blocking

Definition: Assesses the system's resilience to unexpected blocking events and new kinds of blocking.

Rationale for inclusion: Users of video-game-based censorship-circumvention tools can therefore diversify across many games, making it difficult for the censor to respond by simply blocking a single cover protocol.

The primary goal of Castle is adaptability - Castle is loosely cou- pled to the underlying game, enabling developers to quickly adapt Castle to many games

Associated metrics:

  • time to create an adaptation

    Definition: The amount of time it takes some programmer to create a new adaptation of the protocol.

    Rationale for inclusion: As a consequence, it was possible to port Castle to Aeons and Conquerors in under 6 hours per game.

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

GOAL: deniability under computer inspection

Definition: Whether the circumvention tool users can plausibly deny using it even when their computers are inspected.

Rationale for inclusion: Vague but does mention "Deniability and ease of distribution."

Associated metrics:

GOAL: network performance

Definition: Assesses the system's performance in terms of goodput, latency and overhead.

Rationale for inclusion: CASTLE: 7. Performance Evaluation: "Without any game-specific modifications, Castle offers per- formance amenable to transfer of textual data (e.g., tweets, email, news articles)."

Associated metrics:

  • goodput

    Definition: The amount of useful throughput the tool enables.

    Rationale for inclusion: CASTLE: 7. Performance Evaluation (tech report): "Since each real-time strategy game has a limit on the number of objects that can be selected for a single command, the data rate obtained by Castle is game dependent. For example, 0 A.D. allows the selection of up to 200 units for a single command, giving us an average of ... 65 bytes per command. On the other hand, Aeons has no limits on the number of units that may be selected for a single command but allows only 435 objects to be placed within a single screen - giving us an average of a 39 bytes per command.... We found that on average, issuing a single command required between 300-350 ms. With no delays between the issue of each command, this allows 3 commands/second."

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

GOAL: openness of design

Definition: Assesses whether the source code available (client and server) and whether the design public or relies on security through obscurity.

Rationale for inclusion: CASTLE: 9. Conclusions, Code and data release: "To ensure reproducibility of our results and ease comparative evaluation, our implementation of Castle is available at https://github.com/bridgar/Castle-Covert-Channel."

Associated metrics:

  • open source

    Definition: The tool's source code is open.

    Rationale for inclusion: The source code of Castle (not including game specific code – e.g., replay decoders, map generators, etc.) is available under the CRAPL license 4 at https://github.com/bridgar/Castle-Covert-Channel.

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

GOAL: resistance to active probing

Definition: Active probing attacks involve the censor initiating connections to hosts to determine whether the host runs a given circumvention protocol, typically then blocking the host's IP address upon finding that it does. A system is resistant to active probing if an adversary cannot discover the use of the system using this technique.

Rationale for inclusion: CASTLE: 2. Adversary and Threat Model: "The adversary may also take an active approach and probe application endpoints or otherwise interact with the game."

Associated metrics:

  • use authentication

    Definition: Whether a client needs authentication to connect to the server.

    Rationale for inclusion: Castle resists active probing by using authenticated command channel.

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

GOAL: resistance to blocking

Definition: A system resists blocking if it is hard to block the protocol or IP address of the infrastructure that the approach uses, even given a method of identifying it. For example, if blocking would cause substantial collateral damage.

Rationale for inclusion: CASTLE: 2.1 Network traffic attacks: "IP and port filtering: The censor can observe the IP addresses and port numbers of connections on their network (e.g., using standard tools like Netflow])."

Associated metrics:

GOAL: resistance to traffic analysis

Definition: An approach is resistant to traffic analysis if an adversary cannot statically use properties of the traffic generated by the approach to detect it. (Some of the metrics used for this goal can also be used for active probing, but they are not inherently active.)

Rationale for inclusion: CASTLE: 2. Adversary and Threat Model: "...we consider a network-level censor (e.g., an ISP) who is able to perform analysis over all traffic that it forwards from or to clients within its network." CASTLE: 2.1 Network traffic attacks: "Deep-packet inspection: The censor may look for specific patterns in packet headers and payloads (e.g., application payloads indicative of a specific game). Flow-level analysis: The censor may perform statistical analyses of flow-level characteristics such as inter-packet times and packet sizes)."

Associated metrics:

  • connection length

    Definition: Measures the duration of flows (e.g., TCP connections) and evaluates whether the duration can be a distinguisher. (If a connection is suspiciously long, for example.)

    Rationale for inclusion: Castle claims that it's normal for video game connections to last a long time (hours).

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

  • inter-packet timing

    Definition: Measures the distribution of packet timing (interpacket times or packet rates) to assess whether it is unlike that of a blocked protocol, or like that of an allowed protocol.

    Rationale for inclusion: We find that packet sizes and inter-packet times of Castle's traffic deviate from those of regular human-driven game play by the same amount that different human player's traffic differ from each other.

    Fig. 4

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

  • packet size distribution

    Definition: Measures the distribution of packet lengths to assess wehether it is unlike that of a blocked protocol, or like that of an allowed protocol.

    Rationale for inclusion: We find that packet sizes and inter-packet times of Castle's traffic deviate from those of regular human-driven game play by the same amount that different human player's traffic differ from each other.

    Fig. 3

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

GOAL: resistance to traffic manipulation

Definition: Evaluates the system's resistance to modification of packets, or injecting or dropping packets. This criterion is concerned only with manipulation of client-initiated flows.

Rationale for inclusion: CASTLE: 2. Adversary and Threat Model: "It may also perform manipulations (e.g., dropping packets, injecting packets) of the network traffic via on-path or in-path middleboxes." CASTLE: 2.1 Network traffic attacks, Active manipulations: "In particular, the censor may drop, insert, or delay packets. Additionally, they may also modify the packet contents and headers. The adversary may perform these manipulations to observe the behavior of flow endpoints to distinguish legitimate game traffic from the covert channel. They may also use these actions to block covert connections ( e.g., sending TCP RST packets, or dropping traffic)."

Associated metrics:

  • use UDP with reliability

    Definition: Whether an approach uses UDP with reliability.

    Rationale for inclusion: Section 6 (Active traffic manipulations.): "Packet dropping and delaying. Although most commercial real-time strategy games make use of UDP as a transport, the presence of reliability implemented in the application layer pre- vents any threats from adversaries that drop, or significantly delay packets in transmission. As a result, attacks (e.g., [19]) that result in denial-of-service for Castle users are not possible without also affecting legitimate game players."

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

  • use authentication

    Definition: Whether a client needs authentication to connect to the server.

    Rationale for inclusion: Castle resists active probing by using authenticated command channel.

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

GOAL: usability

Definition: Assesses the additional effort that the circumvention tool client user must expand to use the system.

Rationale for inclusion: Deniability and ease of distribution.

Castle's small core size also makes it easy to distribute through hard to block methods - e.g., via the text body in emails and even through instant messaging services.

Associated metrics:

  • small download file

    Definition: The size of the tool's client program file is small.

    Rationale for inclusion: Castle’s small code base also makes it easy to distribute via hard to block asynchronous methods

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

Rook

For an overview, go to the top of the page. For their documentation see (URL). We believe this tool mentioned the following evaluation criteria:

GOAL: adaptability to blocking

Definition: Assesses the system's resilience to unexpected blocking events and new kinds of blocking.

Rationale for inclusion: "Introduction: The general design of Rook is not specific to a game, and so if a censor attempted to block Rook by blocking a single game, it could be adapted to another."

Associated metrics:

GOAL: availability of infrastructure

Definition: This criterion considers the availability of the infrastructure used by an approach for users and the feasibility of deployment.

Rationale for inclusion: "Introduction: Rook was developed with the FPS as the primary type of game to be used: this is because of the prevalence of private servers and the use a robust and low-latency UDP- based network protocol."

Associated metrics:

GOAL: network performance

Definition: Assesses the system's performance in terms of goodput, latency and overhead.

Rationale for inclusion: Section 4.1 Bandwidth and Usability

Associated metrics:

  • goodput

    Definition: The amount of useful throughput the tool enables.

    Rationale for inclusion: MISSING_RATIONALE

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

  • throughput

    Definition: The amount of throughput/bandwidth the tool enables.

    Rationale for inclusion: "Section 4.1 Bandwidth and Usability: Our implementation of Rook for Team Fortress 2 currently operates at 34 bits/second from game client to game server, and 26 bits/second from game server to game client. This is relatively low but still useful for the real- time chat messaging that is the target of this system."

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

GOAL: resistance to active probing

Definition: Active probing attacks involve the censor initiating connections to hosts to determine whether the host runs a given circumvention protocol, typically then blocking the host's IP address upon finding that it does. A system is resistant to active probing if an adversary cannot discover the use of the system using this technique.

Rationale for inclusion: ROOK: Since Rook actually runs the game client and server, an active adversary's probes will be responded to in exactly the same manner as a normal game client and server.

Associated metrics:

  • respond to probes like something else

    Definition: When probed, respond similar to how some allowed server would respond so that a censor deciding to block such responses will incur false positives.

    Rationale for inclusion: Rook: "Since Rook actually runs the game client and server, an active adversary's probes will be responded to in exactly the same manner as a normal game client and server."

    This metric was measured by the work and either shown to hold (binary metrics) or have a particular value (quantitative metrics).

GOAL: resistance to blocking

Definition: A system resists blocking if it is hard to block the protocol or IP address of the infrastructure that the approach uses, even given a method of identifying it. For example, if blocking would cause substantial collateral damage.

Rationale for inclusion: "Introduction: Finally, like VoIP services, games are a widespread and popular form of network use [26]; we believe a censor would face similar dissent to a decision to block all Internet-gaming as they would to blocking all VoIP."

Associated metrics: