1# What other attacks are there against Onion Services? 2 3In addition to the attacks that the vanguards addon mitigates (which are 4documented in 5[README\_TECHNICAL.md](https://github.com/mikeperry-tor/vanguards/blob/master/README_TECHNICAL.md)), 6there are many other attacks on onion services. Most of these attacks are 7theoretical and have not been observed in the wild, but that does not make 8them impossible. The attacks that you are at risk for depends upon who is 9interested in trying to deanonymize you, and what their capabilities are. 10 11To help make this more clear, we're going to first go through the general 12taxonomy of adversaries, along with their capabilities and the types of 13attacks they can perform, in the [Adversaries](#adversaries) section. 14 15In the [What can I do to be safer?](#what-can-i-do-to-be-safer) section, we'll 16give some specific recommendations that will help defend against these 17adversaries. 18 19# Adversaries 20 21Adversaries can be roughly categorized as having one or more of four 22positions: [Client](#adversaries-client), [Network](#adversaries-network), 23[Local](#adversaries-local), or [Global](#adversaries-global). 24 25Adversaries can have more than one position at the same time, and each of 26these positions can be either "**active**", or "**passive**". For brevity, we 27do not make heavy use of the **active/passive** distinction in this document. 28 29The adversary may also have additional outside information or suspicions that 30can help them mount their attacks. 31 32Each of the adversary subsections below starts with a list of capabilities 33that the adversary has, and this list is followed by additional paragraphs 34that describe the specific attacks that provide those capabilities. When 35relevant, we link to our specific mitigation recommendations from each attack 36description paragraph. 37 38We classify each adversary capability using the following action verbs that 39describe the scope of that capability: 40 41 1. **Suspect** - When we say **"suspect"** with respect to a capability, that 42means that the adversary can perform an attack to obtain this information, but 43they will not have high certainty that they are correct. Depending on the 44attack, they may end up suspecting a lot of unrelated Tor clients as a result 45of their attack. These attacks may also fail to suspect the client that is 46actually of interest to them. 47 2. **Confirm** - When we say **"confirm"** with respect to a capability, 48that means that the adversary is able to use an attack to confirm outside 49information, prior suspicion, or speculation with extremely high certainty. 50 3. **Determine** - When we say **"determine"** with respect to a capability, that 51means that the adversary can perform an attack to obtain the described 52information with extremely high certainty in a relatively short amount of 53time, if the conditions for the attack are met. 54 55Attacks that merely allow the adversary to **suspect** information are not 56typically useful, unless there is also an attack that allows the adversary to 57**confirm** that information. 58 59Attacks that allow an adversary to **confirm** information are not useful 60unless the adversary has some prior information or suspicion. 61 62Attacks that **determine** information right away are thus more powerful 63than attacks that **confirm** information, because they do not require any 64prior information or suspicion. They are also more useful to the adversary 65than attacks that allow them to **suspect** information, because they provide 66a very high degree of certainty. 67 68## Adversaries: Client 69 70Client adversaries are those that attack your onion service using nothing more 71than a Tor client and normal internet access. 72 73In addition to nuisances such as DoS attacks, these adversaries can 74perform anonymity attacks that provide the following capabilities: 75 761. **Determine** if a specific onion service is exploitable, and if so, exploit it (possibly learning the IP address). 772. **Determine** if a specific onion service is also listening on a public IP address, by scanning the public internet for it. 783. **Determine** if a specific onion service always goes down at the same time as 79a public Tor relay goes down. 804. **Determine** that a specific onion service is running the vanguards addon. 815. **Suspect** that a specific onion service is using [OnionBalance](https://github.com/DonnchaC/onionbalance). 826. **Suspect** that a specific onion service may be using a particular Guard. 83 84Capabilities #1-3 should be self-explanatory. 85 86For capability #4, the client adversary can **determine** that a specific onion 87service address is running the vanguards addon by observing how that onion 88service behaves. In particular, it can attempt one of the attacks that the 89vanguards addon defends against, and see if the onion service closes circuits 90in response. In these cases, log lines will be emitted by the vanguards addon 91at NOTICE level or above. If you do not want client adversaries to be able to 92easily detect this addon, you can set **close_circuits=False** in 93[vanguards.conf](https://github.com/mikeperry-tor/vanguards/blob/master/vanguards-example.conf). 94However, a network adversary who runs your Guard node can still **determine** 95that you use this addon (see the [network adversary 96section](#adversaries-network) for details). 97 98For capability #5, the client adversary can **suspect** that a specific onion 99service address is running 100[OnionBalance](https://github.com/DonnchaC/onionbalance). This is because the 101onion service descriptors for OnionBalance instances will often contain more 102introduction points than normal, and these introduction points may even be 103split across multiple distinct onion service descriptors. (The client only 104**suspects** this because both of these things can happen in normal onion 105service operation as well). To reduce the ability of the client adversary to 106**suspect** this, set **DISTINCT_DESCRIPTORS=False** and 107**MAX_INTRO_POINTS=7** in your OnionBalance configuration. 108 109For capability #6, the client adversary may be able to **suspect** that a specific 110onion service is using a particular guard by attacking that guard. If that 111guard goes down or becomes slower, they may notice the effect on that onion 112service. This is one of the reasons why the vanguards addon uses two guards in 113a balanced way by default. Additionally, the adversary may be able to flood an 114onion service with traffic to notice spikes in our public relay bandwidth 115statistics at the guard. Setting **circ_max_megabytes** in 116[vanguards.conf](https://github.com/mikeperry-tor/vanguards/blob/master/vanguards-example.conf) 117to an appropriate value for your service can help you detect and mitigate this 118attack. 119 120## Adversaries: Network 121 122Network adversaries are those that run relays in the Tor network, and/or that 123compromise Tor relays. They can also use the network (or a Tor client) to 124inject traffic of their choice (especially against onion services). 125 126The vanguards addon is designed to protect against network adversaries. 127Setting aside the attacks that the vanguards addon defends against (which are 128documented in 129[README\_TECHNICAL.md](https://github.com/mikeperry-tor/vanguards/blob/reamde/README_TECHNICAL.md)), 130network adversaries can still perform attacks that provide the following 131capabilities: 132 1331. **Determine** your Guard relays, if they run one of your Layer2 middle relays. 1342. **Determine** that you are running an onion service that is using the vanguards 135 addon, if they run one of your Guard relays. 1363. **Confirm** that a specific onion service is using their Guard or Layer2 middle 137 relays, if it is. 1384. **Confirm** that a specific onion service is not using their Guard or Layer2 139 middle relays, if it is not. 140 141The vanguards addon is designed to make the network adversary's attacks as 142difficult and unlikely as possible, and to take as long as possible, but they 143can still succeed if you get unlucky. The Tor Project takes these attacks 144seriously, and they are topics of [active 145research](https://blog.torproject.org/tors-open-research-topics-2018-edition), 146but for now, the vanguards addon is the best way we have to defend against 147this adversary class. 148 149For statistics on how long capability #1 takes, please see [our analysis of 150our parameter 151choices](https://github.com/asn-d6/vanguard_simulator/wiki/Optimizing-vanguard-topologies). 152 153For capability #2, if you are using a guard relay run by the network adversary, they can 154**determine** that you are running an onion service that is using the 155vanguards addon through [circuit fingerprinting attacks](https://www.usenix.org/node/190967). 156All of your onion service circuits (which are recognizable via the techniques 157from that paper) will be made to a small set of layer2 vanguard relays. Normal 158onion services (which are also recognizable at the guard relay via these same 159techniques) will make circuits to the entire set of relays in the Tor network. 160This discrepancy allows a malicious guard to determine that you are using the 161vanguards addon. 162 163For capability #3 and #4, the network adversary is able to perform 164**confirmation** attacks to **confirm** that you are or are not using their 165Guard or middle relays via the following mechanisms: 166 1671. Inject special types of traffic at specific times towards your onion service (as was done [by CMU with RELAY_EARLY](https://blog.torproject.org/tor-security-advisory-relay-early-traffic-confirmation-attack), and [shown in the DropMark attack](https://petsymposium.org/2018/files/papers/issue2/popets-2018-0011.pdf)). 1682. Inject large amounts of traffic towards your onion service, and look for these additional traffic patterns on their relays. 1693. Close circuits at their relays, and observe if this causes any of their connections to your onion service to close. 1704. Utilize [cryptographic tagging attacks](https://lists.torproject.org/pipermail/tor-dev/2012-March/003347.html) to mark circuits at their relays, and observe this mark at other relays (such 171as the Rendezvous Point). 172 173The vanguards addon has additional checks to detect activity related to these attacks, as well. Those details are covered in 174[README\_TECHNICAL.md](https://github.com/mikeperry-tor/vanguards/blob/reamde/README_TECHNICAL.md). 175 176## Adversaries: Local 177 178Local adversaries include your WiFi [router 179administrator](https://nakedsecurity.sophos.com/2018/04/18/russias-grizzly-steppe-gunning-for-vulnerable-routers/), ISP, hosting provider, or VPN, as well as the ISP or hosting provider of 180the Tor relays you use to connect to the Tor network, and any other ISPs and 181[routers](https://spectrum.ieee.org/tech-talk/computing/hardware/us-suspicions-of-chinas-huawei-based-partly-on-nsas-own-spy-tricks) along your path to the Tor network. 182 183The local adversary has less surveillance resolution than the network 184adversary, because Tor's TLS encryption prevents it from knowing which of 185your packets belong to which Tor circuit. This means that the local adversary 186cannot perform most of the fingerprinting and related attacks that the network 187adversary can perform. 188 189However, local adversaries still have the following capabilities: 190 1911. **Determine** that you are using the public Tor network. 1922. **Suspect** that your Tor client might be running an unknown onion service. 1933. **Suspect** that your Tor client might be running the vanguards addon (soon to be 194 fixed). 1954. **Confirm** that you are running a specific onion service address, if you are 196 running a specific service that is of interest to them. 197 198For capability #1, local adversaries can **determine** that you are running Tor 199because the list of Tor relays is public, and connections to them are obvious. 200[Using a bridge with your onion service](#the-best-way-to-use-bridges) can 201help mitigate this attack. 202 203For capability #2, local adversaries might **suspect** that your Tor client could 204be an unknown onion service because it exhibits traffic patterns that are 205unlike most other Tor clients. Your connections will stay open all of the 206time, and you will regularly transmit data while other nearby humans are 207asleep, as well as while they are awake. Your traffic will also be 208asymmetrical. While most Tor clients download, you will likely be doing a lot 209of uploading. [Using or running a bridge or Tor 210relay](#Use-Bridges-or-Run-a-Relay-or-Bridge) with your 211Onion Service can help conceal these traffic patterns, especially when [used 212in combination with OnionBalance](#using-onionbalance). 213 214For capability #3, local adversaries might also **suspect** that you could be 215using the vanguards addon, at least until [Proposal 216291](https://gitweb.torproject.org/torspec.git/tree/proposals/291-two-guard-nodes.txt) 217is turned on. This is because you will be using two Guards in a balanced way, 218as opposed to using a second Guard only sometimes (as normal clients do 219today). Proposal 291 is a consensus parameter change. The rest of the Tor 220Project has to agree that this is a good idea, and the change will be 221immediate. I am convinced that worse attacks are possible without this 222consensus parameter change, but discussion and deliberation of all possible 223attacks and all possible future alternatives can take a while. Sometimes 224years. In the meantime, I am still convinced it is safer for onion services to 225use two guards in a balanced way, even if they stand out for doing so. 226 227With capability #2 and #3, the local adversary may **suspect** that you could be 228running an onion service, and maybe even one that wants high security, but 229they will not know which onion service it is. 230 231For capability #4, if the adversary is interested in deanonymizing a small set of 232specific onion service addresses, they can attempt to **confirm** that you are 233running one of these specific services on their local network via a few 234different attack vectors: 235 2361. Block your connection to Tor (or disable your internet connection) to see if any onion services they care about go down. 2372. Send lots of traffic to the onion service to see if you get more traffic on your internet connection. 2383. Kill your TCP connections to see if any of their connections to that onion service close. 2394. If you weren't using vanguards, they can confirm an onion service even 240 easier (see [Proposal 291](https://gitweb.torproject.org/torspec.git/tree/proposals/291-two-guard-nodes.txt) for details). 241 242The first two vectors of this **confirmation** attack can be mitigated by 243[using OnionBalance](#using-onionbalance), and by setting 244**circ_max_megabytes** in your 245[vanguards.conf](https://github.com/mikeperry-tor/vanguards/blob/master/vanguards-example.conf) 246to an appropriate value for your service. 247 248Unfortunately, the third vector is not possible to fully mitigate until Tor 249supports datagram transports and [conflux-style session 250resumption](https://www.cypherpunks.ca/~iang/pubs/conflux-pets.pdf). 251 252However, [monitoring your service closely](#monitor-your-service) for 253connectivity loss can help you detect attempts by the adversary to **confirm** 254your service location. The vanguards addon will emit NOTICE and WARN messages 255related to connectivity loss, and your service will become unreachable. 256 257## Adversaries: Global 258 259A global adversary is an adversary that can observe large portions of the 260internet. [The Five Eyes](https://en.wikipedia.org/wiki/Five_Eyes) and its 261extended versions are the canonical example of this adversary. However, 262adversaries that can compromise a large number of internet routers (such as 263[Russia](https://nakedsecurity.sophos.com/2018/04/18/russias-grizzly-steppe-gunning-for-vulnerable-routers/) 264or 265[China](https://spectrum.ieee.org/tech-talk/computing/hardware/us-suspicions-of-chinas-huawei-based-partly-on-nsas-own-spy-tricks)) 266are also in this class. 267 268The global adversary can perform most of the attacks that the local adversary 269can, but everywhere. (It may be significantly more expensive for the global 270adversary to perform **active** attacks than it is for the local adversary to 271do so, but for the most part this degrades their capability only slightly). 272 273The global adversary has the following capabilities: 274 2751. **Determine** a list of most/all IPs that connect to the public Tor network. 2762. **Suspect** which of these IPs might be running onion services. 2773. **Suspect** which of these IPs might be using the vanguards addon (soon to be fixed). 2784. **Suspect** that an IP might be running a specific onion service address, if it is 279 running a specific service that is of interest to them. 280 281The mitigations for these are the same as they are for the local adversary. 282 283This same adversary can theoretically perform additional attacks to attempt to 284deanonymize all Tor traffic all of the time, but [there are 285limits](http://archives.seul.org/or/dev/Sep-2008/msg00016.html) to how well 286those attacks scale. These limits are also the reason that the global 287confirmation attack has been degraded to "**suspect**" for #4. 288 289For capability #4, the global adversary becomes more certain in their 290suspicion if they are able to induce the onion service to transmit 291significantly more traffic than its baseline for a long period of time. Again, 292the mitigations for this are to use [OnionBalance](#using-onionbalance), use 293or run 294[a bridge](#Use-Bridges-or-Run-a-relay-or-Bridge) with your 295onion service, and/or set **circ_max_megabytes** in your 296[vanguards.conf](https://github.com/mikeperry-tor/vanguards/blob/master/vanguards-example.conf) 297to an appropriate value for your service. 298 299 300# What can I do to be safer? 301 302Quite a few things. Using the vanguards addon is a good start, but it is not 303the whole picture. 304 305There are four classes of things you can do to improve your position against 306various attacks: 307 3081. [Have Good Opsec](#have-good-opsec) 3092. [Use Bridges or Run a Relay or Bridge](#use-bridges-or-run-a-relay-or-bridge) 3103. [Configure OnionBalance Correctly](#using-onionbalance) 3114. [Monitor Your Service](#monitor-your-service) 312 313## Have Good Opsec 314 315Before worrying about any of these advanced attacks on the Tor network, you 316should make sure that your onion service is not leaking basic info via the 317application layer, or by allowing connections outside of Tor. 318 319For information about how to do this, you should have a look at the [Riseup Onion Services Best Practices document](https://riseup.net/en/security/network-security/tor/onionservices-best-practices). 320 321## Use Bridges or Run a Relay or Bridge 322 323Tor has only basic defenses against traffic analysis at the moment. We are 324working on more, but in the meantime, using a bridge or running a relay or 325bridge can provide some additional protection against traffic analysis 326performed by local and global adversaries. 327 328Bridges can help conceal the fact that you are connecting to the Tor network. 329If you use a bridge address that is not known to the adversary, both the local 330and global adversaries will have a harder time performing their attacks. 331 332Running a relay or bridge with your service can help the traffic patterns of 333your service blend in with the rest of the Tor network, but this is tricky to 334set up correctly, and you must take additional steps to decorrelate your 335service uptime from your relay uptime. 336 337### The Best Way To Use Bridges 338 339Right now, the best bridge protocol to use is obfs4, because it has additional 340traffic analysis obfuscation techniques that make it harder for the local and 341global adversaries to use bandwidth side channels and other traffic 342characteristics. 343 344To use obfs4, obtain two bridges from 345[bridges.torproject.org](https://bridges.torproject.org/bridges?transport=obfs4) 346and add them to your torrc like so: 347 348``` 349UseBridges 1 350Bridge obfs4 85.17.30.79:443 FC259A04A328A07FED1413E9FC6526530D9FD87A cert=RutxZlu8BtyP+y0NX7bAVD41+J/qXNhHUrKjFkRSdiBAhIHIQLhKQ2HxESAKZprn/lR3KA iat-mode=2 351Bridge obfs4 38.229.1.78:80 C8CBDB2464FC9804A69531437BCF2BE31FDD2EE4 cert=Hmyfd2ev46gGY7NoVxA9ngrPF2zCZtzskRTzoWXbxNkzeVnGFPWmrTtILRyqCTjHR+s9dg iat-mode=2 352 353ClientTransportPlugin obfs2,obfs3,obfs4,scramblesuit exec /usr/bin/obfs4proxy 354``` 355 356Note the use of the iat-mode=2 parameter. Setting iat-mode=2 (as opposed to 357iat-mode=0 or 1) causes obfs4 to inject traffic timing changes into your 358outgoing traffic, which is exactly the direction you want as a service. The 359bridge itself does not need to have the same setting. 360 361You can get that obfs4proxy binary as a debian package, or from a recent Tor 362Browser version, or [build it from source](https://gitweb.torproject.org/pluggable-transports/obfs4.git/). 363 364### The Best Way to Run Tor Relays Or Bridges With Your Service 365 366Instead of using bridges, another alternative is to use the Tor network itself 367as cover traffic for your service by running a relay or bridge. If your relay 368or bridge is used enough (especially by other onion service client and service 369traffic), this will help obscure your service's traffic. 370 371The seemingly obvious approach would be to use the same Tor process for your 372relay as you use for your onion service. This will accomplish the traffic 373blending on the same TLS connections as relayed Tor traffic. Unfortunately, 374because Tor is single threaded, your onion service activity can still cause 375stalls in the overall network activity of your relay. See 376[Ticket #16585](https://trac.torproject.org/projects/tor/ticket/16585) for the gory 377details. Worse still, if it is the same process, your Tor relay will report 378your onion service history in its read/write statistics, which result in a 379[noticeable asymmetry in these 380statistcis](https://trac.torproject.org/projects/tor/ticket/8742). 381 382However, if you run your Tor relay as a separate process on the same machine 383as your onion service Tor process, but **also** use that relay locally as a 384bridge, your onion service activity will not directly block the relay 385activity, but will still share all of its outbound TLS connections to other 386relays. For this, you would add something like the following to your onion 387service torrc: 388 389``` 390UseBridges 1 391Bridge 127.0.0.1:9001 # 9001 is the relay process's OR port. 392``` 393 394The story deepens, however. When you do this, **your onion service uptime will 395be strongly correlated to your relay uptime, and both are now very 396easily observable by client adversaries**. 397 398[OnionBalance](#using-onionbalance) is one way to address this (ie: running 399several Tor relays on different machines, each with their own OnionBalance 400Backend Instance). 401 402To look as much like a normal onion service as possible, you should use two 403Tor relays, and each on different machines in different data centers. In this 404way, your traffic will appear as an onion service that is using your two 405guards, and your onion service as a whole won't go down unless both of your 406relays are down. 407 408## Using OnionBalance 409 410[OnionBalance](https://onionbalance.readthedocs.io/en/latest/getting-started.html#architecture) 411can help protect against some forms of traffic analysis and confirmation 412attacks. It does this at the expense of more exposure to a larger number of 413local adversaries, though, and if the adversary can tell that you are using 414OnionBalance, they can counteract many of the benefits. 415 416Despite exposing you to more local adversaries, OnionBalance helps protect 417against local adversaries because they will no longer be able to observe all 418of your onion service traffic, and it is more difficult for them to impact 419your reachability for a reachability confirmation attack. 420 421Additionally, when OnionBalance is used in combination with the addon's 422bandguards component option **circ_max_megabytes**, this can help protect 423against bandwidth confirmation attacks that send high volumes of traffic to 424interesting onion services and watch for any evidence of results on a local 425internet connection. 426 427However, OnionBalance needs some tweaks to avoid giving an advantage to the 428network adversary. Because multiple instances of the vanguards addon do not 429communicate through OnionBalance, each additional instance of the vanguards 430addon will choose different layer2 and layer3 guards. These additional layer2 431and layer3 guards increase the overall exposure to guard discovery attacks. In 432cases where it is just as bad for the adversary to discover any of your onion 433service instances as it is to discover all of them, then obviously each 434additional instance lowers your security a bit. 435 436### How to OnionBalance 437 438To attempt to conceal the fact that you are using OnionBalance, you want your 439OnionBalance service to produce descriptors with similar numbers of 440introduction points as normal services. Normal services typically have between 4413 and 7 introduction points. This means you should set the OnionBalance 442setting **MAX_INTRO_POINTS=7**, and also set **DISTINCT_DESCRIPTORS=False**, 443to prevent it from generating multiple descriptors. 444 445To keep your layer2 and layer3 vanguards in sync between your OnionBalance 446Management Server and the backend instances, first run vanguards on your 447Management Server. 448 449Then, once per hour, copy the **vanguards.state** file from your OnionBalance 450Management Server to each of your Backend Instances, via tor+scp or some other 451secure mechanism. (The UNIX crontab program is a good way to do this copy 452hourly). 453 454When each Backend Instance gets this copied statefile (let's call it 455**mgmt-vanguards.state**), it should run 456``` 457 ./src/vanguards.py --one_shot_vanguards --state mgmt-vanguards.state 458``` 459 460This will cause the Backend Instance to update its tor settings with the same 461layer2 and layer3 guard information as on the management side. It does not 462matter if your Backend Instances cannot write to their torrc files. The 463settings will still be updated. 464 465Then, to benefit from the other defenses, each Backend Instance should run a 466separate vanguards process with a different state file, but with vanguards 467itself disabled. This is done with something like: 468``` 469 ./src/vanguards.py --disable_vanguards --state backend-vanguards.state 470``` 471 472These backend instances will then still monitor and react to bandwidth side 473channel attacks and Rendezvous Point overuse, while still using the same 474layer2 and layer3 guards as your Management Server. 475 476## Monitor Your Service 477 478As we discussed above, confirmation attacks can be performed by local and 479global adversaries that block your access to Tor (or kill your Tor 480connections) to **confirm** if this impacts the reachability of a suspect hidden 481service or not. This is a good reason to monitor your onion service reachability very 482closely with monitoring software like [Nagios](https://www.nagios.org/) or 483[Munin](http://munin-monitoring.org/). 484 485If you use OnionBalance, you need to monitor the ability of each of your 486Backend Instances to connect to Tor and receive connections to their unique 487backend onion service addresses. If the adversary **suspects** that you are 488using OnionBalance, they can perform reachability confirmation attacks against 489the specific backend instances, so monitoring their uptime is a wise move. 490 491If you use bridges or run relays, you should monitor their uptime as well, and 492replace them immediately if they go down. 493 494The vanguards addon also emits WARN messages when it detects that you have lost 495connectivity to the Tor network, or when you still have connectivity to the Tor 496network, but you are unable to build circuits. It also emits NOTICE messages 497if any connections were forcibly closed while they had active circuits on them. 498 499You should add the output of the vanguards addon to your monitoring 500infrastructure for this reason (in addition to watching for evidence of 501the other attacks the addon detects). 502