David Goulet <dgou...@torproject.org> writes: > [ text/plain ] > On 22 Mar (13:46:36), George Kadianakis wrote: >> Mike Perry <mikepe...@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. _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev