Re: [tor-dev] Proposal 205: Remove global client-side DNS caching

[Nick Mathewson <nickm@xxxxxxxxxxxx>]

On Tue, Nov 27, 2012 at 10:08 AM, Julian Yon <julian@xxxxxxxxxx> wrote:
> On Tue, 27 Nov 2012 00:49:28 -0500
> Roger Dingledine <arma@xxxxxxx> wrote:
>
>> (Also, if we have no client-side dns cache, further streams requesting
>> the same address, e.g. fetching pictures from the website, might try
>> the same circuit even if we could know that its exit policy would
>> refuse the stream.)
>
> So, perhaps have a cache but only consult it for making decisions about
> whether to use a circuit, not for resolving client requests? Although
> this is still vulnerable to poisoning, that could perhaps be mitigated
> by capping the TTL at some small value.

There's an interesting idea! I wonder, can we come up with a way to
tell whether it's necessary?

It's not likely to help typical clients, since microdescriptor-users
(and all IPv6 users) don't see the full exit policy, but only a policy
summary.


>> The bandaid fix is that we should reset node->rejects_all in
>> nodelist_set_consensus() just like we reset is_valid, is_running, etc
>> from the consensus.
>>
>> The better fix is that we need to either make clients have an accurate
>> view of the relay's exit policy (is that ticket 1774?), or we need to
>> stop behaving so drastically when we only know a microdescriptor for
>> the relay and it declines to exit to an address that its short policy
>> looks like it should accept.
>
> What an interesting vulnerability, especially as it shows that ad
> servers can in fact be a serious attack vector. May I propose a more
> thorough solution? What if there were some mechanism by which, when an
> exit rejects the connection, it can provide its full policy to the
> client at that point? This would give it a chance to explain the
> situation (i.e. it's not actually rejecting everything), without
> requiring any change to the microdescriptor. Obviously the client can
> cache this info, and any node which subsequently doesn't honour its
> declared policy can still be (temporarily?) blacklisted.
>
> (Please forgive me if I'm missing something obvious. I'm not yet as
> familiar with Tor's inner workings as I'd like to be.)

My main worry here is that an exit could give different clients
different exit policies.  I'm not sure yes if there's a clever way to
bootstrap that into a full attack, but generally when you give an
attacker the ability to give different clients different views of the
network, you can run into trouble.

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