The Sniper Attack Anonymously Deanonymizing

8/12/2019 The Sniper Attack Anonymously Deanonymizing

1/15

The Sniper Attack: Anonymously Deanonymizingand Disabling the Tor Network

Rob Jansen

Florian Tschorsch

U.S. Naval Research Laboratory, Washington, DC

{rob.g.jansen, aaron.m.johnson}@nrl.navy.mil

Aaron Johnson

Bjorn Scheuermann

Humboldt University of Berlin, Germany

{tschorsch, scheuermann}@informatik.hu-berlin.de

AbstractTor is a distributed onion-routing network usedfor achieving anonymity and resisting censorship online. Becauseof Tors growing popularity, it is attracting increasingly largerthreats against which it was not securely designed. In this paper,we present the Sniper Attack, an extremely low cost but highlydestructive denial of service attack against Tor that an adversarymay use to anonymously disable arbitrary Tor relays. The attackutilizes valid protocol messages to boundlessly consume memoryby exploiting Tors end-to-end reliable data transport. We design

and evaluate a prototype of the attack to show its feasibility andefficiency: our experiments show that an adversary may consumea victim relays memory by as much as 2187 KiB/s while usingat most only 92 KiB/s of upstream bandwidth. We extend ourexperimental results to estimate the threat against the live Tornetwork and find that a strategic adversary could disable all ofthe top 20 exit relays in only 29 minutes, thereby reducing Torsbandwidth capacity by 35 percent. We also show how the attackenables the deanonymization of hidden services through selectivedenial of service by forcing them to choose guard nodes in controlof the adversary. Finally, we discuss defenses against the SniperAttack that provably render the attack ineffective, and suggestdefenses against deanonymization by denial-of-service attacks ingeneral that significantly mitigate the threat.

I. INTRODUCTIONLarge scale Internet censorship by state-level authori-

ties [44] has spurred the development of new privacy en-hancing technologies that circumvent the censor, followed bynew techniques to recognize and block these circumventiontools [22]. As this censorship arms race proceeds, more re-silient circumvention technologies will be developed in orderto increase the cost of detection using traditional methods. Weargue that as these circumvention technologies improve and thecost of detection increases, alternative techniques for disrup-tion will become increasingly viable. As such, understandingthese alternatives is paramount not only to the successfuldesign of future technologies, but also to the security ofexisting networks and systems.

Tor [19] is the most popular deployed system for fight-ing censorship and online privacy encroachments, currentlysupporting several hundreds of thousands of users daily and

transferring roughly 3 GiB/s in aggregate [8]. Tor uses onionrouting [25] to route clients traffic through a circuit ofgeographically diverserelays, preventing any single relay fromlinking the client to its Internet destination. This work focuseson Tor due to its practical relevance as an adversarial target.

In this paper, we present, analyze, and evaluate a novel anddestructive denial of service (DoS) attack against Tor that maybe used to anonymously and selectively disable arbitrary Torrelays with very low cost to the attacker: our attack is efficientto the extent that an adversary interested in censorship coulddisable instead of block Tor by simply disabling all relaysor intelligently targeting crucial subsets of relays, e.g., thoseproviding high network throughput or authoritative directoryservices. The attack may be undetectably carried out on anymachine with moderate computational and memory resourcesand presents severe security implications for Tor and its users.In addition to threatening network availability, we show howthe attack can be used to deanonymize hidden services byselectively disabling relays, heavily influencing paths to thosein control of the adversary. Our attack thus imposes real,significant threats to Tors users,1 and we believe it constitutesthe most devastating attack against the Tor network to date.

The attack, which we call the Sniper Attack since theattacker remains hidden while disabling relays in a targetedmanner, works by utilizing Tors application level congestionand flow control mechanisms to cause a Tor relay to buffer anarbitrary amount of data in application queues. In particular, anadversarial client builds a normal Tor circuit using the targetrelay as the entry, commands the exit to start downloadinga large file through the circuit, and then continuously sendsSENDMEcells to the exitwithout reading from the target entry.The SENDME cells signal the exit to increase its congestionwindows, after which it will continue to pull data from theexternal data source and push it into the circuit. This processmay be repeated in parallel on many circuits using the sametarget entry for each. The remote Tor process on the target

relay will queue the data and eventually exhaust its hostsmemory, resulting in termination by its operating systemsmemory manager (e.g. the oom-killer on Linux [1]).

Using Shadow [28], we demonstrate the destructivenessof the Sniper Attack and the effectiveness of our defensesby evaluating them in a safe, private, simulated Tor net-work. The evaluation of our attack prototype indicates thatan adversary may consume a target relays memory by as

1We disclosed our attack to The Tor Project [6] in February 2013. Wehave worked with them to develop and deploy a short term defense [17], andcontinue to work with them in developing long term solutions[32]. As a result,Tor is no longer vulnerable since version 0.2.4.14-alpha.

Permission to freely reproduce all or part of this paper for noncommercialpurposes is granted provided that copies bear this notice and the full citationon the first page. Reproduction for commercial purposes is strictly prohibitedwithout the prior written consent of the Internet Society, the first-named author(for reproduction of an entire paper only), and the authors employer if thepaper was prepared within the scope of employment.NDSS 14, 23-26 February 2014, San Diego, CA, USACopyright 2014 Internet Society, ISBN 1-891562-35-5http://dx.doi.org/doi-info-to-be-provided-later


2/15

much as 2187 KiB/s (903 KiB/s in the median), while theadversarial bandwidth costs are at most 92 KiB/s upstreamand 39 KiB/s downstream, (46 KiB/s upstream and 14 KiB/sdownstream in the medians). Using these results, we estimatethat sequentially disabling each of the fastest 20 exit relaystakes a cumulative total of only 29 minutes. In addition, weexplore using Tor to anonymously disable relays by utilizinga separate anonymous tunnel through which we launch our

attacks, and find that doing so does not increase the adversarialbandwidth requirements.We analyze the security threat that the Sniper Attack

poses and present novel techniques for deanonymizing hiddenservices. We utilize the Sniper Attacks ability to kill arbitraryrelays in a selective denial of service attack against the guardrelays of hidden services, influencing the paths chosen by thehidden services to those in control of the adversary. We findthat it enables the complete deanonymization of hidden ser-vices within days by an adversary with only modest resourcesor within hours by a more powerful adversary.

This paper also explores defense strategies against theSniper Attack. We discuss how simple hard-coded queuesize limits and end-to-end authenticated signals affect the

adversarys attack strategy, but do not completely prevent theattack. We then present an algorithm that adaptively reacts tohigh memory pressure indicative of the attack. Our adaptivedefense utilizes queuing delay as a metric to identify and killmalicious circuits in order to prevent the process from beingkilled. We derive resource bounds with our defense mechanismin place, showing that it cannot reasonably be leveraged byattackers to cause relays to destroy honest clients circuits.Our evaluation shows that our adaptive circuit killing defensedetects and stops the Sniper Attack with no false positives.

Finally, we present and analyze path restrictions that miti-giate the threat of DoS deanonymization. By restricting therelays it uses for sensitive circuit positions, a client will failclosedto an unavailable but safe state instead of an avaliable

but potentially compromised one. We analyze the security andavailability cost of such changes under a variety of parametersand find acceptable security/availability trade-offs.

Our main contributions may be summarized as follows:

a dangerous and destructive DoS attack capable ofdisabling arbitrary Tor relays (SectionII);

an evaluation of a prototype of the attack and ourdefenses in a safe, virtual Tor network (Section III);

a security analysis showing how the attack may beused to deanonymize hidden services (Section IV);

practical defenses against the Sniper Attack that re-duce Tors vulnerability to attacks that exploit Torsqueuing mechanisms (SectionV); and

practical defenses against DoS-based deanonymization

attacks that improve security by limiting networkexposure (SectionVI).

II. THE S NIPERATTACKIn this section, we develop a DoS attack against the Tor

network that can be used to anonymously disable arbitraryTor relays by killing the Tor process on its host machine. Tofacilitate an understanding of the exploited protocol features,we first describe two basic attack variants that require theadversary to run both a Tor client and either a Tor exit relay oran Internet service. We then describe a more efficient variantthat only requires a Tor client and therefore significantly

reduces the resources required by the adversary. Finally, wediscuss strategies that disguise the adversarys identity.

A. BackgroundTor is an application-level overlay network enabling anony-

mous communication between clients and arbitrary Internetdestinations. Tor clients are responsible for path selectionat the overlay layer, and form virtual circuits through theoverlay network by selecting three relays from a public listfor each: an entry; a middle; and an exit. Once a circuit isestablished, the client creates streams through the circuit byinstructing the exit to connect to the desired external Internetdestinations. Each pair of relays communicate over a singleonion routing connection that is built using the TransmissionControl Protocol (TCP). The application layer protocols relyon this underlying TCP connection to guarantee reliability andin-order delivery of application data, called cells, between eachrelay. As a result of using hop-by-hop TCP at the networklayer, Tor does not allow relays to drop or re-order cells at theapplication layer. Streams are multiplexed over circuits, whichthemselves are multiplexed over connections.

Tor implements an end-to-end sliding window mechanism

to control the amount of data directed into the network. Forevery circuit, each edge node (i.e. client and exit) managesa package window counter that is initialized to 1000 anddecremented by one for every data cell it directs into thecircuit, and a delivery window counter that is initialized to100 and decremented by one for every data cell it removesfrom the circuit. Analogous counters also exist at the streamlevel, respectively initialized to 500 and 50. The packagingedge (PE) of a circuit will stop injecting cells from anymultiplexed stream whose package window reaches zero, andwill stop injecting cells from all multiplexed streams whenthe circuit packaging window reaches zero. The delivery edge(DE) of a circuit will send a feedback signal, called a SENDMEcell, to the PE whenever the circuit delivery window or any

stream delivery window reaches zero. These SENDME cellscause the DE to increment the associated delivery window byits initialized value, and the PE to increment its packagingwindow by the same amount.2 Thus, there will not be morethan 500 data cells in flight on a stream, and not more than1000 on a circuit.

B. Basic AttacksThe Sniper Attack exploits Tors reliable application-level

queuing. Our assertion is that a DE that stops reading froma connection will cause the next hop node to buffer a fullpackage window worth of data (1000 cells) from the PE forevery active circuit multiplexed over the connection, under theassumptions that there are at least two streams multiplexedon each circuit and that the streams transfer enough data inaggregate to reduce the PEs circuit package window to zero.When a DE with incoming data stops reading from its TCPsocket on the connection to an adjacent relay, the DEs TCPreceive buffer will fill, its TCP flow control window will empty,and it will announce a zero window to the other end of theTCP connection. The adjacent relay will then no longer beable to forward cells to the DE, causing its TCP send buffer

2In practice, circuit and stream delivery windows are respectively initializedto 1000 and 500. When they reach 900 and 450, SENDMEs are sent and theyare incremented by 100 and 50. Therefore, the delivery windows will not fallbelow 900 and 450 under normal operation.

2


3/15

Fig. 1: In the basic version 1 of the Sniper Attack, the adversary controlsthe client and the exit. (a) The client creates a circuit using the target as theentry. (b) The exit generates, packages, and sends data through the circuit,ignoring package window limits. (c) The client stops reading from the TCPconnection to the target entry. (d) The target entry buffers the data until theTor process is terminated by the OS.

to fill. With a full TCP send buffer, the adjacent relay willbuffer cells in the application layer circuit queue (recall thatTor does not allow relays to drop cells in the application layer)until the PEs stream or circuit package window reaches zero.The PE will then stop sending data into the circuit, and stopreading from the data source.

Using the mechanism described above, an adversary thatcontrols a client and a relay may attack a target relay asshown in Figure 1. The adversarial client constructs a circuitby selecting the target relay as the entry and the adversarialrelay as the exit.3 The client signals the exit to start theattack by issuing an arbitrary request over the custom attackcircuit, and then stops reading from the TCP connection tothe target entry. The exit simply ignores the empty packagewindows and continuously sends data it arbitrarily generates,increasing the amount of memory consumed by the entry toqueue the cells. Note that it is not necessary for the maliciousexit to produce correctly encrypted Tor cells since they willnever be fully decrypted by the client (though correct circuitIDs are required). Eventually, the Tor process on the entrynode depletes all of the available memory resources and isterminated by the operating system. On Linux systems, this

job is handled by the out-of-memory (oom) killer [1].A variation of the basic attack described above is shown in

Figure2.In this variant, the adversary controls a client and afile server. The client generates arbitrary data and packages itfor delivery to the target exit. The adversarial server avoidsreading from the TCP connection to the target exit, againresulting in memory exhaustion and death of the Tor processon the target relays host machine. Note that the cells must beencrypted in this attack variant because they will be decryptedby a machine which is not under the adversarys control.

Note that the adversary may choose any relay as its targetentry in version 1 of the basic attack, and should choose the fileservers port according to the exit relays exit policy in version2. However, choosing relays without the Guard flag for a

circuits entry position will raise suspicion since Tors defaultpath selection algorithm will not choose entries in that manner.Alternatively, basic versions 1 and 2 may be slightly modifiedto target any middle node: in version 1 the adversary mayadditionally run an adversarial entry relay that stops readingfrom the connection to a target middle relay; in version 2 theadversary may run an adversarial exit that stops reading fromthe connection to a target middle relay instead of running anexternal file server.

3The Tor software provides parameters, EntryNodes and ExitNodes,to specify a list of nodes for the respective roles; one could also use the Torcontrol protocol[4] to build custom circuits.

Fig. 2: In the basic version 2 of the Sniper Attack, the adversary controlsthe client and the server.(a) The client creates a circuit using the target as theexit, and connects to a colluding server. (b) The client generates, packages,and sends data through the circuit, ignoring package window limits. (c) Theserver stops reading from the TCP connection to the target exit. (d) The targetexit buffers the data until the Tor process is terminated by the OS.

We assert that the TCP connection from the client tothe target must remain open from the victims perspective toprevent the attack circuit from being closed and its queuecleared, but the cost of doing so is insignificant (and it canbe done without maintaining state [26]). Also, the adversarymay slightly reduce the required bandwidth by minimizing thesize of its TCP receive buffer, e.g., by using setsockopt.

C. Efficient AttackWe now describe an efficient Sniper Attack that eliminatesthe necessity of generating and uploading data, thereby signifi-cantly reducing resource demands. This efficient version of theSniper Attack exploits Tors end-to-end flow control signals.Our assertion is that the SENDMEflow signals expected by thePE (so that it may continue packaging data and sending it intothe circuit) only implythat a DE received data and a DE maysend SENDMEs to the PE without actually receiving any data.

The efficient sniper attack works by combining theSENDME signal mechanism described above with the stopreading mechanism from the basic versions of the attack. Asshown in Figure 3, the adversary must only control a singlemalicious client. This client first builds a custom circuit by

selecting the target as the circuit entry, and then initiates thedownload of two large files (e.g., large Linux distributions)over the circuit to ensure that the two streams will empty theexits circuit package window. The client then stops readingfrom the connection to the target entry, and begins maliciouslysending SENDMEs to the exit to ensure that the exits packagewindow does not reach zero and it continues injecting pack-aged data into the circuit. These packaged cells will continueto flow to and be buffered by the entry in its application queue,continuously consuming memory until the entrys Tor processis selected and killed by the OS.

1) Avoiding Detection: To launch a successful Sniper At-tack, the adversary must circumvent a protective mechanismthat Tor employs to prevent protocol violations, e.g., by clients

who try to cheat by sending more SENDME cells to get moredata earlier. When the exit relay receives a SENDME thatcauses its circuit window to go above 1000 cells, it detectsthe violation, closes the circuit, and sends a DESTROY cellbackwards. The middle hop converts the link-level DESTROYcell into a RELAY cell of type truncate and sends it to theentry, who just passes it back to the client. When the clientextracts the DESTROY cell (that originated at the exit) fromthe RELAYcell, it closes the circuit and sends a DESTROYcellforward to the entry. The entry closes the circuit (clearing thecircuit queue) and forwards the DESTROY cell to the middle,who also closes the circuit.

3


4/15


5/15

a) Stealth with Tor: Tor itself is a useful tool to providesuch protections. One way the adversary could use Tor is byalso running a Tor exit node:

EACA GV M E S

This situation provides the adversary plausible deniability:GVwill not be able to distinguish an attack by CA from onelaunched through a circuit in which EA is merely serving as

the exit.4 However, drawbacks to this approach are that EAwill need to serve as an honest exit, which consumes far moreresources than required by the attack and also results in theadversary appearing in the public Tor directory. The adversarythen has to ensure that EA has the characteristics of otherhonest exits (has the right consensus flags for its activities,has the right amount of traffic for its consensus weight, etc).Further,GVwill still know the IP address and may use it as astarting point when looking for someone to blame.

Alternatively, the adversary may use a full Tor circuit:

C2AC1

A G1 M1 E1 G2V M

2 E2 S

This provides the adversary anonymity. It will prevent As IP

address from being known by anyone except G1

, who will beoblivious to the attack. In this scenario, C1A stops reading onthe connection to G1 but C2A sends SENDMEs to E

2 throughthe C1A proxy tunnel. A drawback to using a separate circuitin this way is that it may slightly increase the latency andlength of the attack, because G2V will not start depleting itsmemory resources until E1s package window reaches zero. Itmay also be more difficult to estimate a good SENDME ratewhen concatenating two circuits, and the adversary must nowrun twice as many Tor client instances to ensure that each teamhas two anonymous tunnels. Finally, a circuit that exits backinto Tor may draw unwanted suspicion.

b) Stealth without Tor: Alternatives to using Tor tohide include using public open wireless access points, briefly

renting a small botnet, or using a cloud computing system.However, more entities will then know about the adversarysactions, increasing the risk of discovery: access points andcloud services will be collecting logs; and some number ofbots could be part of a honeypot. The adversary may wantto connect to these services through Tor anyway to remainanonymous to them, and the composition of services will makeit easier to make a mistake. By using Tor as described above,the adversary does not need knowledge of botnets or cloudsystems, drastically simplifying the attack.

III. EVALUATIONWe implemented a prototype of the Sniper Attack in order

to evaluate its feasibility and efficacy. We evaluated it using

Shadow [28], a discrete event network simulator that runs Torcode in a private Tor network, after testing its functionalityin a minimal private Tor network in our lab. Shadow enablesa safe development and evaluation environment that does notharm the security and privacy of the operational Tor networkor its users, while also providing realisticresults since it runsauthentic Tor code. In this section, we detail our private Tornetwork configuration, describe our prototype implementation,

4GV can distinguish CREATE cells from EXTEND cells, but it is plausiblethat a CREATEcell originated from some client in a separate circuit terminat-ing atEArather than fromCA, e.g., if that client is using Tors Socks4Proxyor Socks5Proxy options.

evaluate the attacks efficiency and resource costs, and analyzeour results in the context of the live Tor network.

A. Private Tor NetworkTor nodes running in Shadow communicate over a simu-

lated network. Therefore, Shadow requires models of down-stream and upstream node bandwidths as well as link latency,

jitter, and packet loss rates. The Shadow distribution [3] in-cludes these models, and also includes tools to generate privateTor network configurations for running Shadow simulations.Using these tools and real network data published by Tor5 [8],we configure a private Tor network consisting of 4 directoryauthorities, 400 relays, 500 file servers, and 2800 clients. Thisprivate network consumes roughly 60 GiB of memory onour Linux host during each experiment. The clients generatebackground traffic during the experiments by downloadingvariously sized files from the servers through our private Tor,causing congestion and performance characteristics indicativeof conditions in the live Tor network. All of these nodesrun in the Shadow simulator and communicate only with oneanother. Our configuration follows the methodologies fromrecently published and validated research on modeling privateTor networks [27], which describes in detail the modelingchoices made by Shadows configuration generation tool.

B. The Sniper Attack PrototypeWe implemented the parallel version of the efficient Sniper

Attack as described in SectionII-C, including multiple parallelcircuits but without the rotating circuits enhancement. In ourC prototype implementation, a manager manages all workers,each of which use the Tor control protocol[4] to command andcontrol the associated Tor client instance and its circuits. Theworkers run a modified Tor client instance, based on stablerelease 0.2.3.25, that adds: a STOPREADING controllercommand which instructs Tor to stop reading from the onionrouting connection to the target; SENDSTREAMSENDME andSENDCIRCUITSENDME commands which instructs Tor to

send a stream-level and circuit-level SENDMEs on the spec-ified streams and circuits; and an IGNOREPACKAGEWINDOWcommand that instructs the client to ignore package windowswhen sending data upstream.

We implemented both directand anonymousSniper Attackmodes. In direct mode, each worker connects to the Torclient over the controller port, waits for it to become fullybootstrapped into the Tor network, and builds its customTor circuits using the same path as the other workers onits team. Once the attack circuits are ready, the probingworkers begin circuit measurement probes by downloadingfiles through their attack circuit; the remaining workers requestan extremely large file through the attack circuit, commandTor to stop reading, and send two stream SENDMEs and

one circuit SENDME for every completed probe download.In anonymous mode (see Section II-C3a), each worker runstwo Tor client instances instead of one: the first is used tocreate an anonymous tunnel through Tor; the second is usedas in direct mode, except that all communication with relays isdone over the anonymous tunnel using the Socks4ProxyTorconfiguration option. Note that the client instances that createthe anonymous tunnels ignore their package windows usingthe IGNOREPACKAGEWINDOW command, because otherwise

5We use the server descriptors and extra info documents from 2013-06, andthe Tor consensus from 2013-06-30-23-00-00

5


6/15

TABLE I: Sniper Resource Usage

Max RAM (MiB) and Mean BW (KiB/s)

Direct AnonymousRAM Tx Rx RAM Tx Rx

Config. 1 0 Teams, 100 Circs 283 56.0 20.9 564 56.6 17.0

5 Teams, 50 Circs 141 30.0 9.5 283 27.7 8.51 Teams, 10 Circs 28 6.1 2.6 57 9.4 2.1

1 Team, 5 Circs 28 4.0 2.3 56 3.6 1.8

the SENDMEs that are being forwarded from the attack circuitsupstream through the tunnel will evetually drain the windowsand stall the attack (the tunnels normal downstream SENDMEswhich increment the package window will not be receivedbecause of the stop reading attack behavior). The snipermanager and worker logic was packaged as a Shadow plug-inconsisting of 1416 lines of code, while our Tor modificationsincluded 253 lines of code.

C. Experiments and ResultsWe experiment with our prototype implementation of the

Sniper Attack to explore the target memory consumption andsniper resource tradeoffs when conducting the attack against

target relays of various capacities. Our Tor network modelis configured as described above, with the addition of anadversarial sniper node that runs the Tor clients and the snipermanager that controls the attack. Unless otherwise specified,our experiments use 100 circuits configured as 10 teams of 10circuits each, while each probing circuit downloads =50KiBfiles, pausing for 60 seconds between each probe. Every teamuses a unique Tor path for their circuits chosen following Torsweighted path selection algorithm. Our sniper is configuredwith a 100 MiB/s symmetric bandwidth access link so as notto result in a bandwidth bottleneck during the experiment formeasurement purposes. Each experiment runs for 60 virtualminutes, during the first 30 of which we allow the networkto bootstrap and during the last 30 of which the attack is

executed. We run one attack against a single target relay ineach experiment, and measure the RAM used over time bythe target and the sniper as well as the bandwidth consumedby the sniper.

We tested the feasibility of the Sniper Attack, arbitrar-ily choosing the highest weighted non-authoritative, non-exitguard node in our network as the target. This node had a 9MiB/s symmetric bandwidth access link and otherwise servedas an ordinary relay in our experiment. We tested the SniperAttack with each of 100, 50, 10, and 5 attack circuits. As canbe seen in Figure 4a, the number of circuits directly affectsthe rate at which the sniper is able to consume the targetsmemory. While the targets memory consumed in each scenarioincreases approximately linearly, there is a dramatic difference

between 10 and 50 circuits: the 10 circuit experiment wasconfigured with 1 team, meaning that all 10 circuits areconfigured with the same path through Tor; the 50 circuitexperiment was configured with 5 teams, meaning that thereare 5 paths chosen through Tor. Choosing multiple paths inthis way more effectively utilizes Tors capacity and preventsthe attack from stalling due to a poorly chosen circuit that maycontain a tight bottleneck.

The memory and bandwidth requirements for the sniperin our feasibility experiments can be seen in Table I. Shownare the maximum total memory (RAM, in MiB) used by thesniper at any point during the attacks and the mean total

bandwidth (BW, in KiB/s) consumption, for both thedirectandanonymousexperiments. The RAM used by the sniper dependsalmost entirely on the number of Tor instances being used: inall cases, the mean RAM used per Tor client instance wasapproximately 14 MiB. As expected, the anonymous attackconsumes roughly twice as much memory as the directattacksince it is using twice as many Tor client instances. Theresource requirements for our prototype are quite reasonable:

the maximum memory required in any of our experimentswas less than 600 MiB and the maximum upstream anddownstream bandwidth required was 56.6 and 20.9 KiB/s,respectively. Further, the snipers 60 second bandwidth burstremained below 500 KiB/s throughout the experiment. Weexpect an adversary willing to launch this type of attack caneasily satisfy these requirements. Note that probing less oftenmay further reduce the bandwidth costs.

Our feasibility experiments tested the Sniper Attack againstan arbitrarily chosen relay. We expanded this evaluation todetermine how the Sniper Attack performs against a variety ofrelays with unique congestion, load, and bandwidth capacities.To do this, we chose a set of 50 relays from our privatenetwork, again using Tors weighted path selection algorithm.

Using the default settings outlined above, we ran our prototypeSniper Attack against each relay twice: once in direct modeand once in anonymous mode. We measured the memoryconsumed by the target and the bandwidth consumed by thesniper during each experiment.

We computed the mean target memory consumption rateand mean sniper bandwidth consumption rate achieved duringeach experiment (recall that each experiment targets a differentrelay). Figures 4b and 4c show the cumulative distributionof these rates for each mode over the 50 experiments; eachexperiment produces one data point in each of the two figures.As shown in Figure 4b, the median computed mean targetRAM consumption rate was 903.3 KiB/s in the direct attackand 849.9 KiB/s in the anonymous attack. Further, the direct

mode of the attack was only slightly more effective in ourexperiments: in the maximum the sniper was able to consumethe targets RAM at 2186.8 KiB/s, roughly 1.4 times as fast asthe maximum of 1541.8 KiB/s in anonymous mode. Althoughthis difference is only seen in the tail of the CDF, the reasonis likely due to the additional length of the attack circuitpath in anonymous mode (the cells must traverse 6 Tor relaysin this case), which may lead to less accurate probing andextra latency when sending the SENDME cells through theanonymous Tor tunnel to the the opposite edge of the attackcircuit. Further, the longer path increases the chance that abottleneck exists on the path which may cause some of theattack circuits to fail. Figure 4c shows that the bandwidthrequirements in both modes are similar: the mean upstream

bandwidth measured was 45.9 and 43.0 KiB/s in the median forthe directand anonymousattacks, while the mean downstreambandwidth was respectively 13.6 and 17.6 KiB/s in the median.Our experiments show that the Sniper Attack enables theadversary to relatively easily trade its bandwidth resources fora victim relays memory resources.

D. AnalysisWe now analyze the practical effect the Sniper Attack has

on the operational Tor network by considering how realisticadversaries might choose to disable relays. The adversarymay prioritize as targets the relays with low RAM but high

6


7/15

(a) Target Memory over Time (b) Target Memory Consumption (c) Sniper Bandwidth Consumption

Fig. 4: The Sniper Attack resource consumption. Shown in (a) is the target relays memory usage over time in direct andanonymousattack modes. Compared are attacks with 1 team of 5 and 10 circuits, 5 teams of 10 circuits each (50 circuits total),10 teams of 10 circuits each (100 circuits total), and no attack. The shaded area indicates the time during which the attack isactive. Shown in (b) and (c) are the distributions of the mean consumption rate of the target relays RAM per experiment andmean snipers bandwidth cost per experiment, respectively, over 50 experiments each of direct and anonymous Sniper Attacks.The sniper in each experiment is configured to use 10 teams of 10 circuits each (100 circuits total).

consensus weights: this will have the largest impact on users

since Tors load balancing algorithm is tuned so that theprobability that a client chooses a relay is in proportion tothe bandwidth capacity that relay contributes to the network.However, since relay memory resources are not public, we con-sider an adversary that chooses relays based on the consensusweight alone and explore the time to disable them accordingto various potential memory configurations. Because of theload balancing algorithm and the fact that currently the relayswith the top 100 weights constitute 40 percent of the selectionprobability, the adversary may have significant impact on thenetwork by disabling a relatively small group of relays.

We utilize the results from our 100 experiments discussedabove to estimate memory consumption rates that an adversarymay achieve on live Tor network relays. To do this, we

compute the correlation between the observed mean memoryconsumption rate of each target relay in our experiments andthat relays consensus weight using a linear regression. Thisresults in parameters that we use to estimate the memoryconsumption rate of any relay for which we have a consensusweight. Negative rate estimates were replaced with the mini-mum observed rate. We then use these rates to compute thetime to disable various groups of relays: we consider the top,median, and bottom guard and exit relay by the probability ofselection by clients out of those with the FAST flag, as relayswithout theFASTflag are only selected if no FASTrelays areavailable. We also consider the top 5 and 20 of both guardsand exits as those relays will be selected most often by clientsand represent the most attractive targets for the adversary. We

consider the 10 directory authorities as the final group, as thenetwork will not function over time without the authoritativedocuments they collectively produce and distribute.

Shown in TableII is the total selection probability for eachrelay group, and the estimated total length of time to disable allrelays in the group when the Sniper Attack is synchronouslylaunched on a single relay at a time. We consider memoryconsumption rates for bothdirectand anonymous attacks, andconsider the length of time to disable relays with 1 and 8 GiBof RAM as examples of relay memory capacities. Note thatthese results scale linearly to other RAM sizes. Also note that

TABLE II: Combined Path Selection Probability of and Ex-pected Time to Disable Selected Groups of Relays

Time (H:M) to Consume RAM

Direct AnonymousSel % 1 GiB 8 GiB 1 GiB 8 GiB

RelayGroups

TopFAST Guard 1.7 0:01 0:18 0:02 0:14Median FAST Guard 0.025 0:23 3:07 0:23 3:07Bottom FAST Guard 1.9e-4 1:45 14:03 1:45 13:58

TopFAST Exit 3.2 0:01 0:08 0:01 0:12Median FAST Exit 0.01 1:45 14:03 1:22 10:53Bottom FAST Exit 6e-5 1:45 14:03 1:48 14:20

Top 5 Guards 6.5 0:08 1:03 0:12 1:37Top 20 Guards 19 0:45 5:58 1:07 8:56

Top 5 Exits 13 0:05 0:37 0:07 0:57Top 20 Exits 35 0:29 3:50 0:44 5:52

All Dir Auths N/A 17:34 140:32 17:44 141:49

although the linear regression did not result in a strong cor-relation (direct: r 2=0.164, anonymous: r2=0.237), we believeit provides a reasonable prediction of RAM consumption foranalysis purposes as we expect the actual time to disable thegroups of relays given in TableIIto fall somewhere the timesgiven in the 1 GiB and 8 GiB columns.

Our analysis shows that the fastest guard and fastest exitwith 1 GiB of RAM can be disabled in just one minutewhen using the direct attack, thereby disabling an expected1.7 and 3.5 percent of paths in the Tor network, respectively.When allotting 8 GiB of RAM for these relays, they can bedisabled in under 20 minutes in both attack modes. Perhapsmore strikingly, the entire group of the fastest 20 exits canbe disabled in just 29 minutes if each relay has only 1 GiB

of RAM, and in just under 4 hours if each relay has 8GiB of RAM. (The anonymous attack takes slightly longerin both cases.) This would be extremely disruptful to theTor network, causing roughly 35 percent of all paths to failand increasing load and congestion on the remaining relays.Similarly, the group of the fastest 20 guards can be disabledin just 45 minutes if allotting 1 GiB of RAM for each relay,and just under 6 hours if allotting 8 GiB of RAM for each(again, theanonymousattack takes slightly longer). This wouldcause 19 percent of Tor paths to fail. Finally, the attacktakes significantly longer on the group of directory authorities,since their lower bandwidth weights result in lower RAM

7


8/15

consumption rates than the fastest relay groups. Note thatrelays will likely be rebooted by their operators some timeafter going down, however, all circuits they were carrying willbe lost and the attack could be relaunched against a relay assoon it is available. This may effectively cause a relay to bemarked as unstable and not chosen by clients for their circuits.

IV. DEANONYMIZATION INTORThe Sniper Attack is more than just a threat to Tors avail-

ability: it can also be used as an attack on anonymity. BecauseTor accepts any willing relay into the network, an adversarythat runs relays can deanonymize a victim by controlling theentry and exit relays and correlating the observed timing andvolume of a users traffic entering the network with that leavingthe network shortly afterwards [11], [42].

To prevent an adversary running relays from eventuallybeing chosen for these positions, a user chooses a small setof entry guards (Tor defaults to 3 guards), and begins allcircuits at one of these guards. This protects the user frombeing directly observed as long as adversarial relays are notchosen as guards. A guard is used for 3060 days, at whichpoint a replacement is selected [21].

Thus a users guards are an attractive target for the Sniper

Attack. If few enough of a users guards are responsive (at most1 in Tor), the user will select new guards as replacements. Bydisabling the users guards, the adversary can cause the userto choose new guards and hope that an adversarial relay isamong them. This process can be repeated until the adversarysucceeds.

This attack requires the adversary to identify the targetsguards and to force her to choose new ones as soon as theold ones are disabled. Doing so is particularly easy withhidden services [34] because they create circuits on demand.Therefore, we will describe and analyze the attack applied tohidden services.

Deanonymizing Tor clients using the Sniper Attack is lessstraightforward because they generally do not respond ondemand. However, in some significant cases guards could beidentified and guard reselection initiated. For example, a userdownloading a large file could give the adversary enough timeto discover the guard using a congestion side channel [23],[24], [33]. Furthermore, download managers and BitTorrentclients generally automatically restart an interrupted download,which would prompt guard reselection by Tor.

Finally, we note that in addition to deanonymization, theadversary could use the Sniper Attack to attack Tor privacyin other ways. For example, he could attack the exits of long-lived circuits, such as IRC connections, in order to be chosenas the replacement exit and discover the destination. He couldalso attack exit relays that allow connections to certain portsin order for adversarial relays to observe a larger fraction ofexit traffic to such ports.

A. Deanonymizing Hidden ServicesHidden services provide responder anonymityfor a persis-

tent service. Users are able to connect to the service throughTor without knowing its location. Let H be a hidden serviceand C be a client. H chooses a set I of Tor relays asintroduction pointsand creates persistant circuits to them. Theprotocol for using a hidden service is (1) C chooses a Torrelay R to serve as a rendezvous pointand creates a circuit toit; (2) C chooses an introduction point I, creates a Tor circuitto it, and sends R to H through I; (3) H creates a circuit to

R; and (4) C and H communicate to each other over theirrespective circuits to R .

To perform the anonymity attack on a targeted hiddenservice, the adversary will need to control at least one relaythat can serve as a guard, and he will need to control anotherrelay that can serve as a rendezvous point. For an adversarysrelay to be used as a guard, it must satisfy minimum uptimeand bandwidth requirements (roughly, its uptime must be at

least that of the median relay, and its bandwidth must be atleast the minimum of the median bandwidth and 250 KB/s[7]).Any relay in the Tor network can serve as a rendezvous point.

The deanonymization attack proceeds in three phases:

1) Identify the guards of the hidden service;2) Disable the guards with the Sniper Attack; and3) Test if the hidden service selected an adversarial relay

as a replacement guard, and repeat from 1) if not.

To describe these phases in detail, let GA be the adversarialrelay that can be used as a guard, RA be the adversarial relayintended to be used as a rendezvous point, CAbe an adversarialTor client, and Hbe the target hidden service.

Phase 1 (Identify Guards): A user can force H to select

a new circuit by requesting a new connection through arendezvous point. H chooses the circuits relays other thanthe guard roughly at random weighted by bandwidth. Thus, byrequesting enough connections, the adversary will eventuallycause H to choose circuits such that, for every guard ofH,in some of those circuits the adversarial relay GA is the hopafter that guard. For these circuits, the adversary can directlyobserve the guards identities, although he may not realize it.

Biryukov et al. describe an efficient technique for theadversary to recognize when he is in such a situation [12]. Therendezvous point RA sends a pattern of 50 PADDING cells toHdown the rendezvous circuit followed by a DESTROY cell.If GA observes a pattern of 2 cells on a rendezvous circuitfrom a hidden service and 52 cells on the same circuit to

the hidden service (the cells in excess of 50 are from circuitconstruction), followed by a DESTROY cell shortly after oneis sent byRA, it concludes that the relay one hop closer to Hon the circuit is a guard ofH. During experiments on the liveTor network, Biryukov et al. observed no false identificationsusing this method. They also note that the attack could beperformed without an adversarial rendezvous point, althoughit would slow the attack because the rendezvous circuit mustextend to CA.

Using this method, the adversary can quickly, efficiently,and perfectly identify all guards ofH. Moreover, the discoveryprocess looks fairly innocuous to H, which only sees a seriesof normal rendezvous requests. Of course, all such requestsare to the same rendezvous point, the connections may appear

abnormally fast, and no data is ever carried on the circuits. Ifstealthiness is a goal, the attack could be mounted from CAwith normal rendezvous point selection, at a slower rate, andincluding some typical data requests as cover. This would comeat the cost of some speed and efficiency. Note also that verlierand Syverson [34] describe a less-efficient method of guardidentification that depends on performing traffic correlationthat is less precise but is more robust to countermeasures.

Phase 2 (Disable Guards): Once Hs guards have beenidentified, the adversary can use the Sniper Attack to causethe Tor process of each guard to be killed. The attack canbe run against all guards in parallel to reduce the time of the

8


9/15

attack to the time to kill just one guard. Moreover, attackingthe guards at the same time increases the length of time thatthe guards remain simultaneously unavailable. Eventually, wewould expect the relay operator to notice that the Tor processwas killed and restart it.

Phase 3 (Test for Guard Selection): Once the hiddenservices guards are disabled, the adversary can easily causenew ones to be selected simply by connecting normally to the

service. Then he can determine if his guard GA was selectedby H using techniques very similar to those used to identifyguards in Phase 1. A difference is that he would look on thecircuits ofGAfor those with 3 cells from the circuit origin and53 cells towards it before destruction. This step requires onlyenough circuits that any given guard ofH is sufficiently likelyto be used for at least one (e.g.with 35 circuits, the probabilityof such a selection failing to occur is at most (2/3)35 106).

B. EvaluationThe DoS Deanonymization Attack executes a number of

three-phase rounds until it succeeds. To estimate the time tocomplete round i of the attack on hidden service H, let ti

1 be

the time to identify the guards ofH(Phase 1), ti2

be the time

to disable the guards of H (Phase 2), and ti

3 be the time totest ifHselected a malicious relay as a guard (Phase 3). Let rbe the number of rounds needed for the attack. Then the totalattack time t can be expressed as t=

ri=1t

i1

+ti2

+ti3

. Weestimate t for the actual Tor network and various sizes of theadversary, and use real Tor network data from Tor Metrics [8].

1) Time for Phase 1 (ti1

): To identify the guards of H,the adversary runs a malicious relay MA and creates enoughconnections to H such that, for each guard G, a resultingcircuit fromHto the rendezvous point uses MA as the middlerelay andG as the guard. The connections to Hcan be createdin parallel to speed up this phase. Let tc be the time frominitiating a connection toH untilMA observes the cell patternthat indicates its presence on a rendezvous circuit ofH. Let

ci

be the number of connections that are needed for MA toobserve all guards ofH. Let be the number of connectionscreated in parallel. The time for this phase is then ti

1= tcci/.

To estimatetc andci, we ran a hidden service experiment

in Shadow. During the experiment, a client repeatedly creatednew connections to a hidden service and sent the 50-cell trafficsignature used to recognize relays on the resulting circuit. Notethat we used the version of the attack in which the clientsends these cells rather than the rendezvous point. We recordedthe paths of these circuits and the time from initiation of theconnection until the service received the traffic signature. Ourexperiments were performed in two sessions, each with 10client-server pairs run in parallel and with background traffic.

During these experiments, 8319 connections to hidden

services were created. The average time between starting aconnection at the client and receiving the inserted cell patternat the server was 10.69s. The minimum time was 1.45s and themaximum time was 319.87s. Thus we expect that tc= 10.69.

Our expectation for ci depends on the bandwidth ofMA.The higher the bandwidth is, the more likely that MA isselected in a circuit and the lower that ci is. Thus we considera range of capacities for MA. Table III shows the averagenumber of connections that clients had to make to identify theguards ofHwhen we consider relays of different sizes to bethe malicious relay MA. The relays we select were chosenmiddle relays with probabilities that range from 0.0026 to

TABLE III: Speed of Guard Identification

Selection Prob. Tor BW Avg # of Cxns to t1

(min),as Middle (MiB/s) Identify All Guards = 10

0.0026 8.41 598.00 10.650.0052 16.65 357.33 6.370.010 31.97 227.94 4.060.021 66.04 141.74 2.530.030 96.61 118.40 2.11

0.030. We estimate the bandwidth a Tor relay would need to beto be selected with those probabilities using a linear regressionon the consensus weights and the estimated relay capacity. Theregression is on network data from 6/30/13. We can see thatfor relays with bandwidth in the range of 8100 MiB/s, theaverage number of connectionsc needed to identify all guardsranges from 598 to 118. c is a good estimate for c1, and asthe attack progresses through additional rounds the expectationfor ci only decreases as relays are disabled and the maliciousrelay becomes a larger fraction of the active network. Thus wecan conservatively use c as the estimate for all ci.

We can then use t1 = tcc

/as a conservative estimate forthe timeti

1to complete Phase 1 in round i. TableIII shows this

time for = 10 parallel connections. We use this value of because our experiments consisted of 10 clients simultaneouslyconnecting to hidden services. However, we expect that manymore connections could be created in parallel without increas-ing the connection timetc much because the time is dominatedby network latency and creating a connection uses relativelylittle network bandwidth. This could potentially decrease t

1 to

as little as tc= 10.96s.2) Time for Phase 2 (ti

2): During the ith round of a given

attack, the relay will have selected a set of guards (Tor usesat most 3). We suppose that the Sniper Attack can be run inparallel on all of these, and thus the time ti

2to disable all of

them is the longest time it takes to disable any one of them.Given a set of guards, we can use the linear regression of

SectionIII to estimate the memory consumption rate from theTor consensus weight. Then we can consider the time to filleach guards memory for varying memory capacities.

3) Time for Phase 3 (ti3): During Phase 3, the adversarycreates enough connections to H that ifGA has been chosenas a guard ofH, it will be detected on a resulting rendezvouscircuit. We suppose that the adversary creates 35 connectionsso that if GA is a guard it fails to be used as a guard onone of the resulting rendezvous connections with probabilityless than 6.87107. We use our previous estimate for theexpected circuit construction time of 10.69s and suppose thatthe adversary makes 10 parallel circuits. We thus estimate thatti

3 = 4 10.69 = 42.76s for all i.4) Time for DoS Deanonymization Attack (t): To provide

an estimate for t, we simulate the selection of guards by Hduring the attack using the TorPS tool [5]. As input to TorPS,we use a Tor consensus and server descriptors from 6/30/13.We perform 10,000 simulations of the attack. During eachsimulation, guards are selected by H in each round until GAis chosen. We estimate the total time t for a simulation byadding the given phase estimates in each round.

Table IVshows the results of these simulations. For eachbandwidth capacity of the malicious guard GA, we can see theresulting probability p of being chosen during an individualguard selection. This directly affects the expected number ofrounds needed for deanonymization, which we can see ranges

9


10/15

TABLE IV: Speed of DoS Deanonymization Attack

GA BW Guard Avg # Avg # Avg Time Avg Time(Mi Bps) Prob. R ounds Sniped 1 GiB (H:M) 8 GiB ( H:M)

8.41 0.0048 65.66 132.33 45:30 278:1416.65 0.0097 38.55 78.09 22:27 148:3431.97 0.019 23.03 47.05 12:12 83:4966.04 0.038 12.33 25.67 5:57 43:1296.61 0.054 8.75 18.50 4:08 30:22

from 8.75 to 65.66. These values can in general be roughlyestimated as 1/(2p) because Tor only replaces the snipedguards in each round with two new guards. The number ofguard sniped during the attack, shown next, ranges from 18.50to 132.33 and is also simply 2r+ 1. The total time t for theattack has a range of 4 hours and 8 minutes to 45 hours and30 minutes if all Tor relays have 1 GiB of free memory anda range of 30 hours and 22 minutes to 278 hours and 14minutes if Tor relays have 8 GiB free. Clearly, the time tosnipe the guards dominates t, and so we can approximate itsimply with t rt1

2. Thus, the adversary can significantly

reducet by running a guard or guards with a large amount oftotal bandwidth, which decreases r in expectation.

Finally, we note that it is quite possible that some guard

operators become aware that their guards have crashed andrestart them while the attack is still executing. Tor will goback to using such guards once they become available again.Thus, it may be necessary during the attack to snipe guardsmultiple times to keep them down.

V. DEFENSESAGAINSTS NIPERATTACKSThe Sniper Attack exploits two fundamental problems with

Tors design: a lack of enforcement to follow the flow controlprotocol; and unchecked, unbounded application queues. Inthis section, we address these problems by exploring defensestrategies (summarized in TableV) and their costs, limitations,and practical operational deployment issues.

A. Authenticated SENDMEsOne problem exploited by the Sniper Attack is that the

packaging edges are unable to verify that the delivery edgesactually received any cells. One solution to this problem isadding a challenge-response puzzle to every 100th cell. Eachpackaged cell currently includes a hash digest of its contentsso that bit errors may be detected by the client. A packageedge can require that the digest of each packaged cell be in-cluded in the corresponding SENDME feedback signal cell. Toprevent the delivery edge from pre-computing this digest whendownloading a known file, the package edge could include a 1byte nonce in every 100th cell. This nonce will randomizethe digest that must be returned in the SENDME, and canonly be guessed with probability 1/256. If the response digest

doesnt match the challenge, the exit can drop the circuit.Authenticated SENDMEs prevent clients from subverting the1000 cell in-flight limit, including those who attempt to cheatby preemptively sending SENDMEs to the exit in order todownload data faster.

This defense provides an elegant solution to detectingprotocol violations. It defends against a single client usingthe efficient version of the Sniper Attack. However, usingthis approach alone has some limitations. First, it does notcompletely stop the attack: each circuit will still be able tocause the target to queue 1000 cells (500 KiB), and so thetarget can still be taken down using the parallel attack from

TABLE V: Defense Capabilities

Attacks

Basic V1 Basic V2 Efficient Parallel

Defenses Authentication No No Yes No

Length Limit Yes Yes Yes NoCircuit Killer Yes Yes Yes Yes

Section II-C2. Second, relays are relying on honest circuitmembers to perform the authentication protocol correctly, andtherefore this defense does not protect against either of thebasic versions of the Sniper Attack where the packaging edgeis malicious. We could improve the situation by allowingintermediate relays to read and detect unexpected SENDMEcells and destroy the circuit, but we note that a self-defensestrategy is preferred to one that relies on other circuit members.Finally, this approach has a longer transition phase, since allclients and at least all exit relays need to be aware of theauthentication protocol.

B. Queue Length LimitAnother problem exploited by the Sniper Attack is that

Tors application queues may grow without interference bythe relay. Therefore, a simple defense is for each relay to

enforce a maximum queue size to limit the amount of memoryeach circuit may consume. If the queue length becomes greaterthan the allowed size, then the relay may assume a protocolviolation and destroy the circuit to inhibit malicious activities.

To find a good candidate queue size, we consider thatTors flow control algorithm already enforces a limit on thenumber of cells that may be in transit (1000, plus sometolerance for control messages). One approach would be to usea similar limit as a queue length limit, which provides a self-defense mechanism while also protecting against adversarieswho control multiple nodes in a circuit. However, as with theauthenticated SENDMEs defense, a queue length limit does notprevent an adversary that uses the parallel Sniper Attack fromcircumventing the memory limitations, since memory con-

sumption from its multiple circuits in aggregate can still crashthe relay with relatively low overhead. Further, a maximumqueue length would obstruct future development. Consideringthat the Tor Project anticipates custom transport protocols withdynamic feedback mechanisms, a hard threshold on the queuelength may complicate migrations. Finally, we note that thequeue length limit defense enables a new attack in whichwebservers could inject page objects that require new streamsand cause benign circuit queues to grow beyond the limit andtherefore be destroyed [18].

C. Adaptive Circuit KillingTo overcome the limitations of the previous defenses and

protect against the parallel Sniper Attack, we now develop

a more sophisticated, adaptive mechanism which is incre-mentally deployable and has strong security properties. Aclever attacker against both of the previous defenses can usea sufficiently high number of parallel circuits, each with ashort queue, to exhaust a relays memory. To prevent memoryexhaustion, a relay can begin and continue to kill circuitswhile the total memory consumption remains above a criticalmemory threshold. This technique will guarantee that a relayprocess will not terminate due to an out-of-memory condition.

1) Selecting Circuits: The central question to be solved isto decide which circuit should be killed if memory becomesscarce. This question is not as simple to answer as it might

10


11/15

seem at a first glance. For instance, the most straightforwardapproach would be to kill the circuit with the longest queue.This, however, can be leveraged for a new attack: an adver-sary could set up a large number of circuits with relativelyshort queues on a given relay, so that this relays memoryconsumption is very close to critical. Whenever a benigncircuit temporarily builds up a long queue, the threshold willbe exceeded and a benign circuit will be killed, while the

adversarys (shorter) circuits will remain in place. The relay istherefore manipulated in such a way that it will regularly killbenign circuitswithout any need for the attacker to spendresources beyond initially setting up the circuits. While therelay will not crash due to running out of memory, this is stillhighly undesirable.

We must therefore aim for a decision criterion whichcannot be abused by an attacker to make a relay kill benigncircuits. Here, we propose to use the time of arrival of thefrontmost cell in the queue as the basis for our decision: ifmemory becomes scarce, the circuit killing mechanism willkill the circuit with the currently oldest cell at the front ofits queue. We require that each incoming cell be tagged witha timestamp upon arrival at a relay, but note that this already

happens in the current versions of Tor in order to compute celldelay statistics. Therefore, this mechanism is almost trivial toimplement. In the remainder of this section, we will argue whyit is also effective.

To gain an intuitive understanding, observe that anattackerin order to avoid that his circuit is killed whenmemory becomes scarcewill have to keep the frontmost cellin the circuits queue fresh. Since Tor circuit queues are strictFIFO queues, the frontmost cell in any given circuit queue willhave spent more time in this queue than any other cell. Theattacker is therefore forced to continuously read from all hiscircuits; otherwise, the cell at the attack circuits head willsoon be older than the frontmost cells in the queues of benigncircuits. Thus, by deriving bounds on the share of the relays

available bandwidth that is required in order to make a relaykill a benign circuit, we will be able to prove the effectivenessof the defense strategy.

2) Proof Sketch: Consider a specific relay which offers atotal bandwidth B for relaying Tor circuits. We assume thatB is available both in incoming and in outgoing direction(substantially imbalanced incoming and outgoing bandwidthsdo not make sense for a relay which essentially forwards allincoming data). Furthermore, assume that this relay is currentlyused by a total ofn active circuits. We define an active circuitas a circuit which currently has at least one cell in its queue.

If the outgoing bandwidth of the relay were assigned tothe active circuits in a perfectly fair manner, then each circuitwould experience an outgoing data rate of

rfair=B

n. (1)

Of course, in practice, the distribution will not be perfectly fair;in fact, there are certain known artifacts with respect to inter-circuit fairness [43]. But Tor relays include mechanisms whichwill still result in bandwidth allocations to circuits that arenot arbitrarily unfair: there is a round-robin scheduler whichpicks cells from circuit queues for transmission. Moreover,circuits are carried over TCP connections, and TCP, too,strives for a fair distribution of available bandwidth to multipleconnections. Both of these mechanisms are controlled by the

relay and are thus outside the sphere of influence of an attacker.We will discuss the case of an attacker who is able to claima huge fraction of the relay bandwidth for himself later. Fornow, we may reasonably assume that there is a fairness factor0< 1 such that each active circuit receives a bandwidthshare of at least

r B

n. (2)

As we will see, the exact value of is not critical for ourscheme, as long as an active circuits bandwidth share doesnot become arbitrarily small for a longer period of time.

Now observe that benign circuits will typically have queueswhich are bounded above by a relatively small size Q. Q is,as discussed before, in the order of 1000 cells in the currentTor protocol. Even if possible future protocol versions do notenforce a hard upper limit, observe that high values ofQimplylong queues in the relays and thus poor circuit performance. Inpractice, any reasonable future protocol design will thereforealso result in reasonable queue lengths. Note that while weassume that such an upper bound Q exists in our analysis,its value need not be known and is not used to decide whichcircuit to kill. The exact value is thus much less critical than

in the previously discussed queue length defense.Based on these assumptions we make a central observation

for our argument: if a benign circuits queue length does notexceed Q and its mean rate is at least r, then the maximumtime for which a cell can remain queued is bounded above by

dmax =Q

r =

Qn

B. (3)

Therefore, if tnow is the current point in time, the cells at theheads of all benign circuits queues will have a timestamp laterthan tnow dmax.

Note that an attacker using a single circuit will thus haveto make sure that the cell at the front of the queue does notbecome older than dmax, i. e., the cell must have arrived at a

point in time later than tnow dmax. Only then can the attackerhope that a benign circuit will be killed instead of the attackerscircuit. If the attacker uses multiple circuits in parallel, thesame criterion must hold for all these circuits. Consequently,all the cells in the attackers circuits must have arrived withina time interval of length dmax.

Let the amount of free memory at the relay be denoted byM. The attacker must (roughly) build up queues with a totalsize ofMbytes in order to make the relay kill circuits. Since,as seen before, the attacker must inject all these cells within atime span of length dmax, the attacker needs to send cells intothe relay at a mean rate of at least

ra= M

dmax=

M

Q

B

n =

M

Q r. (4)

This is a factor ofM/Q higher than the minimum outgoingrate r which we assumed for benign circuits above in (2).Observe that M/Q can easily be made a very large numberif sufficient memory is provided. We recommend an order ofmagnitude of a few hundred megabytes, which is not a problemon todays relays (also on machines with a 32 bit addressspace) and results in a factor M /Q in the order of 1000.

The attacker would therefore have to claim the incomingrelay bandwidth virtually entirely for himself in order to mounta successful attack that results in a benign circuit being killed.Although such an attack is possible if an adversary has enough

11


12/15

Fig. 5: The circuit killer renders the Sniper Attack ineffective.

bandwidth, we consider it practically unrealistic for two keyreasons: first, fairness mechanisms are in place also on theincoming side of a relay, making it very hard to achieve this inthe first place; and second (and much more important), observethat consuming almost all of a relays bandwidth constitutes byitself a far more devastating attack on the relay. An adversary

with enough bandwidth to succeed in this attack and cause arelay to drop a few benign circuits would do more damageusing its bandwidth in a classic DoS attack, or in a selectiveDoS attack [13] launched while running malicious relays. (Abandwidth attack on a relay may in fact kill benign circuitsanyway, e. g., due to TCP connections timing out.)

3) Evaluation: We implemented the described out-of-memory (oom) circuit killing as a Tor software patch. Itintroduces a new configuration parameter MaxQMem, whichspecifies the maximum amount of memory usable by Tors cir-cuit queues. Every second the algorithm checks for violationsto this threshold and kills a circuit if necessary. We re-run theexperiments from Section III (the results of which are shownin Figure4a) with the oom circuit killer deployed on all relays,

using a MaxQMemof 500 MiB for the direct and 250 MiB forthe anonymous Sniper Attack (we chose different values solelyfor a clearer presentation). The results in Figure5 contrast thememory consumption with and without our defense. With ourdefense in place, it depicts a horizontal line around the config-ured MaxQMem during the attack, showing that the consumedmemory is bounded by our new parameter. Closer examinationshows a microscopic oscillation around the threshold, i.e. firstsurpassing it, then freeing memory, and then rising again dueto the other sniper circuits. It successfully protects the processfrom arbitrarily increasing the memory consumption and thusfrom being killed. During the experiments of the direct andthe anonymous attack the circuit killer intervened 43 and 32times respectively, and in all cases only attacking circuits were

killed. Thus this defense resulted in a 100% identification ratewith no false positives.

The above results reveal insights into the interplay betweenfairness and the robustness against the Sniper Attack whensuch a mechanism is in place. An attacker needs a lower rateand thus fewer resources either if the queues of benign circuitsbecome longer (higher value ofQ) or if the distribution of relaybandwidth to the circuits becomes less fair (smaller value of). Approaches that bound the queue lengths based on per-linkfeedback [10], or improve transmission scheduling in Tor [43]would therefore complement this defense strategy.

In summary, we believe that adaptive circuit killing based

on the queuing duration of the cells at the heads of thequeues constitutes a strong defense. Not only does it preventa relay from crashing due to insufficient memory, it is alsovery resilient against being abused to make relays kill benigncircuits. It is simple to implement and easily deployable: themechanism need only be implemented on the relays, and it isimmediately effective on all relays where it is deployed.

VI. DEFENSE AGAINSTD OS DEANONYMIZATION

Our proposed defenses against the Sniper Attack protectagainst memory exhaustion but do not protect against bruteforce network or CPU overloading. In addition, other DoSattacks on Tor continue to be discovered [31], [36], and a Torrelay is vulnerable to all DoS attacks on the host platform. TheDeanonymization DoS Attack can be performed usinganyDoSattack on a Tor relay and thus is still a serious problem.

As a defense against it, we suggest that the Tor client limitthe number of relays that it chooses for the most sensitivepositions in its circuits. In the following we describe thisproposal in detail, and we evaluate its security and its costin terms of network performance.

A. Limiting Network Exposure

The key vulnerability in Tor path selection that we exploitis that a client is willing to choose an unlimited number ofentry guards in a period of time. We propose the simplefix of limiting the rate at which clients will add relays totheir entry guard list. In addition, hidden services make guarddiscovery fast for the adversary by selecting new circuits foreach connection. To slow this down, we suggest that hiddenservices use two levels of guards for their rendezvous circuits.

Our first proposed change to the path-selection algorithmlimits entry-guard selection. This change applies to any newcircuit, including exit circuits, rendezvous circuits, and intro-duction circuits. It tries to maintain a certain number ag ofactiveguards, that is, guards that are currently responding. Forimproved security, though, it puts a hard limitr on the number

of recentguards, that is, guards selected more recently than ttime ago. Specifically, the algorithm for circuit guard selectionis as follows: if there are at least ag active guards, return arandom one; else if there are fewer than r recent guards, selectnew guards until eitheragactive guards orrrecent guards existand then return a random active guard; else if there are anyactive guards, return a random one; else return an error. Notethat guard expiration, that is, removal from the guard list, is aseparate procedure handled on a time schedule as Tor currentlydoes [21].

If no active guards are available but the rate limit has beenreached, circuit selection cannot proceed. There are a coupleof reasonable options for handling this at the user level: ( i)indicate to the user that Tor will be temporarily unavailable to

prevent a possible security attack but allow a manual override,or (ii) use a configuration setting for desired security level todetermine if circuit construction should be halted.

This algorithm isnt a strict generalization of Tors currentprocedure. However, a close approximation is that currentlyTor usesag = 2 and infiniter (Tor prefers 3 guards if possiblebut only enforces that 2 are active). We consider a range ofparameter values in our evaluation. Of course, it only makessense to have the recent time t less than the expiration time.

Our second proposed change is for hidden services to usemiddle guardsfor their entry guards when creating rendezvouscircuits. A hidden service Hmaintains a middle-guard set of

12


13/15

relays MG for each of its guards G. After choosing a guardG for a new rendezvous circuit, H adds relays to MG asnecessary to maintain am active relays in the set. Then Hchooses an active middle guard randomly from MG to use inthe circuit. Middle guards expire either after some time chosenuniformly from[e0, e1]or when their guard expires, whicheveroccurs first.

The purpose of these middle guards is to increase the

time and effort needed for the discovery of hidden-serviceentry guards, which is otherwise quite fast and cheap. Hid-ing the identity of the guard helps prevent any DoS-baseddeanonymization attack. In addition, it frustrates other guard-based attacks. For example, currently a Tor adversary can veryeasily monitor guard use by a targeted hidden service andnotice the use of a guardeven for just a short timerunby an entity or in a jurisdiction for which the adversary caneasily set up surveillance or obtain logs.

The design choices in our middle-guard algorithm are madespecifically to prevent such attacks. We do not suggest apply-ing rate-limiting to middle-guard selection, as an adversarycould then achieve the effect of the entry-guard DoS justby attacking the am middle guards. We rather force him

to attack enough middle guards to observe the entry guarddirectly and then be forced to attack it as well. We also do notsuggest extending the guard concept beyond the second circuithop. This would further reduce load balancing, and becauseguard identification can be achieved via attacks other thanDoS [23], [24], [33], there is a limit to the benefit of raisingits cost. Finally, we only apply middle guards to rendezvouscircuits because client and introduction circuits already havelonger lifetimes, and middle guards increase circuit linkability,which is especially a concern for client circuits. Thus weconservatively limit this proposal to where it seems like anunambiguous improvement.

B. AnalysisBoth entry-guard rate-limiting and the use of middle guards

sets up a tradeoff between security and performance. Weconsider this tradeoff separately for each defense.

1) Entry-Guard Rate-Limiting: The main performance costfrom rate limiting entry guards is that a client may be left attimes with no active guards, even just due to benign guardfailure. Depending on how the limiting is implemented, thiscould mean that Tor is unavailable to the user for a period oftime or that the user must consider if he is willing to allow aless restrictive rate-limiting than is recommended by default.To evaluate how often this might happen, we simulated rate-limited guard selection. Our simulator selected a new guardusing the same constraints and weighting as Tor 6,and it useddata from Tor Metrics[8] to determine past network states. Werequired that the desired number of active guards be available

ateverytime instant, a conservative approximationespeciallyfor individual users, who likely only use Tor intermittently.

Table VI shows results of simulations from February toMarch 2013 (after two months all guards will have expired),where each row represents 5000 simulations. For each settingofag andr , we include the largest t for which the fraction ofsimulations withanyperiod of guard unavailability was at most0.001, if any. The table includes this probability of a period ofdown time as well as the median length among such periods.We can see that with even fairly strict rate limiting, a client

6The simulator is based on Tor 0.2.3.25.

TABLE VI: Unavailability from Rate-Limiting Entry Guards

ag r t (days) Prob. Down Med. Down Time (H:M)

1 3 7 0.0004 77:121 4 28 0.0008 840:301 5 28 0 N/A2 4 14 0.0004 10:542 5 28 0.0004 224:24

almost never experiences down time, and when it does it canrecover as fast as within half a day. Guard reselection due toexpiration happens at a rate of 1 relay every 15 days, and sowe could, for example, set a limit at double this existing rateby setting ag = 1, r = 4, and t = 28 and still obtain veryhigh availability.

With rate-limiting in place, it becomes much more difficultfor an adversary to push a target client into using a maliciousguard using a DoS attack. At most the client can be forced tochoose another r guards every t time. Suppose that the mali-cious guards have probability p of being selected as a guard.During the Deanonymization DoS Attack, the probability thattarget client chooses a malicious relay within in the first iperiods of timetis1(1p)ri rip, ignoring thatpincreases

slightly as the targeted relays are taken down. For example,considerr = 4,t = 28days, and suppose that p = 0.017 (thisis the top guard probability on 6/30/13). Let the adversary run aDoS everyt days against all observed guards of the target thatmay be unexpired (the maximum expiration time is public).Note that the DoS need only last briefly, and the attack workseven if relays come back online shortly afterwards; thus thisis not an implausible attack. The probability that the targetclient selects the malicious guard with 3 months is 0.19. Thiscompares to virtual certainty without guard rate-limiting andto a probability of0.10 over the same time period without aDoS attack just due to guard expiration.

Clearly, however, over time the DoS DeanonymizationAttack will eventually succeed. For users facing a persistant

adversary, the only option may be to limit guards to a deliber-ately chosen set using the relevant Tor configuration options.We can also imagine a more sophisticated automated defensescheme in which multiple guard failures in a short time periodare handled with increasing suspicion, but we leave such animprovement to future work.

2) Middle Guards: A potentially significant performanceissue with the use of middle guards is that traffic will not beload balanced as effectively because: (i) the capacity of anentry guard is higher than the capacity of its middle guards;(ii) traffic from different services gets concentrated by chanceon middle-relay hot spots; or (iii) relays join the networkbut arent chosen quickly as middle guards.

(i) can be mitigated by setting am large enough. By

looking at the recent 6/30/2013 consensus as an example,we observe that the observed bandwidth of relays weightedby their probability of being selected as an entry guard is9669.89 KiB/s, and the observed relay bandwidth weightedby the probability of selection as a middle relay is 7721.50KiB/s. Therefore we could prevent middle-guard bottlenecksin expectation by setting am 2. In addition, load from alltraffic other than hidden services would be load balancing asusual, making the capacities available to hidden-service trafficeven more similar between guard and middle relays.

(ii) and (iii) can both be mitigated by making the averagemiddle-guard expiration short enough that hot spots dont

13


14/15

develop and new relays are quickly used. Middle guardsneed only slow down guard discovery to the speed of otherknown methods for identifying guards, such as throughputfingerprinting [33] or the long-path congestion attack [23],which are each effective within hours. Their complexity andresource cost is significantly higher than passive observationat a relay, however, and so the speeds of the attacks need notbe equalized. Moreover, because most Tor traffic continues to

be load-balanced effectively, the net imbalance from middleguards seems likely to be small.The defense offered by middle guards is that an adversary

running malicious relays cannot quickly discover hidden-service entry guards by sending the service many rendezvousrequests. Instead, an adversary trying to directly observe theentry guard must wait to be selected either as the entry guarditself or as a middle guard. With am middle guards and anaverage expiration ofe = (e0+ e1)/2 days, an adversary witha probability p of being selected as a relay will expect towait (1/(1 (1 p)agam) 1)e days until being selected asthe middle guard of some entry guard. Suppose that ag = 1,am= 2, e0 = 30 and e1 = 60 (i.e. middle-guard expiration isthe same as current entry-guard expiration), andp= 0.021(the

largest middle-relay selection probability on 6/30/13). Thenthe expected time for the adversary to be selected as a middleguard is 1037.79 days.

VII. RELATED W OR KInternet DoS attacks, those that make an Internet service

unavailable for longer than the intended waiting time [45], havebeen extensively studied in the literature. Although unique inthis space, the Sniper Attack is most closely related to lowrate and slow read DoS attacks, which are variants of thewell-known SYN flood DoS attack [20], [40]. The goal ofthese attacks is to exhaust resources in order to prevent thevictim from processing new incoming connection requests.Transport layer low rate attacks [30] exploit TCPs retrans-

mission timeout (RTO) dynamics. An attacker repeatedly sendsshort high-rate packet bursts, which produce packet losses (i. e.,timeouts) and thus make the victim double the RTO of otherTCP connections [37]. Transport layer slow readattacks[26]send legitimate data requests, advertise a small TCP receivewindow, and then slowly empty the receive buffer. As a result,the victims send buffer remains full over a long time span, thusblocking resources. Similar low rateand slow readtechniqueshave been described to exploit web server weaknesses on theapplication layer[2], [14], [38]: sending partial HTTP requestsor slowly reading responses to requests will prolong the HTTPsession and extends the time in which the availability of theweb servers connection pool is reduced.

Although the Sniper Attack shares the general goal of

preventing new incoming connections with low rate and slowread attacks, it is achieved as a byproduct of the more directgoal of exhausting system memory resources. In particular,we consume memory from the application layer using validoverlay network protocol messages without reading from thevictim. Therefore, our attack may be characterized as a noread attack. Another important distinction is that, unlike theattacks described above, our attack does not require severalsimultaneous connections to the target and continued effortin order to maintain the effect of the attack. Finally, ourattack destroys existing established connections in addition topreventing new ones.

The Sniper Attack may also be categorized as a permanentDoS attack, as it exploits application layer overlay networkprotocol semantics to consume system memory and crash theprocess. It is distinguished from similar attacks, such as thePing of Death[29], in that it utilizes valid messages to exploitthe protocol design. Fixing it is therefore not simply a matterof correcting a broken protocol implementation.

Our attack is also similar to those that rely on misbehaving

receivers and optimistic ACKs to bypass flow control protocolmechanisms [9], [39], [41]. In particular, the opt-ACK attack[41]is similarly challenged to adjust a feedback signal rate insuch a way that it still appears legitimate to the communicationpartner. Our attack differs in that we target application layerprotocols of overlay networks in order to exhaust the availablememory, rather than targeting network layer protocols for thepurposes of consuming the available bandwidth. As such, theSniper Attack is a no read memory exhaustion attack.

DoS attacks against the Tor overlay network have beenstudied before, building upon a fundamental observation firstmade by Syverson et al. [42]: if the first and the last relayalong a Tor path are compromised, an adversary can link thesource and destination by correlating traffic patterns. verlier

and Syverson first demonstrated how an adversary could lieabout the available bandwidth of compromised relays in orderto inflate the probability of being selected for a hidden servicecircuit [34], and Bauer et al. extended the attack to increasethe probability of end-to-end compromise of general purposecircuits [11]. Borisovet al.[13] describe a selective DoS attackon Tor where malicious relays terminate circuits of which theyare a part but do not control both ends. This forces clients tore-build circuits and similarly increases the probability of end-to-end compromise by the adversary. Danner et al.show howselective DoS attacks can be provably detected by exhaustivelyprobing potential paths [15], while Das and Borisov reduce thecost of detection using probabilistic inference [16].

Resource consumption attacks that may also be used to in-

crease an adversarys probability of end-to-end circuit compro-mise include the Packet Spinning attack[36] and the CellFloodattack [31]. In the Packet Spinning attack, the adversarycrafts special packets that cause them to continuously spinthrough circular circuits composed of the target relays. In theCellFlood attack, the adversary uses special handshake packetsto efficiently build a large number of circuits through the targetrelays. Both of these attacks effectively make relays appearbusy by forcing them to spend resources doing unnecessarywork. Honest clients circuits through these relays will then bemore likely to time out, causing them to choose new circuitscontaining malicious relays with higher probability. The SniperAttack also causes relays to perform unnecessary work, butfocuses on consuming memory resource rather than bandwidth

or computational resources.Our hidden service deanonymization attack builds upon

techniques developed in previous work. In particular, verlierand Syverson first identified that hidden services could belocated quickly and easily [34] because rendezvous circuitsare created on demand using new relays for each circuit. Theadversary could therefore continue to make new connectionsto a hidden server until traffic correlation indicated that thehidden server built a circuit that directly connected to one ofthe adversarys nodes. They further described how a hiddenserver using guard nodes would still be insecure against anadversary using the attack to identify the hidden servers

14


15/15

guards and then DoS them: this process could be repeated untilone of the adversarys nodes was chosen as a new guard. Theyoutlined layered guards, or guard nodes for the guard nodes,to help defend against such an attack. Biryukov et al. showedhow the adversary may detect its position on a rendezvouscircuit by simply counting cells instead of performing trafficcorrelation [12]. Finally, verlier and Syverson introducedValet Service nodes to improve the resilience of introduction

points against DoS attacks [35].VIII. CONCLUSIONS ANDF UTUREW OR K

In this paper we presented a novel and destructive DoSattack against Tor that may be used to anonymously disablearbitrary Tor relays by exploiting the protocols reliable end-to-end data transport. We outlined several ways to carry outthe Sn

The Sniper Attack Anonymously Deanonymizing

Documents

Transcript of The Sniper Attack Anonymously Deanonymizing