Re: [tor-dev] Hidden service policies
(Aside: I think this thread is unrelated enough to tor-dev at this point that I'm going to make this my last reply.) That's too bad - I was only answering questions you posed yourself. Happy to continue debating off list. Still, I think discussion of features that could increase usage are on topic. There's a similar thread about creating social rewards for relay operators after all. Re: technological attacks/partitioning. I did not respond to this because I didn't understand the attack you're proposing, that's why I asked for a step-by-step example against a hypothetical Snowden blog. But your answer starts with first, you break Tor's security. That's not something that HS policies makes newly possible. If you can pwn the users TBB download or impersonate the directory authorities you win no matter what: HS policies are irrelevant. I don't think there's any new technical attack HS policies would open up, if they were done in the same way as exit policies. From the perspective of an HS trying to initialise, it'd just be equivalent to having a smaller network. As you already said you'd happily sacrifice the ~5000 nodes that don't exit traffic because they're harming Tor's anonymity, presumably a smaller network isn't a big deal for you? If there's a specific technical attack that doesn't rely on general attacks against Tor, I'm still keen to hear a step by step example of how to do it. Re: politics. Yes it's a largely political argument. That's fine: Tor is a political animal, it has got a lot of funding from organisations with explicitly political agendas, the who uses tor section on the front page is full of characters with political goals like activists and whistleblowers. Tor does not exist independent of politics - politics should inform its technical design decisions (and does already). Re: TBB. The consequence of TBB not having any setting below extreme is not at all minimal, as you claim, it's a probably severe reduction in usage that could insulate Tor against political pressure. I claim this because in my former job I saw the different usage levels of HotSpot Shield vs Tor. Yes, for the small number of users who might get shot they need and should have that hard core, no compromises mode. For everyone else who would like some additional privacy but who isn't worried about getting shot, the consequence of Tor's current approach is that they just don't use Tor. The same is true of other functions, like running a relay. Having knobs people can tweak is not weakness. It's acceptance of the fact that not *everyone* who wants to have privacy is Tank Man, and not *everyone* who wants to contribute to privacy feels ransomware/revenge porn sites are as worthy of protection as newspaper dropboxes. ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Hidden service policies
One of my first concerns would be that this would build in a very easy way for a government (probably the US government) to compel Tor to add in a line of code that says If it's this hidden service key, block access. And people who run Tor could easily take it out again, what with it being open source and all. After all - it's a stretch to say You must modify your software to support blocking things[0] I don't believe it's a stretch. If I did, perhaps I wouldn't bring the topic up. Judges and lawmakers care very little about the (in their eyes) minor distinction between the code to do this wasn't written yet and the code to do this wasn't configured yet. For example, look at the EU right to be forgotten ruling. The fact that no infrastructure existed to sift through tens of thousands of vague requests for search results to be removed didn't faze the court one bit, nor did the massive size of the project that resulted. They simply interpreted the (vague, poor) law put in front of them. Regardless, even if there is such a difference, jurisdiction would still have the same effect as today. If there's even one relay that supports introductions to a HS then the protocol would still technically work, but operators in regions where the government proved unfavourable would be protected and still able to operate. Additionally, in the absence of government coercion, the Tor relay community would then be able to collectively decide if they really want to pay for the privilege of giving bandwidth to botnet and ransomware operators. ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Hidden service policies
This isn't about 'acceptable usage of Tor', this is necessary compromise to limit exit operators' exposure to ISP harrassment. Even if we accept your premise that no exit operator cares about internet abuse, it's still the same thing. ISP's define what is acceptable usage of their internet connections and by implication, what is acceptable usage of the Tor exit. Tor could ignore what ISPs want (which is usually quite reasonable), but then no Tor clauses in ISP acceptable usage policies would just become even more prevalent. The ability to do this implies the ability for intro points to learn the identity public keys of hidden services they are introducing. Unfortunately, I believe this sort of enumeration attack is possible with the current HS protocol, but I think proposal 224 will fix it. It is currently possible and I am aware of proposal 224, which is why I'm bringing this up now. I don't think this is something that should be fixed without a *lot* of thought given to the consequences. I am by the way quite aware of all the counter arguments already, but someone has to play the devil's advocate here. ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Hidden service policies
On 07/21/2014 12:34 AM, Mike Hearn wrote: Tor provides exit policies to let exit relay operators restrict traffic they consider to be unwanted or abusive. In this way a kind of international group consensus emerges about what is and is not acceptable usage of Tor. For instance, SMTP out is widely restricted. As Andrea said, the exit policies are there mostly to have a small knob to stop complaints. In that sense, participation as a hidden service is opt-in: You're willing to lose the ability to use IP address as a rough method of identifying users. A network provider should in an ideal world _never_ [be able to] interfere with any of the traffic they transport. I already feel very uncomfortable limiting arbitrary destinations based on IP and port. A network provider is a neutral channel. Remember, data payload is just protocol overhead. -- Moritz Bartl https://www.torservers.net/ ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Hidden service policies
On Mon, 2014-07-21 at 11:48 +0200, Mike Hearn wrote: One of my first concerns would be that this would build in a very easy way for a government (probably the US government) to compel Tor to add in a line of code that says If it's this hidden service key, block access. And people who run Tor could easily take it out again, what with it being open source and all. You're an intelligent person and probably know that it's more complicated than that. Any automatically updating mechanism to retrieve the Hidden Service Censorship List is a massive attack vector, because two clients having two different sets of introduction points for a hidden service, or two hidden services having different sets of introduction points available, causes a partition in the anonymity set. Regardless of the moral arguments you put forward, which I will not comment on, it seems like this idea would never be implemented because none of the Tor developers have a desire to implement such a dangerous feature. If you've already thought of this, as you implied in another email, why bring it up? Do you think you'll get the Tor community to agree to enable such a damaging attack? Further, why do you think such infrastructure would be remotely successful in stopping botnets from using the Tor network? A botnet could just generate a thousand hidden service keys and cycle through them. So, this would be: * Socially damaging, because it would fly in the face of Tor's anti-censorship messaging * Technically damaging, because it would enable the worst class of attacks by allowing attackers to pick arbitrary introduction points * Not technically helpful against botnets, because they can just cycle keys * Not even technically helpful against other content, because they can change addresses faster than volunteers maintaining lists of all the CP onionsites can do the detective work (which you assume people will want to do, and do rapidly enough that this will be useful) Let's skip all the devil's advocate discussion. It isn't useful and it'll cause traffic on this thread to blow up more than it already has. Instead, why don't you just present the strongest counterarguments you've thought of against this proposal, which surely include the above, and then the strongest counterarguments to those arguments, which justify your position and have caused you, as an intelligent person, bearing all those negative effects in mind, to *still* hold this position. -- Sent from Ubuntu signature.asc Description: This is a digitally signed message part ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] Hidden service policies
Hello, As we know, hidden services can be useful for all kinds of legitimate things (Pond's usage is particularly interesting), however they do also sometimes get used by botnets and other problematic things. Tor provides exit policies to let exit relay operators restrict traffic they consider to be unwanted or abusive. In this way a kind of international group consensus emerges about what is and is not acceptable usage of Tor. For instance, SMTP out is widely restricted. Has there been any discussion of implementing similar controls for hidden services, where relays would refuse to act as introduction points for hidden services that match certain criteria e.g. have a particular key, or whose key appears in a list downloaded occasionally via Tor itself. In this way relay operators could avoid their resources being used for establishing communication with botnet CnC servers. Obviously such a scheme would require a protocol and client upgrade to avoid nodes building circuits to relays that then refuse to introduce. The downside is additional complexity. The upside is potentially recruiting new relay operators. ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Hidden service policies
One of my first concerns would be that this would build in a very easy way for a government (probably the US government) to compel Tor to add in a line of code that says If it's this hidden service key, block access. After all - it's a stretch to say You must modify your software to support blocking things[0] but it's not so much a stretch to say You already have the code written to block access to things, block access to this thing. -tom [0] The OnStar legal case notwithstanding ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Hidden service policies
On Sun, Jul 20, 2014 at 6:34 PM, Mike Hearn m...@plan99.net wrote: Hello, As we know, hidden services can be useful for all kinds of legitimate things (Pond's usage is particularly interesting), however they do also sometimes get used by botnets and other problematic things. Tor provides exit policies to let exit relay operators restrict traffic they consider to be unwanted or abusive. In this way a kind of international group consensus emerges about what is and is not acceptable usage of Tor. For instance, SMTP out is widely restricted. Has there been any discussion of implementing similar controls for hidden services, where relays would refuse to act as introduction points for hidden services that match certain criteria e.g. have a particular key, or whose key appears in a list downloaded occasionally via Tor itself. In this way relay operators could avoid their resources being used for establishing communication with botnet CnC servers. Obviously such a scheme would require a protocol and client upgrade to avoid nodes building circuits to relays that then refuse to introduce. The downside is additional complexity. The upside is potentially recruiting new relay operators. HS's will just change their HS keys out from under your list. Then it becomes whack a mole. And you'll also be taking out shared services with the bathwater. Are you funding maintenance of that list? Ready to be called a censor when you exceed your noble intent as all have done before? And to be ignored by those operators who don't care to subscribe to your censor list thus nullifying your efforts (not least of why because it may be illegal for them to look at services on the list to verify it, or to look at and make decisions regarding content of traffic that transits them). And ignored by botnet ops who will surely run their own relays and internal pathing. ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
