George Kadianakis:
David Goulet dgoulet@torproject.org writes:
On 22 Mar (13:46:36), George Kadianakis wrote:
Mike Perry mikeperry@torproject.org writes:
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.
Even if we allow this case, we still run up against other path restrictions that enable the adversary to force the same new connection behavior though. If we allow the same guard in multiple points in the same circuit, new connections can be forced for the case where the RP is in the same /16 or same family as the guard. This is not the same level of info, but I still believe that the ability to force a new entry connection is an extremely bad property. We can only avoid that by abandoning all circuit restrictions for the RP/exit, or by having two guards.
I feel vaguely uncomfortable abandoning all of Tor's path restrictions for certain circuits, but I don't have a good argument against doing that.
However, given the other benefits from having two dedicated guards (especially traffic analysis and DoS resistance from conflux, but also performance), I do believe that always using two guards is clearly and strictly better than only using two guards for special cases that can be adversarially controlled.