Re: [tor-talk] Tor 0.2.4.13-alpha is out

[Nick Mathewson <nickm@xxxxxxxxxxxx>]

On Sun, Jun 16, 2013 at 6:49 PM, Roman Mamedov <rm@xxxxxxxxxx> wrote:
> On Sun, 16 Jun 2013 15:18:47 -0700
> Mike Perry <mikeperry@xxxxxxxxxxxxxx> wrote:
>
>> Roger Dingledine:
>> > Tor 0.2.4.13-alpha fixes a variety of potential remote crash
>> > vulnerabilities, makes socks5 username/password circuit isolation
>> > actually actually work (this time for sure!), and cleans up a bunch
>> > of other issues in preparation for a release candidate.
>> >
>> > https://www.torproject.org/dist/
>>
>> As a heads up, a bug was introduced in this release that allows
>> malicious websites to discover a client's Guard nodes in a very short
>> amount of time (on the order an hour), if those Guard nodes upgrade to
>> this release.
>
> So a random clearnet end-destination website can trace the client all the way
> through Tor network and discover information not about its exit, not about the
> middle, but even about the entry node? And nodeS, i.e. all of them?*
> Wow; can you explain in more detail how that works?

We'll probably post in more detail once the fix is out.  See
https://trac.torproject.org/projects/tor/ticket/9072 for a summary of
what we've got so far.

The issue is that the hostile website can't trace the client through
the middle and exit per se per se, but they *can* force the client's
circuit to close, thereby forcing them to make another circuit.  If
the attacker controls the website *and* a fraction of the nodes on the
network, eventually the client would use a middle node or exit node
which the attacker also controls.

> * (then a Three Letter Agency (TLA) can obtain lists of connecting clients
> from all three Guards, and pretty much "triangulate" the actual source IP of
> that user either to a bulls-eye hit or a very short list of IPs simultaneously
> on all three.)
>
>> Unfortunately, the bug was introduced by fixing another issue that
>> allows Guard nodes to be selectively DoSed with an OOM condition, so
>> Guard node (and Guard+Exit node) operators are kind of in a jam.
>
> One more reason to abandon the Guard system altogether.

The Guard system is there for a reason: See
https://www.torproject.org/docs/faq.html.en#EntryGuards .  If you're
hoping to resist adversaries of even modest funding on the medium or
long term, you need some solution to the long-term sampling problem.

If it weren't for entry guards, this would probably be a deanonymizing
issue, since clients would eventually pick an attacker-controlled
entry point: guards are making clients safer here, not less so.

best wishes,
--
Nick
_______________________________________________
tor-talk mailing list
tor-talk@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk