[tor-dev] Proposal 205: Remove global client-side DNS caching
Julian Yon
julian at yon.org.uk
Tue Nov 27 15:08:17 UTC 2012
On Tue, 27 Nov 2012 00:49:28 -0500
Roger Dingledine <arma at mit.edu> 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.
> 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.)
Julian
--
3072D/F3A66B3A Julian Yon (2012 General Use) <pgp.2012 at jry.me>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 230 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20121127/ceb6bac2/attachment.pgp>
More information about the tor-dev
mailing list