Skip to content
Snippets Groups Projects

Vanguards

Last edited by Gaba

10/01/2018

16:00 -- 17:00

Session lead: Mike Perry

*** Session: Vanguards ***

** Background **

  • Vanguards prevent guard discovery by giving guards to guards (i.e. using layers of guards)
  • Layers of guards forces the adversary to do multiple attacks: (1) Sybil attack to be chosen in the fast-rotating position far from the client, and (2) compromise once guards closer to client are discovered

** Progress since 3/2018 **

  • To test this idea, it has been prototyped through the control port
  • Blog post described this progress: https://blog.torproject.org/announcing-vanguards-add-onion-services
  • Current prototype (aka add-on):
    • 2 (normal) entry guards to Tor (uniformly random once placed in the set)
    • 3 second-layer guards with rotation time of 30-45 days (uniformly random once placed into the set)
    • 8 third-layer guards with rotation time of ~2 days (uniformly random once placed into the set)
    • Any guard/vanguard in a given layer can connect in circuit to any vanguard in a successive layer
    • Repository: https://github.com/mikeperry-tor/vanguards
    • Clients choose (i.e. opt-in) to using vanguards, primarily intended initially for onion services
    • Also, checks for biased Rendezvous Point (RP) selection by comparing frequency of RPs to their weights in the consensus. By default, when such an RP is identified, it closes the connection to the RP and informs the user.
    • Furthermore, checks for side-channel attacks by comparing cell counts received from Tor processing to cell count received by Tor. By default, when such a circuit is flagged, it closes the circuit.
    • In addition, checks length of hidden-service descriptors, and if too many bytes are ignored during descriptor parsing, HS circuit is closed.
    • Provides off-by-default option that limits the number of bytes on an HS (hidden service) circuit to limit bandwidth-history guard-discovery attack. If limit is exceeded, circuit is closed.
    • A couple more possible checks: (1) close a circuit after a maximum lifespan. (2) Connectivity to Tor is monitored, and user is notified if guard won't build circuits, if TCP connections close with live circuits on them, or if TCP connections to guards can't be made.
  • Question: What is the vision for this feature, which currently requires opt-in and sophistication from the user. Answer: Developing the add-on allowed us to test and develop the various heuristic attack-detection checks to make sure they aren't triggered during normal operation of the network. In addition, implementing specific defenses allows us to make the ideas concrete for the research community to respond with their own attacks and analysis.
  • Question: Have you seen warning from the attack-detection checks? Answer: No, but it doesn't appear that it was an actual attack.
  • Question: Is anybody else using the plug-in? Answer: At least one person.
  • Question: Would the modifications in Tor Browser inherently require user interaction? Answer: It does work fine with Tor Browser under some configurations - the drop-cell attack can be applied to normal exit traffic (a demonstrated attack). There is a race condition with closing the circuit on the early-drop-cells check, which is that the circuit teardown happens asynchronously and could allow some signal to be propagated via (dropped) cells before the circuit gets closed.
  • Question: Would you recommend regular (i.e. non-onion) clients using vanguards? Answer: It could benefit clients, who can suffer from guard-discovery attacks.
  • Question: Have you tried running the side-channel attacks? Attacks: No, but I have been talking with a researcher (Florentin Rochet) who ran some of them.
  • Question: How does this affect performance? Answer: We wanted to analyze this with OnionPerf. Our main concern was bandwidth availability in the second layer (we were deciding between 3 and 4 relays in the layer). Circuit build timeouts are still used to avoid using very bad relays in a given layer.
  • Question: Isn't a group a high-capacity onion services going to change the load-balancing characteristics of the network? Answer: Yes. Also, high-capacity onion services may want to change the size of their layers.
  • Question: Why not roll this out for onion services now? Answer: Performance concerns, especially for high-capacity onion services. There is also some risk of guard nodes recognizing the use of vanguards.
  • Question: The purpose of this defense is to prevent guard discovery. It seems as if it's easier to run a denial-of-service attacks on onion services at the third guard layer. Answer: It's only easier to do denial-of-service attacks without vanguards (by attacking the guards themselves). Also, defending against denial of service isn't the only goal of vanguards. Its primary goal is to avoid deanonymization by identifying and then compromising the guard. Adding layers makes it harder for large organizations to successfully compromise any single relay (because the value of compromising it is lower).
  • Suggestion: guard discovery of exit circuits is important too because of traffic analysis of the guard. Response: Yes, although perhaps we could handle client guard-discovery attacks by reducing the ability of an adversary to cause many circuits to be created instead of adding vanguards.
  • Question: You have suggested many things that researchers can do to validate and tune parameters. What would be the Minimum Viable Product to deploy this? What is the short list of questions that must be answered? Answer: Go to the github page, which has a README explaining how it works and a README.security explaining the threat modeling. A main barrier to deployment is getting friendly people running onion services to enable to app and give us feedback on how it performs. With positive results in practice, we could merge this into Tor, still on an opt-in basis. Turning on vanguards by default would probably require having higher confidence in any resulting performance impacts. Shadow experiments seem like they could be sufficiently convincing for this purpose. The drop-cell attack check should be validated by showing that the attack no longer work with the defense applied.
  • Question: Is the add-on designed to automatically provide the metrics that are needed to validate the success of its deployment? Answer: The add-on doesn't gather this kind of data (performance data, at least). We could bundle it with OnionPerf to gather performance statistics simultaneously with the vanguard deployment.
  • Question: Is there interest in adding guard sets to vanguards? Answer: There seem to be open research issues to make the guard-set idea more fully complete and secure.
  • Question: What about the issue with path-selection restrictions? Node-family restrictions on the circuit can cause information to leak by observing how last-layer relays are selected. Answer: We disabled all family/subnet restrictions when using vanguards. We can also deal with this by requiring the use of at least two primary guards. Proposal 291 discusses this issue and provides a general approach to handling it.
  • Question: How does circuit-construction work is there is a family/subnet restriction with the RP? Answer: The conflict is ignored with vanguards. Actually, even the same node is allowed to be used on the circuit and as the RP.

Comments

    Please register or sign in to add a comment.