Conjure: Summoning Proxies from Unused Address Space

Sergey Frolov Jack Wampler Sze Chuen Tan

University of Colorado Boulder University of Colorado Boulder UIUC

J. Alex Halderman Nikita Borisov Eric Wustrow

University of Michigan UIUC University of Colorado Boulder

ABSTRACT
Refraction Networking (formerly known as “Decoy Routing”) has
emerged as a promising next-generation approach for circumvent-
ing Internet censorship. Rather than trying to hide individual cir-
cumvention proxy servers from censors, proxy functionality is
implemented in the core of the network, at cooperating ISPs in
friendly countries. Any connection that traverses these ISPs could
be a conduit for the free flow of information, so censors cannot eas-
ily block access without also blocking many legitimate sites. While
one Refraction scheme, TapDance, has recently been deployed at
ISP-scale, it suffers from several problems: a limited number of
“decoy” sites in realistic deployments, high technical complexity, Figure 1: Conjure Overview — An ISP deploys a Conjure station, which
and undesirable tradeoffs between performance and observability sees a passive tap of passing traffic. Following a steganographic registration
by the censor. These challenges may impede broader deployment process, a client can connect to an unused IP address in the ISP’s AS, and
the station will inject packets to communicate with the client as if there
and ultimately allow censors to block such techniques.
were a proxy server at that address.
We present Conjure, an improved Refraction Networking ap-
proach that overcomes these limitations by leveraging unused ad-
dress space at deploying ISPs. Instead of using real websites as the
decoy destinations for proxy connections, our scheme connects 1 INTRODUCTION
to IP addresses where no web server exists leveraging proxy func- Over half of Internet users globally now live in countries that block
tionality from the core of the network. These phantom hosts are political, social, or religious content online [19]. Meanwhile, many
difficult for a censor to distinguish from real ones, but can be used popular tools and techniques for circumventing such censorship
by clients as proxies. We define the Conjure protocol, analyze its become ineffective, because censors have evolved new ways to block
security, and evaluate a prototype using an ISP testbed. Our results them [14, 35] or infrastructure they rely on has become unavailable.
suggest that Conjure can be harder to block than TapDance, is sim- For example, domain fronting [17] was a popular circumvention
pler to maintain and deploy, and offers substantially better network strategy used by meek (in Tor), as well as by the Signal secure
performance. messaging app to get around censorship in countries where it was
blocked [36, 43]. But in May 2018, Google and Amazon made both
CCS CONCEPTS technical and policy changes to their cloud infrastructures that
• Networks → Network security; • Social and professional top- removed support for domain fronting [33]. While meek continues
ics → Censorship. to use other cloud providers that (for now) continue to allow domain
fronting, Signal abandoned the strategy altogether [37]. There is
KEYWORDS an urgent need for new, more robust approaches to circumvention.
anticensorship, proxies, network security A family of techniques called Refraction Networking [3, 13, 26,
29, 40, 59, 60], formerly known as Decoy Routing, has made promis-
ACM Reference Format: ing steps towards that goal. These techniques operate in the net-
Sergey Frolov, Jack Wampler, Sze Chuen Tan, J. Alex Halderman, Nikita work’s core, at cooperating Internet Service Providers (ISPs) outside
Borisov, and Eric Wustrow. 2019. Conjure: Summoning Proxies from Unused
censoring countries [45]. Clients access circumvention services by
Address Space. In 2019 ACM SIGSAC Conference on Computer and Commu-
connecting to a “decoy site”—any uncensored website for which
nications Security (CCS ’19), November 11–15, 2019, London, United Kingdom.
ACM, New York, NY, USA, 15 pages. [Link] the connection travels over a participating ISP. Upon recognizing a
steganographic signal from the client, the ISP modifies the connec-
Permission to make digital or hard copies of part or all of this work for personal or tion response to return censored content requested by the user. Cen-
classroom use is granted without fee provided that copies are not made or distributed sors cannot easily block access without also blocking legitimate con-
for profit or commercial advantage and that copies bear this notice and the full citation
on the first page. Copyrights for third-party components of this work must be honored. nections to the decoy sites—collateral damage that may be prohib-
For all other uses, contact the owner/author(s). itive for censors if Refraction Networking is widely deployed [48].
CCS ’19, November 11–15, 2019, London, United Kingdom However, deploying such schemes is more difficult than with
© 2019 Copyright held by the owner/author(s).
ACM ISBN 978-1-4503-6747-9/19/11. most edge-based circumvention techniques, since ISPs must be
[Link] convinced to operate the systems in their production networks.
1
CCS ’19, November 11–15, 2019, London, United Kingdom Sergey Frolov, Jack Wampler, Sze Chuen Tan, J. Alex Halderman, Nikita Borisov, and Eric Wustrow

To date, only TapDance [59], one of six Refraction Networking future censor techniques with greater agility. We believe that these
proposals, has been deployed at ISP scale [20]. advantages will make Conjure a strong choice for future Refraction
TapDance was designed for ease of deployment. Instead of in-line Networking deployments.
network devices required by earlier schemes, it calls for only a pas- We have released the open source implementation of the Conjure
sive tap. This “on-the-side” approach, though much friendlier from client at [Link]
an ISP’s perspective, leads to major challenges when interposing dark-decoy.
in an ongoing client-to-decoy connection:
• Implementation is complex and error-prone, requiring kernel
2 BACKGROUND
patches or a custom TCP stack.
• To avoid detection, the system must carefully mimic subtle Refraction Networking operates by injecting covert communica-
features of each decoy’s TCP and TLS behavior. tion inside a client’s HTTPS connection with a reachable site, also
• The architecture cannot resist active probing attacks, where known as a decoy site. In a regular HTTPS session, a client es-
the censor sends specially crafted packets to determine whether tablishes a TCP connection, performs a TLS handshake with a
a suspected connection is using TapDance. destination site, sends an encrypted web request, and receives an
• Interactions with the decoy’s network stack limit the length encrypted response. In Refraction Networking, at least one direc-
and duration of each connection, forcing TapDance to multi- tion of this exchange is observed by a refraction station, deployed
plex long-lived proxy connections over many shorter decoy at some Internet service provider (ISP). The station watches for a
connections. This adds overhead and creates a traffic pattern covert signal from the client that this connection is to be used for
that is challenging to conceal. censorship circumvention. Upon seeing the signal, the station will
take over the HTTPS session, and establish a proxy session with
Conjure In this paper, we present Conjure, a Refraction Network- the client that can then be used for covert communication.
ing protocol that overcomes these challenges while retaining Tap- One of the key challenges for Refraction Networking is in taking
Dance’s ISP-friendly deployment requirements Our key innovation over a session. The station must start responding to the client’s
is an architecture that avoids having to actively participate in client- traffic as if it were the decoy destination, and at the same time
to-decoy connections. prevent the destination from sending its own responses back to
In our scheme (Figure 1), clients register their intentions to con- the client. A simple approach is to have the refraction station act
nect to phantom hosts in the “dark” or unused address space of as an inline transparent proxy (Figure 2a) that forwards the traffic
the deploying ISP. Once registered, clients can connect to these between the client and the decoy site. After a TLS handshake has
phantom hosts IP addresses as if they were real proxy servers. The been completed, the station terminates the connection with the
Conjure station (deployed at an ISP) acts as the other end of these decoy site by sending a TCP reset and takes over the session with
connections, and responds as if it were a legitimate site or service. the client.
To the censor, these phantom hosts appear as legitimate sites or An inline element, however, can significantly affect the relia-
services, and even active probes will not reveal information that bility and performance of the regular, non-refraction traffic of an
would allow the censor to block them. ISP. Cirripede [26] and Telex [60] attempted to mitigate this by
Phantom hosts are cheap to connect to, and greatly expand the dynamically adding router rules to forward only a subset of traffic
number of viable proxy endpoints that a censor must consider. from a registered client or an active session through the element,
This increases the cost for censors to block, as they must detect and but this nevertheless presented a deployability challenge.
block in real time. Meanwhile, even a censor that could theoretically TapDance [59] offered an alternative design that did not require
detect 90% of phantom hosts with confidence does not significantly the blocking or redirection of traffic, but used a mirror port instead
reduce the effectiveness of a circumvention system, giving Conjure (Figure 2b). In TapDance a client sends an incomplete HTTP request,
an advantage in the censor/circumventor cat-and-mouse game. which causes the decoy site to pause waiting for more data while the
Conjure supports both IPv4 and IPv6, though we note that the station takes over the connection in its place. After a client would
technique is especially powerful in IPv6, where censors cannot ex- receive a packet initiated by the station, its TCP sequence numbers
haustively scan the address space ahead of time to identify addresses would become desynchronized with the decoy site, causing the
that change behavior. Because we fully control the proxy transport, decoy to ignore the packets sent by the client.
connections can live as long as needed, without the complexity This approach reduced the barriers to deployment and TapDance
faced by TapDance. was used in production during a pilot study, serving upwards of
We introduce the Conjure protocol (Section 4) and analyze its 50 000 real-world users [20]. The tap-based approach, however, has
security, finding that it resists a broader range of detection at- some disadvantages. A decoy site will only ignore packets as long
tacks than TapDance. We have implemented Conjure (Section 5) as the sequence numbers stay within its TCP window, and will
and deployed it on a 20 Gbps ISP testbed similar to the TapDance terminate the connection after a timeout. Frolov et al. report that
deployment [20]. Compared to TapDance, we find that Conjure in their pilot, they eliminated roughly a third of potential decoy
has reduced complexity and substantially improved performance sites due to their measured window or timeout values being too
(Section 6): on average, Conjure has 20% lower latency, 14% faster small [20]. Even so, sessions that try to upload non-trivial data
download bandwidth, and over 1400 times faster upload bandwidth. amounts (in excess of about 15 KB) or last longer than the timeout
In addition, Conjure is significantly more flexible than existing Re- value (ranging from 20–120 s) require the user to create new refrac-
fraction Networking protocols, allowing maintainers to respond to tion connections, adding overhead, complexity, and opportunities
2
Conjure: Summoning Proxies from Unused Address Space CCS ’19, November 11–15, 2019, London, United Kingdom

Handshake Handshake (Figure 2c). This design obviates the need for taking over a session
Client Refraction Decoy already in progress, which both simplifies the implementation and
Station Site
eliminates certain attacks, as we will discuss in Section 7.
TLS session TCP reset

(a) First generation systems for Refraction Networking, such as Telex

Registration Signal In all implementations of Refraction Net-
and Cirripede, operated as inline network elements, with the ability to working, a client must send a covert signal to the station to initiate
observe traffic and block specific flows. ISPs worried that if the inline communication. This covert signal is embedded inside communica-
element failed, it could bring down the network. tion fields that must be indistinguishable from random by a censor
without access to a secret/private key available to the station. Past
implementations have used TCP initial sequence numbers [26], the
Handshake
ClientRandom field inside a TLS handshake [29, 60], and the en-
Client Decoy
Site
crypted body of an HTTPS request [59]. In principle Conjure can
use any of these mechanisms for registration, but in our prototype
TLS session [ignored]
we used the HTTPS request body as it offers the greatest flexibility
Tap for the amount of data that can be sent with the registration.

3 THREAT MODEL
Refraction Our deployment model is identical to that of TapDance: we only
Station require a passive tap at the deploying ISP, and the ability to inject
(spoofed) traffic from phantom hosts. Furthermore, we assume
(b) TapDance is a second-generation Refraction Network scheme that
asymmetric routing (i.e. that the tap might only see packets from but
operates without flow blocking, needing only to passively observe traffic
and inject packets. TapDance has recently been deployed at a mid-size
not to the client). However, we assume a stronger threat model for
ISP, but the techniques used to silence the decoy site and participate in the adversary than TapDance, as our design resists active attacks.
the client–decoy TCP connection mid-stream add significant complexity, We assume the censor can block arbitrary IP addresses and net-
performance bottlenecks, and detection risk. works, but faces a cost in doing so if it blocks potentially useful
resources. In particular, we assume it is difficult for the censor
to have complete knowledge of legitimate addresses used, and so
Registration Session
Client Decoy
instead resorts to a blacklist approach to blocking proxies and objec-
Site tionable content. Whitelists are expensive for censors to maintain
Dark Session
and can stifle innovation, and are rarely employed by country-level
Phantom censors.
Tap Host We assume that the censor can know what network the Con-
jure station(s) are deployed in and the prefixes phantom hosts are
selected from, but that blocking those networks outright brings
a collateral damage the censor is unwilling to suffer. Instead, the
Refraction censor aims to identify the addresses that are phantom hosts, and
Station block only those. We note this assumption supposes that the censor
(c) Conjure, our third-generation Refraction Networking design, overcomes does not mount effective routing decoy attacks [27, 49]; we discuss
these limitations. It uses two sessions. First, the client connects to a decoy these attacks further in Section 8.2.
site and embeds a steganographic registration message, which the station We allow the censor access to the client to register and use its
receives using only a passive tap. Second, the client connects to a “phan- own phantom hosts, so the system should ensure that these will
tom host” where there is no running server, and the station proxies the not reveal the phantom hosts of other users. The censor can also
connection in its entirety. actively probe addresses that it sees users accessing, and can employ
tools such as ZMap [11] to scan large network blocks, excepting
Figure 2: Evolution of Refraction Networking large IPv6 prefixes (e.g. a /32 IPv6 prefix contains 296 addresses).
Finally, we assume the censor can replay or preplay any connec-
tions that it suspects involve phantom hosts (or their registration)
for errors. Additionally, keeping the connections to the decoy site in an attempt to confirm. However, the censor wishes to avoid
open for tens of seconds uses up the site’s resources; Frolov et al. disrupting any connections before it knows for certain they are
found that a default configuration of the Apache web server would from Conjure clients, lest they disrupt legitimate connections. This
only keep 150 simultaneous connections open, while the pilot de- means that injecting false data or corrupting TLS sessions is outside
ployment would often result in dozens of connections to the same the scope of the censor, but that the censor can send non-disruptive
decoy site, creating a scaling concern. probes (such as stale TCP acknowledgments) that would normally
Conjure is able to avoid these problems by creating proxies at be ignored. We emphasize that TapDance is observable by censors
unused IP addresses, allowing the station full control over a host it that can send TCP packets in suspected connections, but that our
has created, rather than forcing it to mimic an already existing decoy protocol is robust against this class of censor.
3
CCS ’19, November 11–15, 2019, London, United Kingdom Sergey Frolov, Jack Wampler, Sze Chuen Tan, J. Alex Halderman, Nikita Borisov, and Eric Wustrow

4.1 Registration
We use a form of Refraction Networking similar to TapDance to
register directly with the station, though Conjure registration is
significantly simpler and more difficult to detect than vanilla Tap-
Dance. This is because registration flows are unidirectional; a client
communicates their intent to register to the station without any
response from the station itself. This makes registration flows very
difficult to detect as they can be sent to any site hosted behind the
ISP, and display no evidence of proxy behavior.
While this model of registration gives the client no definitive in-
dication that their registration was successful, the client can attempt
to register multiple times concurrently with the same information,
and expect that one gets through. Alternatively clients can register
intent to use the proxy in other covert ways. For instance, they
could use email [28] or any other existing intermittently available
proxies to register.
A registration connection is sent to a registration decoy: any
site that supports TLS behind the ISP relative to the client. The client
completes the handshake, and sends a normal HTTPS request that
embeds a ciphertext tag in the payload. Conjure leverages the same
steganographic technique as TapDance to encode the ciphertext [59,
§3], however we send a complete request allowing the registration
Figure 3: Conjure Operations — A Conjure session is constructed in two decoy to respond or close the connection. The tag is encrypted such
pieces. First a client registers by sending a TLS connection to the decoy host that it is only visible to the station. The Conjure station passively
(see Figure 2c) with a steganographically tagged payload. This registration observes tagged flows obviating the need to mimic the decoy. In
contains the true “covert” address that the client would like to connect to addition, more potential decoys can be used in comparison to Tap-
and a seed which the Conjure station uses to derive the Phantom IP address Dance, as there is no need to exclude decoys that have timeouts or
for the session (green dashed flow). Second, the client derives the same TCP windows unfavorable for keeping connections open. In our
Phantom IP address and connects directly to it using the proxy protocol
deployment, this results in a modest increase of 25% more decoys
(e.g. OSSH) specified in the registration (purple dotted flow). The station
that could be used than in TapDance.
identifies registered packets by source IP, destination IP, and destination
port (client IP, phantom IP and port respectively). The traffic is passed The tag contains a public key (encoded to be indistinguishable
to a proxy server handling the specific proxy protocol, which ultimately from random using Elligator [2]), and a message encrypted under
proxies traffic to the covert address. Secrets for the individual application the shared secret derived from a Diffie-Hellman key exchange with
proxy service are shared out of band or derived from the secret seed shared the station’s long-term public key hard-coded in the client. The
between client and station during registration, preventing an adversary station uses its private key to compute the same shared secret from
from successfully connecting to the application in follow up probes. the (decoded) client public key, and decrypts the message in the
tag. The censor, without knowledge of either the station or client’s
private key, cannot derive the shared secret, preventing it from
being able to decrypt the message, or even learn of its existence.
4 ARCHITECTURE
Inside the message, the client communicates a random seed, the
Conjure involves two high-level steps. First, clients register with covert address they would like to connect to, the transport protocol
a Conjure station deployed at an ISP, and derive a phantom host they will use, and other configuration-specific information, such as
IP address from a seed shared in the registration. Then, clients flags to signify version, and feature support. The client and server
connect to the agreed upon phantom address, and the station hash the seed to determine which specific IP address from the set of
listening on the tap relays the client’s traffic to a local application. shared CIDR prefixes will be used and registered as a phantom host.
The application brokers traffic to a proxy application specified by It may seem intuitive to instead have the client send the specific
the client in their registration providing a probe resistant tunnel. IP address to register, but allowing the client arbitrary choice also
Figure 3 describes a high-level overview of the Conjure registration allows the censor to register suspected phantom hosts and block
and connection behavior. them if they can be used as proxies. By using a hash of a seed, the
Similar to TapDance [59], our design does not require expensive censor would have to pre-image the hash to obtain a seed it could
in-line flow blocking and is accomplished with only a passive tap use to register for a desired IP address. We discuss the intricacies
at the ISP, imparting little to no burden on their infrastructure of phantom IP address selection in Section 6.2.
and service reliability. Our architecture is also modular, in that the Once the phantom host IP address has been selected, the station
registration and connection steps operate independently, allow- watches for packets with the source address of the original client
ing a wide range of flexibility to evade censors. We describe each and the phantom as the destination, and forwards them on to the
of these components, and then describe our implementation and a local application handling transports. The station only forwards
deployment in Section 5.
4
Conjure: Summoning Proxies from Unused Address Space CCS ’19, November 11–15, 2019, London, United Kingdom

packets that originate from the IP address of the registering client, obfuscated by encrypting it and sending headerless ciphertext mes-
making the phantom host appear firewalled off to everyone but sages. Similar to OSSH, clients can only connect to obfs4 servers
the client. We note that censors have been observed taking over by proving knowledge of a secret. Probing censors that do not have
client IP addresses for follow-up probing [14]. This would allow the secret get no response from obfs4 servers, making it difficult
censors to hijack registrations if they can connect within the small for censors to confirm if a host is a proxy. Server IPs and their cor-
window between client registration and connection. However this responding secrets are normally distributed out-of-band through
only allows the censor to communicate to the local application Tor’s bridge distribution system.
that handles transports, it does not connect them to the covert During registration, the Conjure client and station could use
address that the client indicated in their registration. Filtering by the registration seed to derive the obfs4 secrets (NODE_ID and
client IP and phantom IP also prevents censors from enumerating server private/public keys) needed for the client to connect. The
the address space before hand, as they would have to do so from station could then launch an obfs4 server instance locally for the
every potential client IP address. Simply scanning the prefixes with client to connect to as a transport using the derived secrets. If a
ZMap [11] from a single vantage point would not reveal hosts that censor attempts to connect to the phantom address (even using the
only respond to specific IPs (e.g., firewalled subnets). client’s IP), it will not receive a response, as it does not know the
registration seed used to derive the obfs4 secrets.
4.2 Transports Using obfs4 as a Conjure application has the added benefit
that servers and secrets do not need to be distributed out-of-band,
Once the client has registered, packets sent to the phantom host IP
eliminating one of the main ways censors currently block existing
address are detected at the station and passed to the local applica-
obfs4 instances [7]. Instead, each Conjure obfs4 instance is private
tion which provides proxy access to the client. A viable Conjure
to its registering client, and there is no public service that censors
transport has two main requirements: first, the protocol it uses with
can use to discover them.
the client must be difficult for the censor to passively detect and
block by traffic inspection. Second, the endpoint must resist active 4.2.3 TLS. TLS is a natural protocol for Conjure applications, be-
probes by the censor (who does not know some shared secret). cause it is ubiquitous on the Internet (making it difficult for censors
Any protocol that satisfies these criteria can be used as an effec- to block), while also providing strong cryptographic protection
tive transport with Conjure. In this section, we describe various against passive and active network adversaries. However, there are
existing protocols (OSSH and obfs4) as well as introduce our own several challenges to make it robust against censors that wish to
(Mask sites, TLS 1.3 eSNI, and phantom WebRTC clients) that can block a particular service.
be used in Conjure, and evaluate how each meet the necessary One challenge is that TLS sends important server-identifying
requirements. Table 1 compares the application protocols. Conjure content in plaintext during the TLS handshake. This includes the
uses a modular approach to transports because research into proxy Server Name Indication (SNI) in the Client Hello message that
detection is ongoing. Having a variety of supported transports gives specifies the domain name, and the X.509 Certificate of the server.
clients a quick way to pivot and maintain proxy access even when To evade censors, we must send a plausible SNI value (sending no
new proxy protocol vulnerabilities are discovered. SNI is uncommon and easily blocked—only 1% of TLS connections
do not send the SNI extension [21]), and we must have the server
4.2.1 Obfuscated SSH. Obfuscated SSH [31] (OSSH) is a protocol respond with a plausible (and corresponding) certificate. Even if
that attempts to mask the Secure Shell (SSH) protocol in a thin we manage to avoid sending either in the clear (e.g. using session
layer of encryption. This makes it difficult for censors to identify resumption), censors could actively probe the server in a way that
using basic packet filters, as there are no identifying headers or would normally elicit a certificate.
fields to search for. Instead, Obfuscated SSH clients first send a
Encrypted SNI TLS 1.3 [46] offers several features that may
16-byte random seed, which is used to derive a symmetric key
greatly simplify Conjure transport design. For instance, TLS 1.3
that encrypts the rest of the communication. Early versions of
handshakes include encrypted certificates, removing a strong traffic
OSSH were passively detectable by censors, who could observe the
classification feature. Unfortunately, TLS 1.3 currently still sends
random seed and derive the key, allowing them to de-obfuscate the
the SNI in the (plaintext) Client Hello, meaning we would have to
protocol. These versions also did not protect against active probing
choose a realistic domain to fool a censor.
attacks, as a censor could easily create their own connections to
However, there are proposals to encrypt the SNI in the Client
confirm if a server supports the protocol.
Hello [47], though none have been implemented or deployed as of
More recent versions of OSSH, such as those used by Psiphon [44],
2019. Nonetheless, if widely adopted, Encrypted SNI (ESNI) would
mix a secret value into the key derivation, thwarting the naive pas-
offer a powerful solution for Conjure applications by allowing the
sive detection/decryption attack. The secret is distributed out-of-
client to use plain TLS as the transport while remaining hidden from
band along with the proxy’s address, and is unknown to a passive or
the censor. Censors could still try to actively probe with guesses
active-probing censor. If a client connects and cannot demonstrate
for the SNI, but servers could respond with generic “Unknown
knowledge of the secret, the OSSH server does not respond, making
SNI” errors. If such responses were common for incorrect SNI, the
it more difficult for censors to discover OSSH servers via active
censor’s efforts to identify phantom hosts would be frustrated.
probing attacks.
Mask Sites Another option to overcome active and passive prob-
4.2.2 obfs4. obfs4 [52] is a pluggable transport used by Tor [8] de- ing attacks is to mimic existing TLS sites. In this application, we
signed to resist both passive detection and active probing. Traffic is simply forward traffic between any connecting clients and a real
5
CCS ’19, November 11–15, 2019, London, United Kingdom Sergey Frolov, Jack Wampler, Sze Chuen Tan, J. Alex Halderman, Nikita Borisov, and Eric Wustrow

TLS site. To a censor, our phantom site will be difficult to distin-

as 2]

s
]

TL Site
1

W NI

C
[5
[3

RT
eS
guish from the actual “mask” site, making it expensive for them to

4
SH

k
fs

eb
S
OS
block without potentially blocking the real site. TLS connections

ob

M
to the Conjure station will terminate exactly as connections to the Active probe resistant
mask site would, with Conjure acting as a transparent TCP-layer Randomized or Tunneling R R T T T
proxy between the client and mask site. However, this leaves the Known passive attack [15] [53] - - -
application unable to introspect on the contents of the TLS con- Conjure implementation # # #
nection to the mask site, as it does not have the client-side shared
secrets, and it cannot overtly man-in-the-middle the connection Table 1: Conjure Applications — “Active probe resistant” protocols are
before knowing it is communicating with the legitimate client (and designed to look innocuous even if scanned by a censor. “Tunneling” (T)
not the censor). protocols use another protocol (e.g. TLS) to blend in, while “Randomized”
To covertly signal to the relaying application, the client changes (R) ones attempt to have no discernable protocol fingerprint or headers. For
existing protocols, we list any known attacks suggested in the literature
the shared secret it derives with the mask site to something that
that let censors passively detect them. We also list if we have implemented
the Conjure station can also derive. The client’s first Application the application in our prototype.
Data packet is thus encrypted under a different secret than the
client/mask site secret. Specifically, the client uses the seed sent dur-
ing registration to derive the pre-master secret for the connection.
The new pre-master secret is hashed along with the client and server In practice, clients can often try multiple phantom hosts/mask
randoms of the current (mask site) TLS connection to obtain the sites over several attempts, as blocking the client outright may
master secret that determines encryption/decryption/authentication negatively impact other unrelated users behind the same network
keys. (e.g. in the case of NAT). Thus, even a censor that can block most but
The Conjure station can determine if the client did this by trial not all mask site usage (i.e. by employing website fingerprinting)
decryption with the master secret derived from the known seed only delays access, and doesn’t prevent it outright.
shared at registration. If it succeeds, the client has proved knowl-
edge of the seed, and the application can respond as a proxy. If not, 4.2.4 Phantom WebRTC Clients. Phantom hosts could also pretend
the application simply continues to forward data between the client to be clients instead of servers. This may potentially give censors
and the mask site, in case a client’s IP was taken over by a censor less to block on, as actively probing clients commonly returns few
after registration. As the censor does not have knowledge of the or no open ports. A censor may also be hesitant to block client-to-
seed used in registration, it cannot coerce the application to appear client communication, as it could block peer-to-peer applications
as anything besides the mask site. as well as many video conferencing protocols. WebRTC is a natural
choice for a client-to-client transport in censorship circumvention,
Mask Site Selection Selecting which sites to masquerade as and is already used in existing schemes like Snowflake [23]. Conjure
must be done carefully to avoid censors being able to detect obvious could also use WebRTC as the transport protocol, convincing the
choices. For example, if a small university network has a phantom censor that two clients are communicating.
host in their network that appears to be [Link], it would be easy
for a censor to block as a likely non-legitimate host. Likewise, if a 5 IMPLEMENTATION
phantom host at an IP address pretends to be a domain that globally We implemented Conjure and deployed a station at a mid-sized
resolves to a single (different) IP address, the censor could also transit ISP tapping traffic from a 20 Gbps router. We used PF_RING
trivially identify and block the phantom host. Several approaches to consume the 20 Gbps link, and feed it to a custom detector writ-
are possible: ten in Rust. The detector processes all packets and watches for new
Nearby sites: pick websites that are legitimately hosted in or near registrations. Once a registration is detected the local application is
the network of the phantom host addresses effectively creat- notified via an out-of-band ZMQ [61] connection, which provides
ing copies of legitimate sites. However, other signals such the registering client’s IP address, the seed, and other configuration
as DNS may reveal the true mask site. information. We note that this is not along a critical timing path
Popular sites: choose mask sites from a list such as the Alexa top for proxying connections and no client packets are sent over ZMQ.
site [1] list. Although it may be wise to avoid sites that are The detectors forwards all packets destined for a (registered)
obviously not hosted in the phantom host address range, phantom host address to the local application via tun interfaces
such as large companies that run their own data centers and and iptables DNAT rules that rewrite the destination IP, allowing
own their own ASN. The list could also be filtered to domains the local application to accept and respond to connections using
that resolve to different IP addresses from different vantage the native operating system’s interface. Figure 4 shows the over-
points, making it harder for a censor to know if a phantom all architecture of our implementation, which we describe in the
host corresponds to a domain’s IP. following subsections.
Passive observation: collect sites by passively observing DNS re-
quests, TLS SNI, or certificates that pass by at the network 5.1 Detector
tap. This would allow for building a realistic set of sites that We implemented our detector in approximately 1,800 lines of Rust,
are plausibly in the vicinity of the phantom host addresses compared to over 5,000 lines for TapDance (excluding from both
that pass by the tap. auto-generated protobuf code).
6
Conjure: Summoning Proxies from Unused Address Space CCS ’19, November 11–15, 2019, London, United Kingdom

proxies after they go unused for a set time. However, this could
leave one core (that sees active proxy use) forwarding packets to the
application, while other cores (that do not see use) would timeout
the proxy. A censor could probe the phantom proxy and observe
this behavior: if the censor’s packets are processed on a forwarding
core, the censor can establish a TCP connection with the phantom
application. Otherwise, if they are processed on a timed out core,
the censor’s packets will be ignored. Through multiple connections,
the censor could use this strange behavior (of intermittent TCP
response) to identify and block potential phantom proxies.
To address this issue of differing core timeouts, we implemented
a new load-balancing algorithm in PF_RING to select the core based
only off the destination IP address of a packet. This means that all
packets sent to a particular phantom proxy address are processed by
the same detector core, which allows the phantom proxy’s timeout
state to be consistent regardless of what source attempts to connect
to it.

5.2 Client
Figure 4: Station Architecture — We used PF_RING to receive packets
from a 20 Gbps tap which we load balance across 4 CPU cores. The detector
We created a Conjure client and integrated it with the Psiphon [44]
processes identify registrations, sending notification to all other cores via anticensorship client. Psiphon has millions of users in censored
redis and to the local application via ZMQ when a new registration is countries, and we are in the early stages of rolling Conjure out to
received. The detector also identifies packets associated with registered real-world users.
flows and diverts them to the local application which handles proxying Our Conjure client is written in Golang, and uses the Refraction
connections. The local application determines which transport the flow Networking tagging schema (Section 4.1) for registration. We note
should use based on a parameter specified in the client’s registration and that this protocol will be more difficult for censors to observe than
initializes a goroutine to handle forwarding. A censor trying to interfere in normal TapDance because it consists of only a single (complete)
this connection would need to take over the clients IP address in a precise request, and the station does not have to spoof packets as the decoy
window (after the registration but before the client connects to the phantom)
during registration, only passively observe them.
and correctly guess the phantom host’s IP address (or connect to all possible
phantom IPs) before the active probe traffic gets to the local application. At
We implemented support for two of the transports in our client:
this point their connection will fail in a manner specific to the transport Obfuscated SSH used by Psiphon (Section 4.2.1) and our TLS Mask
that the client specified in the registration (e.g. connecting to OSSH without Site protocol (Section 4.2.3). Our client signals which transport it
knowledge of the pre-shared secret). will use in the registration tag along with a flag indicating whether
the client supports IPv6, allowing IPv4-only clients to derive exclu-
sively IPv4 phantom hosts. After registration, the client connects to
To achieve performance needed to operate at 20 Gbps, we used the derived phantom host address, and speaks the specified trans-
PF_RING [42] to load balance incoming packets across 4 CPU cores, port protocol, which tunnels between the client and either the mask
which each run a dedicated detector process. PF_RING supports site transport local to the station or Psiphon’s backend servers. A
load balancing packets based on either their flow (5-tuple), or their SOCKS connection can be initiated through this tunnel to allow for
source/destination IPs, which allows connections to be processed connection multiplexing.
by a single process without requiring communication across inde-
pendent cores.
5.3 Application and Transports
However, in Conjure, registration connections and phantom
proxy connections could end up being load balanced to different We implemented our station-side application in about 500 lines
cores. In order for an individual detector process to forward phan- of Golang. This includes support for OSSH (via integration with
tom proxy connections to the application, it must know about the Psiphon) and Mask Sites, both specifiable by the client during reg-
original registration, even if that registration was observed by a istration. We note that support for other transport protocols (e.g.
different core. To address this, we used Redis [30] to allow each Obfs4 or WebRTC) can be added as development continues.
core’s process to broadcast (publish) newly registered decoys to 5.3.1 OSSH. Our Conjure implementation includes support for
the other cores so they can add them to their local list of registered OSSH through integration with Psiphon. Client traffic is forwarded
phantom host addresses. Broadcasting registrations across all cores to a Psiphon server by using Conjure as a transparent proxy. This
ensures that each detector process sees all registrations, and can symbiotic relationship provides Conjure with active and passive
forward phantom proxy connections accordingly. probe resistance, while preventing censors from being able to inex-
A second problem arises when considering how to timeout un- pensively block Psiphon’s backend servers individually.
used phantom proxies in the detector. When a phantom proxy is
timed out, it no longer responds to any active probes. A naive imple- 5.3.2 Mask Sites. We implemented a mask site mimicking proxy,
mentation might simply have each core timeout unused phantom that pretends to be a mask site when actively probed by the censor.
7
CCS ’19, November 11–15, 2019, London, United Kingdom Sergey Frolov, Jack Wampler, Sze Chuen Tan, J. Alex Halderman, Nikita Borisov, and Eric Wustrow

Once the station accepts accepts a connection for a registered flow, latency to about 10% of requests. In addition, the median latency
it initially acts as a transparent proxy to a mask site specified by the of Conjure is about 19% faster, due to the added overhead of TLS
client during registration. The application parses the handshake, and the complex path that TapDance data packets take through the
forwarding packets back and forth between client and mask site station compared to Conjure.
without modification, extracting the server and client randoms. The
application attempts to decrypt the first application data record 6.2 Address Selection
from the client using a key derived from the secret seed, client, Phantom host IP addresses must be derived from network blocks
and server randoms. We use the uTLS library [21, 41] on both the that are routed (so they pass the Conjure station) and contain other
application and client to allow us to change the TLS secrets being legitimate hosts (so that censors cannot block the entire network
used after the handshake. without collateral damage). Because of the large number of IPv6 ad-
If the decryption is successful, the application switches to for- dresses, even moderately-sized network prefixes have astronomical
warding (decrypted) data back and forth with a client-specified numbers of addresses: a single /32 prefix has 296 possible addresses.
endpoint, such as a SOCKS proxy, which can provide multiple se- Therefore, client-chosen seeds have negligible probability of cor-
cure connections over the single connection to the phantom host. responding to addresses that are already being used by legitimate
hosts. This allows us to select phantom host addresses from net-
6 EVALUATION work prefixes that contain legitimate hosts—crucial to discouraging
To evaluate our Conjure implementation, we compare its band- the censor from blocking them outright—without worry that regis-
width and latency to that of TapDance in a realistic ISP setting. We trations could interfere with legitimate services.
used a 20 Gbps network tap at a mid-sized ISP and run both imple-
6.2.1 IPv4. While Conjure works best with IPv6, it can also support
mentations on a 1U server with an 8-core Intel Xeon E5-2640 CPU,
IPv4, with some careful caveats.
64GB of RAM, and a dual-port Intel X710 10GbE SFP+ network
First, in IPv4, there are substantially fewer addresses, allowing
interface. A typical week of bandwidth seen on the tap is shown in
censors to potentially enumerate all the network prefixes that
Figure 5, ranging from 2.4 Gbps to peaks above 17 Gbps.
pass by the ISP station, compose the list of innocuous sites, and
block other websites, as they are being summoned by Conjure. To
6.1 Performance address this, Conjure phantom hosts are firewalled from all IPs
We evaluated the performance of a client from an India-based VPS. other than the client that registered them, providing a reason why
Figures 6 and 7 show the upload and download bandwidth as mea- the address hasn’t been seen in an enumerating scan, conducted by
sured by iperf for TapDance, our Conjure implementation (using a censor from a single vantage point. Censors could attempt to scan
the mask site application), and a direct connection to our iperf the network from all potential client vantage points, by co-opting
server in the ISP’s network. client IPs to perform scans—a behavior previously observed by the
TapDance must reconnect if the amount of data sent by the client Great Firewall of China to scan for Tor bridges [14]. To prevent
exceeds a short TCP window (typically on the order of 32 KBytes) this, for IPv4 Conjure, we dynamically generate the TCP port of
or the connection persists until a timeout (18-120 seconds). At each the phantom host (along with its IP) from the registration seed,
reconnect, the TapDance client naively blocks until a new TLS con- which further makes exhaustive scans infeasible: a censor that must
nection to the decoy and station has been established. Thus, when enumerate from the vantage point of a /10 of client IPs (4 million
uploading files, TapDance has to create a new TLS connection for IPs) to a /16 (65K IPs) of potential phantom proxies on each of 65K
every 32 KBytes of data it sends, limiting its average upload band- potential ports would take nearly 50 years of scanning with ZMap
width to around 0.1 Mbps due to the high overhead. In contrast, our at 10 Gbps. We note that while the use of non-standard ports could
Conjure implementation is able to maintain the same connection potentially be suspicious, several successful circumvention tools—
during large uploads, and achieves performance inline with the including Psiphon [44] and obfs4 [52]—use random ports on their
direct connection, over 1400 times faster. obfuscated protocols. Finally, we note that censors that whitelist
During download-only workloads, TapDance is able to better uti- either standard ports or discovered hosts from enumerations scans
lize the network, but must still reconnect before the decoy times out. would over-block new services that came online after their scans.
In our tests, we see TapDance reconnect every 25 seconds, which A second problem in IPv4 Conjure is that the limited range of
can negatively impact the performance of downloads or any real- IPs (and ports) makes it possible for a censor to pre-image the
time streaming applications. Again, our Conjure implementation hash used to derive the phantom address from the seed. Even with
is able to maintain a single connection and provide the maximum the /16 of IPs and all 65K ports, in order to find a seed for any
download rate without interruption, 14% faster than TapDance. desired address a censor needs to only test an expected 232 possible
We also measure the latency of repeated small requests. In both seeds. The censor could then register a suspected address, and see
Conjure (using the OSSH protocol) and TapDance we establish a if it provides proxy access. If it does, the censor learns there is no
single session tunnel using our integrated Psiphon client, and make legitimate service there, and can block it. To combat this, we allow
1000 requests through each using Apache Benchmark (ab). We only a single client to register for a particular phantom address at a
find that our India-based VPS throttles TLS but not OSSH, making time. A censor could attempt to register all addresses in an attempt
TapDance twice as slow as Conjure. We repeated these tests on to deny proxy service to legitimate users, but this would be easily
a US-based VPS which does not have such throttling, and show observed at the registration system, where rate limits via client
results in Figure 8. TapDance’s frequent reconnects adds significant puzzles or account-based fees could be enforced.
8
Conjure: Summoning Proxies from Unused Address Space CCS ’19, November 11–15, 2019, London, United Kingdom

Figure 5: Tap Bandwidth — We deployed Conjure in a realistic ISP testbed on a tap of a 20 Gbps router. In a typical week, traffic ranges from 2–17 Gbps.

100
Conjure Conjure
Direct Direct
TapDance TapDance
10 100

1
10
Mbps

Mbps

0.1

1
0.01

0.001 0.1
0 10 20 30 40 50 60 0 10 20 30 40 50 60
Time (s) Time (s)

Figure 6: Upload Performance — We used iperf to measure the upload Figure 7: Download Performance — Using iperf, we compare the down-
bandwidth for a direct connection, TapDance, and Conjure. As expected, load performance of a direct connection, TapDance, and Conjure. While
TapDance’s upload performance is several orders of magnitude lower than TapDance can achieve link-capacity download, it still has to occasionally
the link capacity, due to the overhead of making frequent reconnects to the reconnect to the decoy, as seen by the periodic dips. These reconnects are
decoy site. more common the more data the client sends (e.g. requests or uploads).

Finally, legitimate IPv4 addresses density is much higher than To measure and quantify this problem, we collected and analyzed
IPv6, increasing the potential for users to accidentally register seeds 16 hours of netflow data at our ISP tap. We extracted 4013 IPv6
that derive phantom addresses corresponding to live hosts. To ad- addresses observed in the /32 IPv6 prefix routed by the ISP (out of
dress this, the station sends probes to potential IPv4 phantom hosts 32,817 total observed). To confirm the hypothesis that 0 bits are
during registration, and ignores the registration if a real host re- more common in IPv6 addresses, we counted the number of bits set
sponds. Censors that try to register specific phantom proxies will be in each address. Figure 9 shows a histogram of the number of bits
unable to distinguish if another user has registered it or a legitimate set and compares it to the histogram of a uniformly random set of
host is there, as in both cases we ignore the censor’s registration. addresses. (The random distribution’s center is skewed from 64 due
This also serves to prevent abuse by attackers that attempt to use to the number of set bits in our fixed /32 network prefix.) Although
the Conjure station to interfere with innocuous services. these distributions are distinguishable, they do have significant
overlap. Given enough samples, a censor could trivially tell if the
6.2.2 IPv6. In IPv6 Conjure address enumeration and pre-image addresses were chosen randomly or were legitimate hosts. However,
attacks are infeasible due to a large amount of potential IP addresses. a censor’s job is significantly harder, and they must tell from a single
Our ISP routes a /32 IPv6 prefix, which provides 296 potential phan- sample which distribution it comes from. The presence of random-
tom host IP addresses. However, IPv6 addresses often have long runs looking addresses makes it difficult for censors to block such hosts
of 0 bits in them, and rarely use all 128-bits equally. For instance, outright.
[Link] has the address [Link], which Prior work by Foremski et al. [18] has developed models to gen-
only has 24 bits set to 1. Censors might try to use this observation erate likely IPv6 addresses from a set of known addresses, useful
and block high entropy IPv6 addresses. for discovering new hosts to scan given known ones. We use their
9
CCS ’19, November 11–15, 2019, London, United Kingdom Sergey Frolov, Jack Wampler, Sze Chuen Tan, J. Alex Halderman, Nikita Borisov, and Eric Wustrow

1
Conjure
Entropy/IP tool [18] to generate the random IPv6 phantom hosts
0.9 TapDance from the registration seed based on the Bayesian Network model
0.8 created by the tool.
0.7

0.6 7 ATTACKS AND DEFENSES

CDF

0.5 In this section, we discuss several attacks a censor might attempt

0.4 to either block phantom hosts from being registered or used.
0.3

0.2 7.1 Probing phantom hosts

0.1
Censors may attempt to actively probe suspected phantom hosts to
0
0 200 400 600 800 1000 determine if they are proxies or real hosts. China has been observed
Latency (ms) using exactly this technique to discover existing proxies and Tor
bridge nodes [7, 14, 57, 58]. In response to China’s active probing,
Figure 8: Latency — We compare the CDF of latency for requests between Tor and other circumvention tool developers have developed probe-
Conjure and TapDance. In each case, we have a long-lived session over resistant protocols, such as obfs4 [52], Obfuscated SSH (OSSH) [31],
which requests are being made using Apache Benchmark (ab). At the me- and Shadowsocks [50]. Each of these protocols require the client
dian, Conjure has 44 ms (19%) faster latency than TapDance. In addition,
to know a secret distributed alongside the original proxy address.
TapDance requests are frequently slowed by its intermittent reconnections
Without knowledge of this secret, active-probing censors will not
to the decoy, as shown in the longer tail of TapDance’s latency CDF. Conjure
has no such reconnects, and thus has more uniform latency. At the 99th receive any response from these hosts, making it difficult for censors
percentile, Conjure is 281 ms (92%) faster than TapDance. to tell if a server is a proxy or a non-responsive legitimate host.
Obfuscated SSH Modern OSSH protocols are intended to be
12
probe-resistant. Censors that attempt to probe suspected OSSH
Observed servers without knowledge of the secret receive no data response,
Random
10 making it difficult to distinguish them from other non-responsive
hosts. To confirm this, we use ZMap [11] to scan over 1 billion
8 random IP/port combinations, and sent 25 random bytes (corre-
sponding to the OSSH handshake) to the approximately 800,000
% IPs

6
servers that responded. We expect very few of these to actually be
OSSH servers as they are simply random servers on random TCP
4
ports. However, over 99.4% of them did not respond with any data,
2 behavior mirrored by OSSH servers. Furthermore, 7.42% of servers
closed the connection with a TCP RST after we send our random
0 data, a response we also see with OSSH. While there may be other
0 20 40 60 80 100
ways to differentiate OSSH servers from others online, our tests
IPv6 address bits set
suggest censors could face steep false-positive rates in identifying
Figure 9: IPv6 Bits Set — We measure the number of bits set to 1 in IPv6 OSSH servers with active probing.
addresses in our ISP’s /32 and observed by our tap, and compare it to the Bi- obfs4 Unlike previous versions of obfsproxy, the obfs4 protocol
nomial distribution (Random) we would expect to see if the 96 non-network is designed to be resistant to active probing attacks, requiring the
bits of each address were chosen randomly. In practice, we observe much client prove knowledge of a secret before the server will respond.
fewer bits set. Nonetheless, the significant overlap of these distributions We verified that naive active probing attacks (where we attempt to
would make it difficult for censors to block any individual phantom hosts connect to an obfs4 server without knowledge of the secret and see
without collateral risk of blocking legitimate services.
if it provides proxy access) do not work against obfs4. In addition,
although China is effective at blocking obfs3, the more recent
Entropy/IP tool to analyze the addresses we collected. Figure 10 probe-resistant obfs4 remains a viable proxy in the country.1
shows the normalized entropy of each address 4-bit nibble and the Mask sites The censor could also attempt to fingerprint a masked
total entropy (18.8 out of 32). Nibbles that were constant across all site and compare it to a suspected Conjure application. For in-
addresses (such as the /32 network prefix nibbles) have zero entropy, stance, if a phantom host IP responds to a censors’ probes pretend-
while those that equally span the range of values have maximum en- ing to be [Link], the censor could probe real instances of
tropy (normalized to 1). In our addresses, we observe an entropy of [Link] on different ports and see how it responds. Then, the
over 75 bits, with more entropy in the later segments of the address. censor can probe the phantom host IP, and see if it responds sim-
While not quite the full 96 bits that uniformly random would pro- ilarly (e.g. with the same set of open ports and payloads for certain
duce, this is still a significant amount for phantom hosts to hide in. kinds of probes). To defend against this, we forward all traffic des-
For a specific deployment, operators should be careful to observe tined to the phantom host to the masked site, including ports that
the distribution of addresses in the subnets they use, and possibly 1 E.g.,
[Link]
limit to randomizing “realistic” bits (e.g. the upper and/or last 32 27&end=2019-09-25&country=cn shows obfs4 clients from China successfully using
bits within the given /32). As an improvement, we could also use the Tor.
10
Conjure: Summoning Proxies from Unused Address Space CCS ’19, November 11–15, 2019, London, United Kingdom

is still possible for censors to use active probing attacks to detect

either protocol feature, payload size, or timing differences between
mask sites and the real sites they attempt to mimic.

7.2 Passive identification

Censors might also attempt to use passive methods to distinguish
and block communication with registration decoys or phantom
hosts. For example, Website Fingerprinting [24, 51, 56] (WF) uses
the patterns of encrypted traffic to identify which website a client is
connected to. WF uses a classifier to label the traffic as belonging to
one of several known websites, or (in some variants), an unknown or
background class. Though WF is commonly studied in the context
of anonymous web browsing, a censor could also use WF to detect
Conjure applications by distinguishing known traffic patterns of
legitimate website use from traffic generated by Conjure (unknown
class). Alternatively, the censor could monitor traffic for patterns
Figure 10: IPv6 Entropy — Censors may be able to distinguish random- consistent with tunneled access to a set of blocked websites.
looking phantom host IPv6 addresses from legitimately used ones based Wang et al. [53] demonstrated several effective classifiers that
on the address’s entropy. We used the Entropy/IP tool [18] to analyze the can passively distinguish normal traffic from obfuscated circum-
entropy of 4013 IPv6 addresses observed by our tap. This plot from the tool vention protocols including obfs3, obfs4, Format-transforming
shows the normalized entropy of each nibble in the addresses, which is fairly encryption [12], and meek [17]. However, despite the low false
high for most of the non-network prefix nibbles. In total, these addresses positive rate of these classifiers, Wang et al. [53] caution that the
have about 75 bits of entropy (out of 96 expected), and the relatively high
base rate of normal traffic compared to obfuscated traffic would
entropy present in each nibble would make it difficult for a censor to block
without significant false positives / negatives. While distinguishable from
force censors that employ such attacks to suffer significant collat-
random given enough samples, we can also use the Entropy/IP tool to eral damage in degrading performance and reliability of legitimate
generate addresses from the Bayesian Network model it produces. traffic. Indeed, to date, censors have not been observed using WF
or other passive techniques, possibly due to the inaccuracy of these
identification techniques in practice. Even small false positive rates
are not relevant to the proxy application (e.g. non 443). This ensures means blocking mostly legitimate connections, and false negatives
that above the TCP layer, we appear to be the mask site. However, could allow clients to retry until they gain access.
there may be differences in TCP/IP implementations, for instance, More importantly, Conjure applications offer great flexibility
how IP IDs are incremented, or how TCP timestamps are incre- in deploying traffic analysis defenses; for example, traffic shaping
mented (or supported at all) that may be different from the mask site. strategies such as implemented in Slitheen [3] could be easily em-
To combat this, we can filter mask sites by those that have identical ployed in Conjure. Conjure clients could also choose from a large
TCP/IP stacks to ours, as we use a common Linux implementation. set of potential applications, forcing censors to have to block access
We also note that this attack only applies when we use the mask site to all of them to block use.
as an application, and that Conjure can support other applications
(e.g. obfsproxy, WebRTC, etc) that do not have this issue.
7.3 Blocking registration
We acknowledge that perfect mimicry of the real site is likely
infeasible: Houmansadr et al. [25] demonstrated the difficulty in To make registration more difficult, censors could block TLS connec-
fully mimicking known applications, showing that staying fully- tions to all of the limited decoys available in a deployment. Using
feature compatible is an expensive and potentially intractable prob- TapDance’s current deployment, this would involve blocking over
lem for circumvention systems. However, their study focuses on 1500 sites. We note that such an attack would completely disable
application-specific mimicry, used by circumvention tools like Cen- all existing Refraction Networking schemes, as none work without
sorSpoofer, StegoTorus, and Skypemorph. These tools generally being able to access legitimate decoys past the station. In Conjure,
attempt to mimic a specific protocol used by a complex applica- this would only block new registrations, and would not impact
tion such as Skype, where only one or a handful of official popular users that previously registered. Furthermore, registrations could
clients are used. Houmansadr et al. [25] show that such mimicry also occur over email, or over lower-bandwidth covert channels,
is difficult in practice due to the complexity and opaqueness of such as port (or even IP) knocking past the station, that would be
specifications, side protocols that applications may use, and intra- more difficult for the censor to block.
and inter-dependence on connections and other protocols.
In contrast, mask sites have the advantage that we can mimic 7.4 ICMP
any sites from a large set of heterogeneous real websites, making Censors can use ping or traceroute utilities (via ICMP) to probe
it harder for a censor to fully fingerprint and characterize all po- potential phantom hosts. Because there is (usually) no host at the
tential mask sites. As websites may themselves use distributed or phantom host address, these probes will timeout and produce no
heterogeneous server implementations, it could be more difficult response. They might also produce “Destination Unreachable” re-
for a censor to block all mask site application use. Nonetheless, it sponses from routers depending on how they are configured. We
11
CCS ’19, November 11–15, 2019, London, United Kingdom Sergey Frolov, Jack Wampler, Sze Chuen Tan, J. Alex Halderman, Nikita Borisov, and Eric Wustrow

performed a scan of 10 million IPv6 addresses in a routable /32 and introduces a large overhead as it has to wait for the subset
prefix to see if it is common to respond with such tell-tale ICMP of data-carrying packets from the decoy that Slitheen can safely
messages for unused messages. We found only 0.016% of addresses replace. We note that the Slitheen model of mimicry is compatible
responded with any ICMP messages (mainly “Time Exceeded” and with Conjure, as we could use Slitheen as the application protocol.
“Destination Unreachable”). Despite using a passive tap, our scheme is effectively inline to the
Many legitimate hosts and routers do not respond to or forward phantom host (which won’t otherwise respond).
ICMP packets, and it is common for firewalls to block traceroutes Bocovich and Goldberg propose an asymmetric gossip scheme [4]
from penetrating inside networks. Thus, simply ignoring ICMP that combines a passive monitor on the forward path from the client
messages (or low TTL packets that might be used by traceroute) to the decoy with an inline blocking element on the return path.
may be a viable strategy. Alternatively, we could spoof responses These elements work in concert to allow schemes such as Telex
to convince an adversary that a phantom host is part of a particular and Slitheen to work on asymmetric connections. This approach,
network. However, this strategy requires careful consideration of however, still requires inline blocking on one direction, and fur-
what network makes sense for a mask site to be in. Also, the censor ther complicates deployment by requiring the installation of more
may try to probe for addresses around the phantom host (but still components and potentially complex coordination between them.
likely to be in the same network), which must also be responded to. MultiFlow [34] uses refraction networking only as a forward mech-
anism to communicate a web request to the station, and then uses
8 RELATED WORK a bulletin board or email to deliver the response back. It does not
require inline flow blocking as it does not modify users’ traffic at all,
We first compare Conjure with other Refraction Networking schemes
but it fundamentally relies on a separate data delivery mechanism,
and then discuss other related work.
similar to other cloud- or email-based circumvention tools [5, 28].
Conjure allows a large amount of flexibility compared to previ-
8.1 Prior Refraction Networking Schemes ous schemes. Because we have significant degrees of freedom in
Since 2011, there have been several proposed Refraction Network- choosing the specific application the phantom host will mimic or
ing schemes. Telex [60], Cirripede [26] and Decoy Routing (aka talk, our scheme can combine the best of existing Refraction Net-
Curveball) [29] are “first generation” protocols with nearly identical working protocols to achieve high performance, be easy to deploy,
features. These designs require inline flow blocking at the ISP to and also be resistant to active attacks such as replaying or prob-
allow the station to intercept flows with detected tags and act as ing by the censor. Table 2 lists the existing Refraction Networking
the decoy host for them. However, inline blocking is difficult for schemes and their features, as compared to Conjure.
ISPs to deploy, as it requires special-purpose hardware to be placed
inline with production traffic, introducing risk of failures and out- 8.2 Decoy Placement and Routing Attacks
ages that may be expensive for the ISP and potentially violate their Houmansadr et al. [26] found that placing refraction proxies in
contractual obligations (SLAs). a handful of Tier 1 networks would be sufficient for them to be
TapDance [59] solves the issue of inline-blocking by coercing usable by the majority of the Internet population. Cesareo et al. [6]
the decoy into staying silent, and allowing the station to respond developed an algorithm for optimizing the placement of proxies
instead. However, as previously described, this trick comes at a cost: based on AS-level Internet topology data. Schuchard et al. [49]
the decoy only stays silent for a short timeout (typically 30–120 s), suggested that a censor may actively change its routes to ensure
and limits the amount of data the client can send before it responds. traffic leaving its country avoids the proxies, but Houmansadr et
TapDance clients must keep connections short and repeatedly re- al. [27] suggested that real-world constraints on routing make this
connect to decoys, increasing overhead and potentially alerting attack difficult to carry out in practice. Nevertheless, Nasr et al. [39]
censors with this pattern. Conjure addresses this issue and allows propose a game-theoretic framework to optimize proxy placement
clients to maintain long-lived connections to the phantom host. in an adversarial setting, and the design of Waterfall [40] is in part
Rebound [13] and Waterfall [40] both focus on routing asym- motivated by resilience to routing attacks, as it is more difficult for
metries and routing attacks by the censor. Rebound modifies the the censor to control the return path from a decoy site, rather than
client’s packets on the way to the decoy, and uses error pages on the forward path.
the decoy site to reflect data back to the client. Waterfall only ob- In practice, deployment of refraction networking has so far been
serves and modifies the decoy-to-client traffic, similarly using error at access, rather than transit ISPs [20]. This may be in part because
pages on the decoy to reflect communication from the client to a transit ISP has a large number of routers and points-of-presence,
the station. These schemes also provide some resistance to traffic significantly raising the costs of deployment [22].2 Likewise, we
analysis, as they use the real decoy to reflect data to the user. Thus, expect Conjure to use address space announced by the ISP, rather
the TCP/TLS behavior seen by the censor more closely matches than addresses relayed by it, which mitigates routing-based attacks.
that of a legitimate decoy connection. However, latency and other Depending on the size of the ISP, however, a censor may decide to
packet-timing characteristics may be observable, and both schemes block the entirety of its address space, which would incur smaller
require some form of inline flow blocking. collateral damage than blocking all addresses seen by a transit ISP.
Slitheen [3] focuses on addressing observability by replacing
data in packets sent by the legitimate decoy. Thus, even the packet 2 We note that Gosain et al. [22] use an estimate of $885,000/proxy, while Frolov et
timings and sizes of a Slitheen connection match that of a legitimate al. [20] report line-rate TapDance deployment using commodity hardware that costs
decoy connection. However, Slitheen also requires inline-blocking, only several thousand dollars.
12
Conjure: Summoning Proxies from Unused Address Space CCS ’19, November 11–15, 2019, London, United Kingdom

un [59] ]
29
Re nce g [
Ta Ro ]

ur ]
a in

3]
6

nj [40
co [2

pD ut

3]
ith d [1
rr ]

W en [
De ede

Co fall
Ci [60

e
y

er
ip

e
ex

bo

at
l
Te

Sl
No inline blocking # # # # # #
Handles asym. routing # # #
Replay attack resistant #
Traffic analysis resistant # # # # #
G #
G #
Unlimited Session Length # # # #
Table 2: Comparing Refraction Networking Schemes — “No inline blocking” corresponds to schemes that can operate as a passive tap on the side without
needing an inline element in the ISP network. “Handles asymmetric routes” refers to schemes that work when only one direction (either client to decoy or
decoy to server) is seen by the station. “Replay attacks” refers to censors who may replay/preplay previous messages or actively probe the protocol. “Traffic
analysis” includes latency, inter-packet timing, and website fingerprinting. “Unlimited Sessions” shows schemes that do not need to repeatedly reconnect to
download or upload arbitrarily large content.

8.3 Avoiding Destination Blocking transports and simplicity of registration allows Conjure to incor-
Traditionally, proxies deployed for censorship are eventually iden- porate state of the art censorship circumvention tools and resist
tified and blocked by the censor. Several proposals have been made nation-state censors.
to carefully control the distribution of proxy addresses, using so- One obvious future direction is to study new options for regis-
cial connections and reputation [9, 38, 55]. Nevertheless, keeping tration and proxy transport. For instance, while Conjure currently
this information secret is challenging; additionally, censors often uses a TapDance- style covert channel for registration, we could
employ active scanning techniques to discover proxies [10]. Re- potentially cut down on the overhead of one-time registration by us-
fraction networking generally assumes that clients have no secret ing port-knocking or using a Telex-style [60] tag (in the ClientHello
information, and instead relies on the collateral damage that would rather than Application Data).
result from blocking all the potential decoy destinations. Conjure Client-side applications Conjure provides an interesting op-
furthers this goal by creating a large number of destinations out portunity to explore client mimicking phantom hosts. Rather than
of the dark space. A similar approach was conceptualized in DE- pretend to be a server (e.g., a mask site), our transport itself could
FIANCE [32], where censored Tor clients connect to pools of ad- connect to a newly registered client from the phantom host ad-
dresses that are volunteered to run Tor bridge nodes. DEFIANCE dress. Possible protocols could include WebRTC, mentioned in Sec-
also requires volunteer web servers to run specialized servers to dis- tion 4.2.4, or other peer-to-peer protocols such as BitTorrent, Skype,
tribute information. Unlike Conjure, DEFIANCE was not designed or Bitcoin.
to run at an ISP, and involves many moving parts that present Traffic analysis Conjure could also support applications that
single points of failure if blocked by a censor. In contrast, Con- tradeoff performance for observability. While Slitheen offers ideal
jure has a relatively simple yet flexible design, allowing it to easily mimicry of decoys, it comes at a high cost of overhead. Conjure
respond to censors. Another similar approach was taken by Cen- transports such as mask site could implement Slitheen in order
sorSpoofer [54], which spoofed traffic from a large set of dummy to perfectly mimic the decoy site’s latency, packet timings, and
destinations. CensorSpoofer, however, could only send information payload sizes. In addition, careful choice of mask sites may allow
in one direction—to the client—and had to rely on a separate out-of- for higher performance, as sites with more replaceable content can
band channel for client-to-proxy communication. As an alternative carry more covert data.
approach, FlashProxy [16] and Snowflake [23] allow users to run
Long-term deployment Ultimately, the goal for Refraction Net-
Flash- or WebRTC-based proxies within their browser to allow
working protocols is to be useful in circumventing censorship.
censored users to connect to the Tor network with the potential
While it has taken many years for research protocols to mature, we
to greatly increase the number. In practice, these proxies served
are excited to see schemes like TapDance deployed in practice [20].
a very small number of users, as compared with other Tor bridge
We believe Conjure can be even easier to deploy at scale, and we
transports.3
hope to leverage the existing success of TapDance to place Conjure
stations at real ISPs.
9 CONCLUSION AND FUTURE WORK
Conjure provides a much larger degree of engineering flexibility ACKNOWLEDGMENTS
than previous Refraction Networking schemes. Due to its modu-
The authors thank the incredible partner organizations that have
lar design, different registration protocols and proxy transports
made deployment of Refraction Networking a reality, especially
can be used interchangeably by the client. The flexibility of proxy
Merit Network and Psiphon. We also thank the University of Col-
3 [Link]
orado IT Security and Network Operations staff. This material is
01-01&end=2019-02-15&transport=!<OR>&transport=websocket&transport= based in part upon work supported by the U.S. National Science
snowflake Foundation under Awards CNS-1518888 and OAC-1925476.
13
CCS ’19, November 11–15, 2019, London, United Kingdom Sergey Frolov, Jack Wampler, Sze Chuen Tan, J. Alex Halderman, Nikita Borisov, and Eric Wustrow

REFERENCES [27] Amir Houmansadr, Edmund L. Wong, and Vitaly Shmatikov. 2014. No Direction
[1] Alexa Internet, Inc. 2019. Alexa Top 500 Global Sites. [Link] Home: The True Cost of Routing Around Decoys. In 21st Annual Network and
topsites. Distributed System Security Symposium, NDSS 2014. The Internet Society.
[2] Daniel J Bernstein, Mike Hamburg, Anna Krasnova, and Tanja Lange. 2013. [28] Amir Houmansadr, Wenxuan Zhou, Matthew Caesar, and Nikita Borisov. 2017.
Elligator: Elliptic-curve points indistinguishable from uniform random strings. In SWEET: Serving the Web by Exploiting Email Tunnels. IEEE/ACM Transactions
20th ACM Conference on Computer and Communications Security (CCS). 967–980. on Networking 25, 3 (Jan 2017).
[3] Cecylia Bocovich and Ian Goldberg. 2016. Slitheen: Perfectly imitated decoy [29] Josh Karlin, Daniel Ellard, Alden W. Jackson, Christine E. Jones, Greg Lauer,
routing through traffic replacement. In 23rd ACM Conference on Computer and David P. Mankins, and W. Timothy Strayer. 2011. Decoy Routing: Toward Un-
Communications Security (CCS). 1702–1714. blockable Internet Communication. In 1st USENIX Workshop on Free and Open
[4] Cecylia Bocovich and Ian Goldberg. 2018. Secure asymmetry and deployability Communications on the Internet (FOCI).
for decoy routing systems. Proceedings on Privacy Enhancing Technologies 2018, [30] Redis Labs. 2019. Redis is open source, in-memory data structure store. https://
3 (2018), 43–62. [Link]/.
[5] Chad Brubaker, Amir Houmansadr, and Vitaly Shmatikov. 2014. CloudTransport: [31] Bruce Leidl. 2009. Obfuscated SSH. [Link]
[32] Patrick Lincoln, Ian Mason, Phillip A Porras, Vinod Yegneswaran, Zachary Wein-
Using Cloud Storage for Censorship-Resistant Networking. In The 14t h Privacy
berg, Jeroen Massar, William Allen Simpson, Paul Vixie, and Dan Boneh. 2012.
Enhancing Technologies Symposium (PETS).
Bootstrapping Communications into an Anti-Censorship System. In 2nd USENIX
[6] Jacopo Cesareo, Josh Karlin, Michael Shapira, and Jennifer Rexford. 2012. Opti-
Workshop on Free and Open Communications on the Internet. USENIX.
mizing the Placement of Implicit Proxies.
[33] Colm MacCarthaigh. 2018. Enhanced Domain Protections for Amazon Cloud-
[7] Roger Dingledine. 2011. Research problems: Ten ways to discover Tor bridges.
Front Requests. [Link]
[Link]
protections-for-amazon-cloudfront-requests/.
[8] Roger Dingledine, Nick Mathewson, and Paul Syverson. 2004. Tor: The Second-
[34] Victoria Manfredi and Pi Songkuntham. 2018. MultiFlow: Cross-Connection
Generation Onion Router. In 13th USENIX Security Symposium. 303–320.
Decoy Routing using TLS 1.3 Session Resumption. In 8th USENIX Workshop on
[9] Frederick Douglas, Rorshach, Weiyang Pan, and Matthew Caesar. 2016. Salmon:
Free and Open Communications on the Internet (FOCI 18). USENIX Association.
Robust Proxy Distribution for Censorship Circumvention. PoPETs 2016, 4 (2016),
[35] Bill Marczak, Nicholas Weaver, Jakub Dalek, Roya Ensafi, David Fifield, Sarah
4–20.
McKune, Arn Rey, John Scott-Railton, Ron Deibert, and Vern Paxson. 2015. An
[10] Arun Dunna, Ciarán O’Brien, and Phillipa Gill. 2018. Analyzing China’s Blocking
analysis of China’s “Great Cannon”. FOCI. USENIX (2015), 37.
of Unpublished Tor Bridges. In Free and Open Communications on the Internet.
[36] Moxie Marlinspike. 2016. Doodles, stickers, and censorship circumvention for
8th USENIX Workshop on Free and Open Communications on the Internet (FOCI
Signal Android. [Link]
18).
[37] Moxie Marlinspike. 2018. Amazon threatens to suspend Signal’s AWS account
[11] Zakir Durumeric, Eric Wustrow, and J. Alex Halderman. 2013. ZMap: Fast
over censorship circumvention. [Link]
Internet-Wide Scanning and its Security Applications. In 22nd USENIX Security
front/.
Symposium.
[38] Damon McCoy, Jose Andre Morales, and Kirill Levchenko. 2012. Proximax:
[12] K. P. Dyer, S. E. Coull, T. Ristenpart, and T Shrimpton. 2013. Protocol misidentifi-
Measurement-driven Proxy Dissemination (Short Paper). In Proceedings of the
cation made easy with format-transforming encryption. In 20th ACM Conference
15th International Conference on Financial Cryptography and Data Security (FC’11).
on Computer and Communications Security (CCS). 61–72.
Springer-Verlag, Berlin, Heidelberg, 260–267.
[13] Daniel Ellard, Alden Jackson, Christine Jones, Victoria Manfredi, W. Timothy
[39] Milad Nasr and Amir Houmansadr. 2016. GAME OF DECOYS: Optimal Decoy
Strayer, Bishal Thapa, and Megan Van Welie. 2015. Rebound: Decoy routing on
Routing Through Game Theory. In Proceedings of the 2016 ACM SIGSAC Confer-
asymmetric routes via error messages. In 40th IEEE Conference on Local Computer
ence on Computer and Communications Security, Vienna, Austria, October 24-28,
Networks (LCN). 91–99.
2016. ACM, 1727–1738.
[14] R. Ensafi, D. Fifield, P. Winter, N. Feamster, N. Weaver, and V. Paxson. 2015.
[40] Milad Nasr, Hadi Zolfaghari, and Amir Houmansadr. 2017. The waterfall of
Examining How the Great Firewall Discovers Hidden Circumvention Servers. In
liberty: Decoy routing circumvention that resists routing attacks. In 24th ACM
15th ACM Internet Measurement Conference (IMC). 445–458.
Conference on Computer and Communications Security (CCS). 2037–2052.
[15] David Fifield. 2017. Threat modeling and circumvention of Internet censorship.
[41] Refraction Networking. 2019. uTLS—fork of the Go standard TLS library, provid-
Ph.D. Dissertation. University of California, Berkeley.
ing low-level access to the ClientHello for mimicry purposes. [Link]
[16] David Fifield, Nate Hardison, Jonathan Ellithorpe, Emily Stark, Roger Dingledine,
refraction-networking/utls/.
Phil Porras, and Dan Boneh. 2012. Evading Censorship with Browser-Based
[42] Ntop . PF_RING. [Link]
Proxies. In 12th Privacy Enhancing Technologies Symposium (PETS). 239–258.
[43] Open Whisper Systems . Signal Private Messenger. [Link]
[17] David Fifield, Chang Lan, Rod Hynes, Percy Wegmann, and Vern Paxson. 2015.
[44] Psiphon . Psiphon. [Link]
Blocking-resistant communication through domain fronting. Proceedings on
[45] Refraction Routing Site [n.d.]. Refraction Networking: Internet freedom in the
Privacy Enhancing Technologies 2015, 2 (2015), 46–64.
network’s core. [Link]
[18] Pawel Foremski, David Plonka, and Arthur Berger. 2016. Entropy/ip: Uncovering
[46] Eric Rescorla. 2018. The Transport Layer Security (TLS) Protocol Version 1.3.
structure in ipv6 addresses. In Proceedings of the 2016 Internet Measurement
RFC 8446.
Conference. ACM, 167–181.
[47] Eric Rescorla, Kazuho Oku, Nick Sullivan, and Christopher A. Wood. 2018. En-
[19] Freedom House. 2018. Freedom on the Net 2018: The Rise of Digital Authoritari-
crypted Server Name Indication for TLS 1.3. Internet-Draft draft-ietf-tls-esni-02.
anism. [Link]
Internet Engineering Task Force. Work in Progress.
11_1_2018.pdf.
[48] David Robinson, Harlan Yu, and Anne An. 2013. Collateral freedom: A snapshot
[20] Sergey Frolov, Fred Douglas, Will Scott, Allison McDonald, Benjamin VanderSloot,
of chinese Internet users circumventing censorship. Open Internet Tools Project
Rod Hynes, Adam Kruger, Michalis Kallitsis, David Robinson, Nikita Borisov,
Report (2013).
J. Alex Halderman, and Eric Wustrow. 2017. An ISP-scale deployment of Tap-
[49] Max Schuchard, John Geddes, Christopher Thompson, and Nicholas Hopper.
Dance. Free and Open Communications on the Internet (FOCI) (2017), 49.
2012. Routing around decoys. In 19th ACM Conference on Computer and Commu-
[21] Sergey Frolov and Eric Wustrow. 2019. The use of TLS in Censorship Circum-
nications Security (CCS). 85–96.
vention. In 2019 Network and Distributed System Security Symposium (NDSS).
[50] Shadowsocks. 2019. Shadowsocks: A secure SOCKS5 proxy.
[22] Devashish Gosain, Anshika Agarwal, Sambuddho Chakravarty, and H. B. Acharya.
[51] Payap Sirinam, Mohsen Imani, Marc Juarez, and Matthew Wright. 2018. Deep fin-
2017. The Devil’s in The Details: Placing Decoy Routers in the Internet. In
gerprinting: Undermining website fingerprinting defenses with deep learning. In
Proceedings of the 33rd Annual Computer Security Applications Conference (ACSAC
Proceedings of the 2018 ACM SIGSAC Conference on Computer and Communications
2017). ACM, 577–589.
Security. ACM, 1928–1943.
[23] Serene Han. 2017. Snowflake. [Link]
[52] The Tor Project . obfs4 Specification. [Link]
Snowflake.
transports/[Link]/tree/doc/[Link].
[24] Jamie Hayes and George Danezis. 2016. k-fingerprinting: A robust scalable
[53] Liang Wang, Kevin P Dyer, Aditya Akella, Thomas Ristenpart, and Thomas
website fingerprinting technique. In 25th USENIX Security Symposium. 1187–
Shrimpton. 2015. Seeing through network-protocol obfuscation. In 22nd ACM
1203.
Conference on Computer and Communications Security (CCS). ACM, 57–69.
[25] Amir Houmansadr, Chad Brubaker, and Vitaly Shmatikov. 2013. The Parrot
[54] Qiyan Wang, Xun Gong, Giang T. K. Nguyen, Amir Houmansadr, and Nikita
is Dead: Observing Unobservable Network Communications. In The 34th IEEE
Borisov. 2012. CensorSpoofer: Asymmetric Communication using IP Spoofing for
Symposium on Security and Privacy.
Censorship-Resistant Web Browsing. In Computer and Communications Security.
[26] Amir Houmansadr, Giang T. K. Nguyen, Matthew Caesar, and Nikita Borisov.
ACM.
2011. Cirripede: Circumvention infrastructure using router redirection with
[55] Qiyan Wang, Zi Lin, Nikita Borisov, and Nicholas Hopper. 2013. rBridge: User
plausible deniability. In 18th ACM Conference on Computer and Communications
Reputation based Tor Bridge Distribution with Privacy Preservation. In 20th
Security (CCS). 187–200.
Annual Network and Distributed System Security Symposium, NDSS 2013. The
14
Conjure: Summoning Proxies from Unused Address Space CCS ’19, November 11–15, 2019, London, United Kingdom

Internet Society. Internet. USENIX.

[56] Tao Wang, Xiang Cai, Rishab Nithyanand, Rob Johnson, and Ian Goldberg. 2014. [59] Eric Wustrow, Colleen M. Swanson, and J. Alex Halderman. 2014. TapDance:
Effective attacks and provable defenses for website fingerprinting. In 23rd USENIX End-to-Middle Anticensorship without Flow Blocking. In 23rd USENIX Security
Security Symposium. 143–157. Symposium. 159–174.
[57] Tim Wilde. Jan. 7, 2012. Knock knock knockin’ on bridges’ doors. Tor Blog. [60] Eric Wustrow, Scott Wolchok, Ian Goldberg, and J. Alex Halderman. 2011. Telex:
[Link] Anticensorship in the Network Infrastructure. In 20th USENIX Security Sympo-
[58] Philipp Winter and Stefan Lindskog. 2012. How the Great Firewall of China is sium.
Blocking Tor. In 2nd USENIX Workshop on Free and Open Communications on the [61] ZeroMQ . ZeroMQ Distributed Messaging. [Link]

15