On Tue, 27 Nov 2012 20:53:03 -0500 Nick Mathewson <nickm@xxxxxxxxxxxx> wrote: > On Tue, Nov 27, 2012 at 10:08 AM, Julian Yon <julian@xxxxxxxxxx> > wrote: > > > > 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 might be possible experimentally. Implement it as an optional codepath. Run in both configurations for a while, and in each case monitor the number/percentage of refused connections the average added latency due to refusal, and the percentage of total latency that this represents. > 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. Hmm. From the summary we know which destination ports we can use, so the time we have a problem is (e.g.) when an exit allows port 80 in general but not for the particular IP/netblock in question. This is a rare case, but when we do hit it, without DNS caching every single request is going to bounce, isn't it? Given the number of resources on a typical modern webpage, this implies that occasionally somebody is going to find that suddenly their latency goes through the roof because of an unlucky combination of website and exit. And so maybe it's not quite as simple as the above experiment :-/ What's needed is to determine whether the effect is large enough that it needs to be accounted for, or whether it's just an inconvenient corner case. So I think maybe performing some measurements using an artificially small ExitNodes list, giving a high probability of hitting a restrictive exit, may be necessary (obviously the call that Roger mentioned to policies_set_node_exitpolicy_to_reject_all needs to be disabled or it'll just get blacklisted on the first hit). And of course you're right, unless clients have some way of knowing to avoid the exit it's a moot point, so... > 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. Ok, that's a fair concern. Two variations sprang to mind immediately: (1) Add a hash of each router's full exit policy to the consensus. The client can use this to verify that it's being given the same info as everyone else. For policies that are fully covered by the summary, this line could be omitted (as it should never be needed). (2) The first time an exit rejects a connection, ask another party (directory authority/mirror) for the full policy at that point. However, I see that a related idea has been floated before (Proposal 141). Presumably there were good reasons why that proposal wasn't implemented. Certainly I can immediately see the potential for information leakage. But as I was writing the top half of this email I then thought: (3) Don't bother trying to ascertain the full exit policy, but rather maintain a simple table of exit/IP/port combinations that have been rejected and consult it when building/using circuits. This requires no protocol changes (win!) at the cost of no longer blacklisting dishonest exits entirely. Some mechanism for expiring entries would probably be a good idea, and/or maybe hold it in a circular list so that there's a maximum number. As far as I can see, all of these would mitigate Roger's attack, and (3) feels like it should be particularly easy to implement and while it doesn't solve #1774 I can't see how it introduces any new problems. Thoughts? Is it really that simple? 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