David Goulet dgoulet@torproject.org writes:
[ text/plain ] On 22 Mar (13:46:36), George Kadianakis wrote:
Mike Perry mikeperry@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-paramete... 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:
- 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.