[tor-dev] Setting NumEntryGuards=2

Thu Mar 22 14:07:43 UTC 2018

On 22 Mar (13:46:36), George Kadianakis wrote:
> 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)

For hidden service, I think you meant [G1 -> M1 -> M2 -> *G1*] considering
that G1 is the chosen RP. But also, I think my comment was very wrong 3 years
ago, a service already builds a 4 hops to the RP so it should then be this in
your example?: [G1 -> M1 -> M2 -> M3 -> G1]

This makes it VERY easy for a Guard node to learn that it is the guard of a
specific .onion but considering an evil guard of a .onion, there are other
effective methods to learn it so I'm not convinced that this path will be
worst, just maybe bad for performance.

But also this would violate tor protocol of "never having the same hop in the
path" so overall making an exeception for this makes me worry a bit :S.

I do agree with Mike on this one that we don't get benefit here from 1 to 2
because the code right now is basically a two guard system where the second
guard is used rarely. Not only that but an attacker can force you to use that
second Guard at will.

> 
> > 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.

Agree with George here. I think 1 or 2 Guards here won't matter much in this
attack as mentionned where Alice can just keep injecting traffic pattern on
both Guards for identification at the netflow records level.

> 
> > 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.

I'm a bit undecided on this whole switch to 2 Guards for now. For hidden
service, there is probably a slight positive gain I would say that is using
"equally" two guards instead of the second one being used rarely and on
command by the client.

I'm not convinced about the security arguments but rather the Guard congestion
argument makes more sense for me. And this at the expense of exposing regular
clients to more Guards.

Although, the "changing Internet" problem is an important one for which I
wonder if it could be fixed with its own solution instead of moving to 2
guards at large.

Tough call....

Thanks!
David

-- 
hgJe5VGAkZPnC/W4iPXnCuf1HcG2evYQqVjeb8Ugb4Y=
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20180322/e528463d/attachment.sig>