Re: [tor-dev] Defending against guard discovery attacks by pinning middle nodes

[George Kadianakis <desnacked@xxxxxxxxxx>]

Ian Goldberg <iang@xxxxxxxxxxxxxxx> writes:

> On Fri, Jul 11, 2014 at 01:44:36PM +0300, George Kadianakis wrote:
>> Hey Nick,
>> 
>> this mail is about the schemes we were discussing during the dev
>> meeting on how to protect HSes against guard discovery attacks (#9001).
>> 
>> I think we have some ideas on how to offer better protection against
>> such attacks, mainly by keeping our middle nodes more static than we
>> do currently.
>> 
>> For example, we could keep our middle nodes for 3-4 days instead of
>> choosing new ones for every circuit. As Roger has suggested, maybe we
>> don't even need to write the static middle nodes on the state file,
>> just use new ones if Tor has restarted.
>> 
>> Keeping middle nodes around for longer will make those attacks much
>> slower (it restricts them to one attack attempt every 3-4 days), but
>> are there any serious negative implications?
>> 
>> For example, if you were unlucky and you picked an evil middle node,
>> and you keep it for 3-4 days, that middle node will always see your
>> traffic coming through your guard (assuming a single guard per
>> client). If we assume you use a non-popular guard node (with only a
>> few clients using it), the middle guard might be able to think "Ah,
>> the circuit that comes from that guard node is always user X" making
>> your circuits a bit linkable from the PoV of your middle node.
>
> And similarly at the exit node: the exit will now know that circuits
> coming from the same middle are more likely to be the same client.
> That's a little more worrying to me than the above.
>

That's a good point and it pretty much kills the idea. We don't have
enough users or powerful nodes, to be able to provide any kind of
anonymity set for the circuits coming from the same pinned middle node.

I guess a stupid way of dodging that problem is instead of applying
the "semi-static middle nodes" idea to all Tor clients, maybe we can
only apply it to HS rendezvous circuits.

The idea is that an exit node being able to link the rendezvous
circuits of an HS *might* not be that dangerous (compared to the exit
node being able to link the HTTP traffic of Tor clients).

If we are worrying about reducing Tor's anonymity set by partitioning
our circuits to "rendezvous circuits" and "regular circuits" one can
argue that this is the case currently too, since the nodes of a
rendezvous circuit are probably able to statistically determine
whether the circuit is a rendezvous circuit or a regular Tor circuit
by the cells/data flow.

(To be honest, I don't really like this idea, but I'm just stating it
here for brainstorming.)
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev