Re: [tor-talk] Tor 0.2.7.6 is released

[Roger Dingledine <arma@xxxxxxx>]

On Fri, Dec 11, 2015 at 09:29:50PM +0000, nusenu wrote:
> but most ordinary users will probably (and should) just use torbrowser
> and the tor version that comes with it (so we might see an update there
> soon?)

Right. I hear there is a regularly scheduled Tor Browser update coming
out on Tuesdayish. There won't be another (regular scheduled) one of
those until mid January or something, so this seemed like a good time
to make sure we got a new 0.2.7 release out.

> > What does "weaker anonymity" mean exactly? How big is the risk? Can this 
> > bug lead to deanonymization?
> 
> > For more information on the guard bug, see Roger's preliminary analysis
> > https://trac.torproject.org/projects/tor/ticket/17772#comment:1

Right. The bug doesn't lead to deanonymization directly, but it can make
some existing attacks more effective.

First, for background, read
https://blog.torproject.org/blog/improving-tors-anonymity-changing-guard-parameters
(I'm sorry that it's long, but this is an important topic which is not
easily summarized in a few simple sentences.)

Two of the existing attacks that I'm thinking of above are:

A) If you picked a guard and it went away the next day, you'd be forced
to pick another one. If this happened often, you'd end up "touching"
many more entry guards than you would in the ideal case where all guards
are up forever. We only assign the Guard flag to relays that tend to be
available a lot of the time, with the goal of reducing the impact from
this "natural churn". (Tariq's paper from the above blog post looks at
this question.) So if clients mistakenly treat all relays like they have
the Guard flag, then they might pick flaky ones, thus increasing the rate
of natural churn, thus increasing the expected number of entry guards a
client will touch in a given time period. I don't think this one is a big
deal -- it's certainly worth fixing, and fixing it will improve anonymity,
but I don't think the rate of natural churn is hugely higher for all the
relays than for just the relays with the Guard flag. Or said another way,
there are enough fast and stable relays that you'll probably hit upon a
good relay pretty early in the process. (Somebody here could use the
public metrics database to check, if they wanted!)

B) One of the nice side effects of only giving the Guard flag to relays
that have been around a while is that when some jerk signs up 100 relays
on Amazon EC2, these relays will never interact directly with users
for the first week or so. But if clients mistakenly treat all relays
like they have the Guard flag, then they don't necessarily have this
"waiting period" for newly born relays. I don't think this one is a
big deal either -- first because it takes several days before they get
measured by the bwauths, so some of this waiting period is still in place,
and second because clients with existing guards will probably not rotate
to a new guard at the moment that the new relays show up.

Clients still choose their new guards proportional to their speed, and
many of the fast relays have the Guard flag, so for many users there
won't be much difference. But for a tiny number of users, they could
end up picking an entry point that very few other people have picked,
and that could have crummy consequences for them. For more on issues
like those, you will enjoy this HotPETS paper from last year:
https://www.petsymposium.org/2014/papers/Dingledine.pdf

Hope that helps,
--Roger

-- 
tor-talk mailing list - tor-talk@xxxxxxxxxxxxxxxxxxxx
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk