[tor-dev] Setting NumEntryGuards=2

[George Kadianakis]

Mike Perry <mikeperry at torproject.org> writes:

> [ text/plain ]
> Back in 2014, Tor moved from three guard nodes to one guard node:
> https://blog.torproject.org/improving-tors-anonymity-changing-guard-parameters
> https://trac.torproject.org/projects/tor/ticket/12206
>
> We made this change primarily to limit points of observability of entry
> into the Tor network for clients and onion services, as well as to
> reduce the ability of an adversary to track clients as they move from
> one internet connection to another by their choice of guards.
>
> At the time, I was in favor of two entry guards but did not have a
> strong preference, and we ended up choosing one guard. After seeing
> various consequences of using only one entry guard, I think a much
> stronger case can now be made for bumping back up to two.
>

Hello Mike,

thanks for writing this post. Thinking about entry guards is extremely
important since guards and path selection is pretty much the whole
security of Tor.

However we should think hard here before flapping from one conf to
another.  In the grand scheme of things, I see the positives of moving
to two guards but also the positives of staying with one guard; I think
we need more data to decide what's best and for which threat models.

In general, the main argument for me to stay with one guard is to
minimize client exposure to guards over a period of time. If we choose
two guards instead of one, clients will expose themselves to double the
amount of guards over time (not to take into account flaky unreachable
guards). Perhaps we could compensate that by increasing the lifetime of
guards if we switch to two guards... I think simulations and graphs here
to show exposure of guards per number of guards would be useful, and we
have some of those already for prop247.

OTOH the main arguments for me to switch to two guards is not so much
security but performance improvements and reducing congestion of guard
nodes.

> Roger suggested that I enumerate the pros and cons of this increase on
> this mailing list, so we can discuss and consider this switch. So here
> is my attempt at that list. Let's start with a more in-depth recap of
> the one-guard arguments, along with some recent observations that change
> things.
>
>
> Arguments for staying with just one guard:
>
> 1. One guard means less observability.
>
> As Roger put it in the above blog post: "I think the analysis of the
> network-level adversary in Aaron's paper is the strongest argument for
> restricting the variety of Internet paths that traffic takes between the
> Tor client and the Tor network."
> http://freehaven.net/anonbib/#ccs2013-usersrouted
>
> Unfortunately, we have since learned that Tor's path selection has the
> effect of giving the adversary the ability to generate at least one
> additional observation path. We first became aware of this in
> https://trac.torproject.org/projects/tor/ticket/14917, where the change
> to one guard allowed an adversary to discover your guard by choosing it
> as a rendezvous point and observing the circuit failure. After the fix
> for #14917, the onion service will build a connection to a second guard
> that it keeps in reserve. By using this attack (as well as a similar but
> more involved attack with unique exit policies and carefully chosen /16
> exit node subnets), the adversary can force clients to be observed over
> two paths whenever they like.
>
> So while we may get benefit for moving from three guards to two guards,
> we don't get much (or any) benefit from moving to two guards to one
> guard against an active adversary that either connects to onion
> services, or serves content to clients and runs exits.
>

Hmm, that's a fair point. However, the fact that this behavior exists
currently does not mean that it's the best we can do with what we have.

Example of what we can do to stop this bad behavior: instead of using
our second guard when our "exit" conflicts with our first guard like
this: [G2 -> M1 -> G1], we could instead make a 4-hop circuit as
follows: [G1 -> M1 -> M2 -> G2]. This would stop us from using our
second guard and would hide the obvious signal you are worrying about.
(I see that dgoulet also suggested that in the ticket comment:7)

> 2. Guard fingerprintability is lower with one guard
>
> An adversary who is watching netflow connection records for an entire
> area is able to track users as they move from internet connection to
> internet connection through the degree of uniqueness of their guard
> choice. There is much less information in two guards than three, but
> still significantly more than with one guard:
> https://trac.torproject.org/projects/tor/ticket/9273#comment:3
>
> But, even with one guard, if there are not very many Tor users in your
> area, you still may be trackable. "Guard bucket" designs are discussed
> on the blog post and in related tickets, but they are complicated and
> involve tricky tradeoffs (see
> https://trac.torproject.org/projects/tor/ticket/9273#comment:4). The
> best solution that I see to this is to make Tor maintain separate guard
> choices depending on the current SSID, BSSID, or default gateway router
> MAC from ARP. The default gateway ARP MAC is probably easiest for us to
> implement cross-platform and stable across wifi to ethernet.
>

Agreed. I don't think guard fingerprintability was ever a serious
argument for switching to a single guard node.

>
> Arguments in favor of switching to two entry guards:
>
> 1. One guard allows course-grained netflow confirmation attacks
>
> The counterargument based on #14917 above also has an additional
> wrinkle: an adversary watching a suspect list of clients can easily
> observe the "temporarily use a second guard" activity using just
> connection-level ISP/AS netflow logs. To a large-scale netflow
> adversary, the use of a second guard only when the guard is chosen as
> the RP confirms not only guard choice, but the IP address of the onion
> service itself.
>

Devil's advocate: I'm not sure how big the suspect list we are thinking
about is, or what kind of threat models we are considering here, and I
think this matters quite a bit. Because if the suspect list is not big,
and the threat models allows the attacker to cause the victim to build
circuits, then the attacker could succeed even with simple traffic
signals (or shutting down the internet) and traffic monitoring.

Also, this whole point relies on our suboptimal fix to #14917. We could
improve the situation here by doing more advanced fix like the one
suggested above.

> Again, similar attacks may be possible against exit activity via
> cleverly crafted exit policies and /16 subnet choice. (Aside: if we
> allow routers to join any family they like without reciprocation, this
> attack becomes worse.)
>
> Having a dedicated second guard that is always in use will prevent the
> creation and exclusive use of a new TLS connection just for this
> request. Instead, the two TLS connections will both remain open and in
> regular use as long as the client is active.
>
> 2. More than one guard allows us to deploy conflux.
>
> As mentioned in the blog post, moving to one guard prevents us from
> deploying conflux -- a research design that improves Tor performance by
> combining two or more circuits together at an exit node or rendezvous
> point and load balancing between them:
> https://www.cypherpunks.ca/~iang/pubs/conflux-pets.pdf
>

I also like the conflux idea a lot but IIUC we are still very far away
from it being a reality, since the bridge from the research paper side
to the reality side is huge and unbuilt. Seems to me that toggling
NumEntryGuards from 1 to 2 is just a tiny part of the work required, and
something that could also be done after all the rest of the work gets done...

I don't see this as a major argument for switching to two guards, but
please correct me if I'm not right.