On Tue, Feb 22, 2011 at 3:49 PM, thecarp <thec...@gmail.com> wrote: > It is even possible that someone might run tor in lieu of encrypted > services, I know I went and made sure that the whole trick of getting > end-to-end encryption by having a node ON the target hosts worked for me.
For that you need an exit policy to yourself, not to the internet. > I have to wonder, how is that so much worst than the situation anywhere else? I suggest an alternative question: How much better is it having more nodes choose not to exclude 443 so that tor will have more 443 capacity, providing faster 443 service and fewer reasons for people to use unsecured http? How does that compare to the potential harm of throwing out a near zero number of nodes with high suspect policies (which are probably either misconfigurated _or_ are sniffing) and which were not previously taking considerable exit traffic in any case? Certainly there are other bad nodes out there, but that doesn't really make it any better. It's a small benefit in each direction. "An incentive for more people to offer 443" vs "a small amount of additional probably tainted capacity". Sensible people might go either way. What sensible people won't do is participate in an epic argument about it (and I apologize for my participation)… Of course, until you factor in the information we received later which is that a researcher has apparently been using a technique to discover "passively" eavesdropping nodes, and the node in question here came up. Sort of mooting the whole discussion until the research is published. [snip] > I am thinking, what if badexits became more like a DNS RBL.... there > could be multiple sources of truth that people could choose to subscribe > to. Maybe, for some reason, I feel the need to avoid exits in some area > (like china), it would allow me to subscribe to the list that tries to > keep chineese exits banned. There is already support for geographic targeting in the tor software, fwiw. > Maybe someone could make a little side cash (bitcoins?) doing node > contact verification and publishing a badexits list based on faile > docntact info. Shit...maybe implement a "good exits" for them. Just some > thoughts. No reason that this needs to be overly centralized. It's been a long thread so I can understand why you've missed it— but there is an _enormous_ smoking gun reason on why this should be to be somewhat centralized. Consider: What is more anonymous: two anonymity networks each with one user or one anonymity network with two users? The first has no anonymity at all, the latter has a little. This pattern plays out with larger numbers. If you can split up the users of a anonymity network you make it less anonymous. This is a called a partitioning attack. If you have user selected exit subsets then you are partitioning the network and reducing its anonymity. It's especially bad if you know in advance who is in which subset, E.g. "I told everyone except bob this exit was bad, so if someone is using it it's probably bob", but it's can be a bad attack blind e.g. "Mystery person X uses exits 1,2,3 but never 4,5,6, and thec...@gmail.com also uses the same mixture. I bet mystery person X is the same persona as thecarp" Of course, users will sometimes do things which distinguish themselves but the software ought not _encourage_ anonymity weakening behavior like this especially when the implications are subtle and not the practical effect is not especially well understood. It would be very sad if someone thought "I need to be extra secure, so I'll turn all these knobs" and by the resulting unique mix of exits used they ended up uniquely identifying their client. So ideally the default behavior should be as broadly acceptable as possible, and then people who need different behavior should be able to do so thought hopefully minimum changes which result in the least anonymity loss. (And hopefully not without understanding the increased risk that they're taking) _______________________________________________ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
