Announcing Vanguards Support in Arti
![](lead.png)
As of version 1.2.2, Arti supports Vanguards, a defense against guard discovery attacks targeting onion services and onion service clients. First introduced in 2018 as an add-on to v3 onion services, Vanguards serve to mitigate the risk of de-anonymization attacks.
Why
A guard discovery attack reveals the guard relays of a onion service or client to the attacker. While this does not, in and of itself, deanonymize the victim, it does make it easier to launch traffic analysis attacks, which can ultimately lead to deanonymization. See 'From "Onion Not Found" to Guard Discovery' and section VI of 'Trawling for Tor Hidden Services: Detection, Measurement, Deanonymization' for more on guard discovery attacks.
To defend against this type of attack, Arti now uses additional layers of guards, called vanguards, when building onion service circuits.
Before Vanguards, Arti would build these circuits by randomly selecting the second and third hops from the set of all relays. Now, the second and third hops are selected from restricted subsets of relays, called the L2 and L3 vanguard sets, respectively. By pinning the second and third hops for a period of time, we make guard discovery attacks significantly more costly to perform successfully.
Arti's Vanguards implementation is based on the research behind Tor's Vanguards add-on, and offers similar protections to its Vanguards component. The other experimental defenses from the add-on are not yet implemented in Arti (but they are on our roadmap!)
Who is this for?
If you are using Arti to connect to onion services, or if you are running an
Arti onion service, this change affects you. In particular, if you are running
a long-running onion service and would like to harden it against guard
discovery attacks, we recommend you read on. If you are not interested in the
nitty-gritty of the new subsystem, you can skip over to the Usage
section
below.
Lite or Full vanguards?
Arti's Vanguards subsystem supports two mutually exclusive modes of operation:
- Lite, for clients and short-lived onion services
- Full, for onion services with high uptimes (longer than one month)
Full vanguards provide better security than lite vanguards, but come with a performance cost: circuits using full vanguards have an additional hop, and will therefore have higher latency than those built using lite vanguards.
Lite vanguards
With lite vanguards, the second hop of every onion service circuit is selected from the L2 vanguard set. The third hop is selected as before, by randomly choosing a relay that can serve as a middle relay:
Client hsdir: C - G - L2 - M - HSDir
Client intro: C - G - L2 - M - Intro
Client rend: C - G - L2 - Rend
Service hsdir: S - G - L2 - M - HSDir
Service intro: S - G - L2 - M - Intro
Service rend: S - G - L2 - M - Rend
where L2
is a second-layer vanguard, and M
is a randomly selected middle
relay.
The L2 vanguard set is ephemeral (it is not preserved across process restarts).
Full vanguards
In addition to using L2 vanguards, circuits with Full vanguards also use an L3 vanguard as the third hop. Moreover, onion service circuits where the target might be controlled by an adversary are extended by an additional middle relay, sampled from the set of all relays:
Client hsdir: C - G - L2 - L3 - M - HsDir
Client intro: C - G - L2 - L3 - M - Intro
Client rend: C - G - L2 - L3 - Rend
Service hsdir: S - G - L2 - L3 - HsDir
Service intro: S - G - L2 - L3 - Intro
Service rend: S - G - L2 - L3 - M - Rend
where L2 and L3 are second- and third-layer vanguards, respectively,
and M
is a randomly selected middle relay.
The L2 and L3 vanguard sets are written to disk, and thus are preserved across restarts.
Vanguard lifetimes
The L2 and L3 vanguard sets are built by randomly selecting a fixed number of
relays that have the Fast
, Stable
, and Valid
flags. We select 4 relays for
the L2 set, and 8 for the L3 one.
Each vanguard is assigned a random lifetime from the max(X, X)
distribution,
where X
is a uniform random value between the minimum and maximum vanguard
lifetimes specified in the consensus (we use the max(X, X)
distribution to
introduce a bias towards longer lifetimes). Vanguards are rotated when their
lifetime expires.
The lifetime of an L2 vanguard is between 1 and 12 days, whereas L3 vanguards have a much shorter lifetime (between 1 and 48 hours). This short lifetime aims to deter adversaries from attempting to compromise the L3 vanguards: by the time the attack succeeds, there is a high chance the vanguards will have already been rotated. In other words, the lifetime was chosen so that the only feasible way to control the third hop in the victim's circuit is through a Sybil attack. In contrast, a successful Sybil attack against the second layer would take a very long time. For more about our threat model, see the vanguards specification.
Relaxed path building restrictions
When vanguards are enabled, we relax some of the path building restrictions that would otherwise be enforced. For instance, same-family and same-subnet restrictions do not apply, and the last hop of a circuit is allowed to be the same as the first.
The relaxed restrictions prevent attackers from, for example, finding out the
guard of a onion service by successively using each relay with the Guard
flag
as a rendezvous point, and checking which of them the service consistently fails
to connect to.
Usage
Vanguards are enabled by default in Arti since version 1.2.2. However, a number of security issues affecting vanguards were discovered in Arti 1.2.2, 1.2.3, and 1.2.4, so we strongly recommend running a version no older than 1.2.5.
By default, Arti uses lite vanguards for all onion service circuits. We recommend most users stick with the provided defaults. However, if you are running a long-lived onion service (with an uptime exceeding one month), we recommend using full vanguards instead.
You can enable full vanguards by setting vanguards.mode
in your TOML config:
[vanguards] mode = "full"
or via the command-line, using
arti proxy -o=vanguards.mode=full
While we do not recommend disabling vanguards, you can do so by setting
vanguards.mode
to disabled
.
Choice of parameters
The vanguard set sizes and the vanguard lifetime bounds are read from the
consensus. Like other consensus parameters, the vanguard parameters can be
overriden in Arti using the override_net_params
configuration option.
Important: overriding these parameters could compromise your anonymity, so
proceed with caution.
See George Kadianakis' experiments with various vanguard topologies and the statistical analysis from the vanguards specification for more details.
Thanks to everybody who's contributed to Arti over the years!
Also, our deep thanks to Zcash Community Grants, the Bureau of Democracy, Human Rights and Labor, and our other sponsors for funding the development of Arti!
Comments
We encourage respectful, on-topic comments. Comments that violate our Code of Conduct will be deleted. Off-topic comments may be deleted at the discretion of the moderators. Please do not comment as a way to receive support or to report bugs on a post unrelated to a release. If you are looking for support, please see our FAQ, user support forum or ways to get in touch with us.