On Tue, Nov 27, 2012 at 10:08 AM, Julian Yon julian@yon.org.uk wrote:
On Tue, 27 Nov 2012 00:49:28 -0500 Roger Dingledine arma@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.
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,