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. > 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@xxxxxx>
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev