On Fri, Aug 18, 2006 at 08:49:07PM -0700, Anothony Georgeo wrote: > Hi, > > I have been thinking about the issue of exit node > operators and/or adversaries sniffing clear-text > ingress/egress traffic locally and/or remotly on an > exit node. I have a possible solution but I would > like the Tor devs. and experts here to weigh-in. > > If this won't work feel free to ignore this > thread...or just belittle me ;-) Erk. I hope I'm not *that* rude. :) [...] > --> Possible Solution: > > 4. A couple dozen _fast_ 24x7 exit nodes are run by > trusted operators (read: known personally by Nick or > Roger) on a local machine the operators control. This would pretty much restrict exit nodes to a few places in the US and Europe, since that's where the exit node operators we know are. It would limit the scalability of the network pretty badly, and that's a problem, since we need to accommodate more users, not less. Also, "A local machine the operators control" would be insufficient and troublesome. If we want to lower the likelihood of eavesdropping, we'd need to make sure it wasn't on an easily eavesdropped network (like, say, a university net). "Local" would mean no collocated hosts, and no hosts at your place of work. So we'd basically be limited to people that Roger and I know personally who have very fast network connections to their homes and who want to run an exit node. That is not a big list... and because it's not a big list, it would make us more vulnerable to certain attacks: - End-to-end correlation attacks get easier, since fewer exits means fewer points that a roving adversary would need to eavesdrop on in order to see all traffic leaving the network. - Legal/social/online DOS attacks get easier, since fewer exits means fewer people you need to sue/intimidate/flood in order to take down the network. > 5. These trusted exit nodes would be setup as Hidden > Services (ex. "www.6sxoyfb3h2nvok2d.EXIT.onion"). > > 6. Tor would be updated to use these .EXIT.onion nodes > randomly as it now randomly chooses regular exit > nodes. > > 7. All Tor traffic exits from these .EXIT.onion nodes. Technically speaking, hidden exit nodes are a pretty cool idea -- but I don't think they achieve what you want. If nobody knows where the exit nodes are, it's _harder_ to tell whether they're trustworthy, rather than easier. Now, perhaps you meant that only Roger and I should know where the exits were. But that would create problems: - It would turn Roger and me into a single failure point with respect to the network. For obvious reasons, I'd like to *minimize* the number of viable attacks on the network that start with "Send thugs to threaten Nick"; this would create a new one. ;) - It would require us to operate in secret, without oversight. This would reduce confidence in the network. - It wouldn't work so well, since an attacker could easily enumerate the exit nodes by just making a series of connections via Tor to a website they control, and looking at which IPs those connections come from. Still, technically, it's a very cool notion. I don't think it's useful *here*, but I kinda hope we eventually come up with something it's good for, so I have an excuse to implement it. ;) [...] > 10b. Not associating IP's with .EXIT.onion operators > on the 'closed' list should offer an extra layer of > anonymity for the operators. > > 10c. Due to the fact an .EXIT.onion node operator can > not be associated to any perticular .EXIT.onion node > there may be less liability for the operator. Again, if you want to know who's running [X].exit.onion, you could just make a connection to your own website via [X].exit.onion, and see whose IP it comes from. Also, if it's not easy to prove that you're running a Tor exit node, you will IMO have a _harder_ time defending yourself if somebody tries to accuse you of originating traffic that your exit node delivers. > 11. ISP's, websites, etc may not be able to block > these servers as the IP's of the .EXIT.onion nodes are > not associated to the nodes. (is this correct?). Being hard to block at the exit side is not a goal of Tor. We want it to be _easy_ for websites that don't want anonymous traffic to block us. Being blockable discourages administrators from taking an adversarial stance to our software, and has in several cases actually encouraged people to improve their authorization systems to not rely on IP blocking for security. See http://wiki.noreply.org/noreply/TheOnionRouter/TorFAQ#WhyBlockable for more rationale. [...] yrs, -- Nick Mathewson
Attachment:
pgpsmRa1VUwZT.pgp
Description: PGP signature