[tor-dev] Setting NumEntryGuards=2

[George Kadianakis]

David Goulet <dgoulet at torproject.org> writes:

> [ text/plain ]
> 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.
>> >
>> 
>> <snip>
>> 
>> > 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]
>

Yep, you are right in everything here.

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

Why bad for performance? It will be the same length as currently.

> 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 think this is your main objection to this approach, and I understand
it, but I'm not sure how well-enforced this tor protocol "rule" is, or
how much we should respect it given that this is an important security
edge-case that we can solve.

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

I don't think this is true anymore, if we accept
[G1 -> M1 -> M2 -> M3 -> G1] as a reasonable solution.