Announcing the Vanguards Add-On for Onion Services
An Intro to Onion Service Security
Earlier this year, the Tor Project released its first stable Tor and Tor Browser releases with the new v3 onion service protocol. The protocol features many improvements, including longer and more secure onion addresses, service enumeration resistance, improved authentication, and upgraded cryptography.
However, while this new protocol closes off some attacks (particularly enumeration and related targeted DoS attacks), it does not solve any attacks that could lead to service deanonymization.
We believe that the most serious threat that v3 onion services currently face is guard discovery. A guard discovery attack enables an adversary to determine the guard node(s) that are in use by a Tor client and/or Tor onion service. Once the guard node is known, traffic analysis attacks that can deanonymize an onion service (or onion service user) become easier.
The most basic form of this attack is to make many connections to a Tor onion service, in order to force it to create circuits until one of the adversary's nodes is chosen for the middle hop next to the guard. That is possible because middle hops for rendezvous circuits are picked from the set of all relays:
A traffic analysis side channel can be used to confirm that the malicious node is in fact part of the rendezvous circuit, leading to the discovery of that onion service's guard node. From that point, the guard node can be compromised, coerced, or surveilled to determine the actual IP address of the onion service or client.
The Vanguards Control Port Add-On
Fixing the guard discovery problem in Tor itself is an immense project -- primarily because it involves many trade-offs between performance and scalability versus path security, which makes it very hard to pick good defaults for every onion service.
Because of this, we have created an add-on that can be used in conjunction with a Tor onion service server or a Tor client that accesses Tor onion services.
The add-on uses our Control Port Protocol and the corresponding Stem Library to defend against these attacks. The hope is that it will we will be able to study the performance and functionality of this feature and gather feedback before we deploy these changes in Tor for all onion services and clients.
Vanguards, Bandguards, and a Rendguard, oh my!
Our add-on has three components:
The core functionality is provided by the Vanguards component which implements the Mesh Vanguards (Proposal 292). This ensures that all onion service circuits are restricted to a set of second and third layer guards, which have randomized rotation times as defined in that proposal. Basically, now all the hops of onion service circuits are pinned to specific nodes instead of sampling random ones from the whole network every time.
This change to fixed nodes for the second and third layer guards is designed to force the adversary to have to run many more nodes, and to execute both an active sybil attack, as well as a node compromise attack. In particular, the addition of second layer guard nodes means that the adversary goes from being able to discover your guard in minutes by running just one middle node, to requiring them to sustain the attack for weeks or even months, even if they run 5% of the network.
The analysis behind our choice for the number of guards at each layer, and for rotation duration parameters is available on GitHub. Here is how our current vanguard 2-3-8 topology looks like:
Furthermore, to better protect the identity of these new pinned guard nodes the circuit lengths have been altered for rendezous point circuits, hidden service directory circuits, and introduction point circuits. You can see them here (where L1 is the first layer guard, L2 is second layer guard, L3 is third layer guard, M is random middle):
Additionally, the Bandguards component of the add-on also checks for evidence of bandwidth side channel attacks, which may be used by the adversary to aid/amplify traffic analysis attacks.
When these attacks are detected, the circuit is (optionally) closed.
Note that the Bandguards component also closes any circuit older than 24 hours (the `circ_max_age_hours` setting), and has an option (off-by-default) to close circuits that transmit more than a certain number of megabytes (the `circ_max_megabytes` option).
If your service requires large file uploads, or very long-lived circuits, set these options to 0 in your vanguards.conf.
Finally, the Rendguards component of the add-on performs analysis on the prevalence of rendezvous points on the onion service side. The rendezvous point is chosen by the client when it connects to an onion service, and some attacks rely on the use of a malicious rendezvous point to aid in traffic analysis.
This component tracks the frequency of rendezvous point use, and when it finds overuse, it optionally closes circuits from that rendezvous point and emits a log message.
Each of these components is configurable. Please see the README for more information.
Requirements, Installation, Usage, and Caveats
The Vanguards add-on is primarily for high-risk onion service operators at this point. In order for the Bandguards side channel detection features to be enabled, Tor 0.3.4.4 or above is required, but the script will run with Tor 0.3.3.x+. Earlier Tors do not have sufficient Control Port support for the script, however.
Additionally, while they have been thoroughly tested by us, the parameters for the various detection mechanisms of the Bandguards and Rendgaurd components are still experimental and may need fine tuning for your service or scenario, especially if it differs from our testing environment.
If you notice log messages or alarms from these components, it does not necessarily mean that you are under attack. If you can, please report frequent log messages to the GitHub issue tracker.
Thank you and let us know if you have any questions or concerns! :)
That's correct. It is also the same trade-off we made when first deploying Guard nodes very early in Tor's history.
For onion services, the key thing that makes this worthwhile is that the adversary gets to force you to create as many circuits as they like, by continuously connecting to you. So if you are actually under attack, it is strictly better to use restricted second and third layer guards that rotate slower than your circuit creation.
For onion clients, it is a bit more fuzzy since it is harder to get them to build lots of circuits. But, if the adversary only controls a small percentage of the network, you're still more likely to get lucky than be SOL right away, as you say.
Not exactly the same tradeoff. Guards obtain their status flag by relaying massive amounts of data compared to relay-only. To have made a single poor choice of guard is not immediately a failure of the network goal since guards which do not serve their purpose lose the status. It may be easy for a adversarial to perform some analysis, but a surveilled guard is not as vulnerable.
So here you have a trade off explicitly for onion services to mitigate the number of connections being abused to identify ips of possible interest. I'd admit it would be a hard choice except that onion services that want to stay anonymous should be trying to blend in with other clients in the first place. They could do this by choosing guards that service many requests but that won't stop the issue of paramount concern; as you mentioned.
Why doesn't the guard recognize that *any* deviance in number of concurrent connections from possible client behavior *is* a threat. It doesn't matter if it's a client or onion service. Could not the guard throttle concurrent connections and total bandwidth to a "client" as a defensive measure? It sounds like a sacrifice but the services that count on it probably don't want to stand out. mtc.
Deploying a defense at the guard node against dos/circuit churn attacks against services isn't really feasible because the guard node can't tell if the service is actually under attack or just suddenly popular.
I thought about adding configurable rate limits on the total number of circuits before sounding some sort of alarm in this vanguards addon, but even that is iffy. Even a quiet service can suddenly get a lot of unexpected attention if it goes viral.
Plus, any sort of limits like this are inherently DoS vectors to take down a service.
I'm talking about those situations (suddenly popular==measurably bad), so the extra attention you describe is undoubtedly an attack vector against the onion service in active exploitation (or client doing something reckless). (and in the case of the service is having to be mitigated at the client when it's too late) The design proposed benefits adversarial nodes the most as they stand to gain from the status-quo the current design offers. Suppose you can say with some certainty the guards chosen are non-adversarial. Then adversarial nodes stand to benefit from these non-adversarial becoming more associated/connected, more nodes to target, and a way to shift network topology to an adversarial benefit.
Now suppose worse case for an onion service trying as I describe to not stand out. By enforcing the behavior at the guard, these "clients" all look relatively similar, and deprives the successful adversary of benefit. Those who are expected to be targeting these onion services can only succeed if they also simultaneously own multiple guards (perhaps being used to scale).
It would slow down the service, but if the operator sees that warning, continues for whatever reason, then they likely need the service for support. I would be recreating the onion address. So slower is okay, clear warnings okay too. The adversary also needs to experience the churn, and by deflecting at the guard no benefit is gained from surveilling a single non-adversarial guard.
I do see what you mean about the proposed design helping those onion services where suddenly popular==no problem. For some (I'd think many/most) this behavior is undesirable.
Look I dunno (non-gendered) dude.. Nodes like "being connected and stuff" is kinda vague (maybe you mean fingerprinting? search the comments of this post for that thread). As is how to have the entire network enforce an appropriate set of heuristics on how onion services get used at the guard node...
I'm a little on the yolo side myself but I still deal in science over here. To me, the tradeoffs are clear. If you do not use this addon, the adversary can find your guard in a hot minute (which is much shorter than a wall-clock minute ;), and can use a whole treasure chest of unfixed-in-core-tor attacks to confirm this, observe the guard, and then find your IP address. If you do use this addon, you are making use of the best ways we know of to slow down these attacks. Just a little bit before they go into core-tor.
But maybe you know how to yolo with the wingnut opsec better than I do. That's why it is an addon! Best of luck!
translation: it's ok for situationally adversarial nodes to exploit this design, ignoring the undesirable, to say disclose location of a network peer acting contrary to sponsor interests (oh, I don't know like to politics of copyright enforcement), versus situationally being non-adversarial when the peer *is* acting in alignment with sponsor interest (like, oh, I don't know supporting insurgency against perceived anti-competitive political structure, ie. supporting regime change)
You do realize that what you just said sounds like: a) I tried something like that to prevent abuse and failed, and b) you're clearly in opposition to situationally adversarial nodes, which by transitivity means c) you would support such a node when acting in the interest of aligned political powers and simultaneously when acting exclusively in network interest.
Not sure what to make of the rest of your comment, but all I really wanted to know was if research besides your failed attempt has been made. And whether a ticket to seriously investigate the matter exists.
But hey, if your response: The USA is great!, is actually what you meant, all the power to you. Otherwise sorry for misunderstanding.