[HOME] [DOWNLOAD] [DOCS] [NEWS] [SUPPORT] [TIPS] [ISSUES] [CONTRIBUTE] [DONATE]

vanguards - Additional protections for Tor Onion Services

Todo research:

Tor version deb.torproject.org (Whonix uses) vs packages.debian.org vanguards version mismatch?

Sane for installation by default?

Vanguards available from deb.torproject.org?

https://blog.torproject.org/announcing-vanguards-add-onion-services

1 Like

When we know where to set it up, sure - no probs.

2 Likes

@Patrick My guess is on the GW?

Yes.

This looks easy to add by default. Doesn’t look very error prone and would be a good enhancement.

No.

Asked.
OK got mix vanguards from packages.debian.org with Tor from deb.torproject.org repository?
https://lists.torproject.org/pipermail/tor-dev/2020-January/014118.html


1 Like
1 Like

enable vanguards systemd unit file by default
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=948975

1 Like
1 Like
1 Like

According to Mike Perry we should stick to the defaults as far as layer 2 guards are concerned and not enable circ_max_megabytes because it will silently interfere with file transfers essentially breaking them.

https://lists.torproject.org/pipermail/tor-dev/2020-January/014134.html

A user ticket on Github shows you must anticipate the number of bytes to transfer beforehand with circ_max_megabytes. This is impractical.

1 Like

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=948975#10

Hi,

This is a deliberate choice that we have made, as there is no reason to
use vanguards unless onion services are being hosted. If vanguards gets
installed accidentally then it can have confusing effects for users. It
is better to explicitly enable it.

Thanks,
Iain.


This is a deliberate choice that we have made, as there is no reason to use vanguards unless onion services are being hosted.

Is that so?

If vanguards gets installed accidentally then it can have confusing effects for users. It is better to explicitly enable it.

Strange because the usual Debian way is to start services by default.

1 Like

They have no idea it protects clients too…
It doesn’t affect users unless explicitly enabled in torrc.

1 Like

Any authoritative, quoteable references for that? Then I could tell them and get this fixed in Debian. Thereby no workaround on the Whonix level required anymore in future.

I don’t think so. Just needs ControlSocket which is default in Debian nowadays too. The only other issue which doesn’t make this work out of the box on Debian is this vanuards config file change:

1 Like

Yes here:

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.

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.

https://blog.torproject.org/announcing-vanguards-add-onion-services

1 Like

Awesome! Added to bug report: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=948975#15

1 Like

FYI re: Proposal 332 (Vanguards lite). When this is implemented it looks like it will exist alongside the standard Vanguards option. That means thinking is required about which one will be better for general Whonix users.

[tor-dev] [RFC] Proposal 332: Vanguards lite

[tor-dev] [RFC] Proposal 332: Vanguards lite

Filename: 332-vanguards-lite.md
Title: Vanguards lite
Author: George Kadianakis, Mike Perry
Created: 2021-05-20
Status: Draft


# 0. Introduction & Motivation

This proposal specifies a simplified version of Proposal 292 "Mesh-based vanguards" for the purposes of implementing it directly into the C Tor codebase.

For more details on guard discovery attacks and how vanguards defend against it, we refer to Proposal 292 [PROP292_REF].

# 1. Overview

We propose an identical system to the Mesh-based Vanguards from proposal 292, but with the following differences:

  - No third layer of guards is used.
  - The Layer2 lifetime uses the max(x,x) distribution with a minimum of one day and maximum of 12 days. This makes the average lifetime approximately a week. We let NUM_LAYER2_GUARDS=4.
  - We don't write guards on disk. This means that the guard topology resets when tor restarts.

By avoiding a third-layer of guards we reduce the linkability issues
of Proposal 292, which means that we don't have to add an extra hop on top of our paths. This simplifies engineering.

# 2. Rotation Period Analysis

From the table in Section 3.1 of Proposal 292, with NUM_LAYER2_GUARDS=4 it can be seen that this means that the Sybil attack on Layer2 will complete with 50% chance in 18*7 days (126 days) for the 1% adversary, 4*7 days (one month) for the 5% adversary, and 2*7 days (two weeks) for the 10% adversary.

# 3. Tradeoffs from Proposal 292

This proposal has several advantages over Proposal 292:

By avoiding a third-layer of guards we reduce the linkability issues of
Proposal 292, which means that we don't have to add an extra hop on top of our paths. This simplifies engineering and makes paths shorter by default: this means less latency and quicker page load times.

This proposal also comes with disadvantages:

The lack of third-layer guards makes it easier to launch guard discovery attacks against clients and onion services. Long-lived services are not well protected, and this proposal might provide those services with a false sense of security. Such services should still use the vanguards addon [VANGUARDS_REF].

# 4. References

[PROP292_REF]: https://gitlab.torproject.org/tpo/core/torspec/-/blob/main/proposals/292-mesh-vanguards.txt
[VANGUARDS_REF]: https://github.com/mikeperry-tor/vanguards
2 Likes

It seems the Vanguard lite proposal is a tradeoff against security to increase performance and so there’s no need to swtich to it as a default. However it may be useful for users with high perf reqs to know about it in the documentation.

1 Like

It will also depend on if vanguards will continue to be maintained. I guess that will be our main point of focus. If vanguards is deprecated then we necessarily must switch to vanguards lite.

Low accuracy statement:
Perhaps vanguards will keep being the go-to tool for advanced anonymity.

Maybe the newest/best defenses are only being implemented in vanguards before these features are backported to Tor core (vanguards lite) with restraints on technical implementation feasibility. Time will tell.

1 Like
[Imprint] [Privacy Policy] [Cookie Policy] [Terms of Use] [E-Sign Consent] [DMCA] [Contributors] [Investors] [Priority Support] [Professional Support]