Re: [tor-relays] [tor-dev] Hidden service policies
On Sun, Jul 20, 2014 at 9:57 PM, Thomas White thomaswh...@riseup.net wrote: Mike Hearn, Simple. If you start filtering anything at all, regardless of what it is ... then I will block any connection of your relays to mine ... Freedom isn't free unless it is totally free and a selective reading policy through Tor is not just a bad idea as stated below, I find it outright insulting to me and everyone else who cares about the free and open internet. The fact somebody has the audacity to come to a project like Tor and propose blacklisting mechanisms is jaw-dropping. ... As I recall, you are also the person who raised the idea of coin tinting or a similar concept in the bitcoin community to identify suspect coins and that backfired spectacularly on you. Yes, that is the person. Though the term is known as 'taint'. One of many discussions from that suggestion is here: https://bitcointalk.org/index.php?topic=333824.0 so while you are reading this, let me know if you run any relays so I can avoid them. router riker 207.12.89.16 9001 0 0 fingerprint 8657 6CF6 AA84 496F 62C0 5AFE 9F26 8962 A5F0 B2BD contact Mike Hearn m...@plan99.net accept *:8333 reject *:* Normally I would thank exits for passing BTC traffic, but now I'm unsure of this one (and a few others), especially given that's the only exit policy of the above node. To identify anon (Tor) coins for marking and tracking? ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] [tor-dev] Hidden service policies
Thomas White thomaswh...@riseup.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mike Hearn, Simple. If you start filtering anything at all, regardless of what it is (yes, even if you filter child porn or fraud sites) then I will block any connection of your relays to mine (which are exits and guards totally 4Gbps). There are uses for preventing some connections Sorry, wrong answer. If you block connections from other relays, you break the tor network. I don't recall offhand whether that sort of breakage might earn your relay either an Invalid flag or being simply dropped from the consensus. like if you are legally required to then I guess the tradeoff of some inconvenience for a handful of relays, but still providing high-speed access to Tor for most people and sites is worth it. When you begin to do it as a proactive censorship event is when I will be firmly against you. The moment people censor things because it is illegal, immoral or terrorist is the moment that person accepts responsibility for the traffic that passes through their nodes and is an active attempt by them to filter what people can access. Freedom isn't free unless it is totally free and a selective reading policy through Tor is not just a bad idea as stated below, I find it outright insulting to me and everyone else who cares about the free and open internet. The fact somebody has the audacity to come to a project like Tor and propose blacklisting mechanisms is jaw-dropping. In addition, botnets using Tor actually improve the security of the network. Generally the more traffic there is, the harder it is to conduct statistical attacks against the users. Now of course it is not the most politic thing to say or the most popular, but it's the truth. Are you suggesting that the mobbing attacks on HSDIR relays are the actions of botnets? If so, then you are suggesting that the problem of mobbing of HSDIR relays is probably insoluble because it would not be the symptom of a bug in tor. :-( We don't need to stop x y or z using Tor, we need to get more people using Tor regardless of their purpose. Botnets are the result of design/security flaws and not something within the scope of Tor Project to address. Wrong again. See multitudinous previous threads regarding bittorrent over tor. Let me give you an example of appropriate filtering. My system logs frequent attacks/probes that I consider illegitimate. I enter the source addresses of those probes into a pf table of addresses from which SYN packets for any protocol or port get dropped with no response. However, there is a cron job that runs every 30 minutes that takes all the relay IP addresses in the most recently downloaded consensus and puts them into another pf table. This latter table is used by pf rules to bypass the check described above, but only for relays attempting to connect to my relay's ORPort or DirPort. This prevents the sort of breakage you threaten to cause because currently active relays will still be able to relay through my relay, although if they are also in the table described first, then they will have no *other* type of access to my system. Scott Bennett, Comm. ASMELG, CFIAG ** * Internet: bennett at sdf.org *or* bennett at freeshell.org * ** * A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army. * *-- Gov. John Hancock, New York Journal, 28 January 1790 * ** ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] [tor-dev] Hidden service policies
On 21/07/2014 7:34 AM, Thomas White wrote: Seemed a little targeted at me and I am the one agreeing with you xD Wasn't so much targeted at you, as I was chiming in to agree with what you had said. :) Just in my own words. Furthermore, I'm going to see what the authority directories think about his relay because that is just playing silly bugger only allowing bitcoin related traffic. I don't see an issue with his relay only choosing to allow bitcoin traffic. Again, that comes down to allowing each relay operator to allow or reject whatever ports they are comfortable with through their relays. Just as we can't go around censoring services however we please, we can't go around telling relay operators that they need to allow arbitrary traffic on our say-so. If he only allows a single port, he won't get the Exit flag (as long as the policy on that flag is that any two of [HTTP, HTTPS, IRC] must be exited). As far as the rest goes, As long as he's using the Tor-readable method of limiting ports (ExitPolicy, rather than some silly buggered firewall that Tor can't understand), my opinion would be to leave him be. -Lance signature.asc Description: OpenPGP digital signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] [tor-dev] Hidden service policies
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mike Hearn, Simple. If you start filtering anything at all, regardless of what it is (yes, even if you filter child porn or fraud sites) then I will block any connection of your relays to mine (which are exits and guards totally 4Gbps). There are uses for preventing some connections like if you are legally required to then I guess the tradeoff of some inconvenience for a handful of relays, but still providing high-speed access to Tor for most people and sites is worth it. When you begin to do it as a proactive censorship event is when I will be firmly against you. The moment people censor things because it is illegal, immoral or terrorist is the moment that person accepts responsibility for the traffic that passes through their nodes and is an active attempt by them to filter what people can access. Freedom isn't free unless it is totally free and a selective reading policy through Tor is not just a bad idea as stated below, I find it outright insulting to me and everyone else who cares about the free and open internet. The fact somebody has the audacity to come to a project like Tor and propose blacklisting mechanisms is jaw-dropping. In addition, botnets using Tor actually improve the security of the network. Generally the more traffic there is, the harder it is to conduct statistical attacks against the users. Now of course it is not the most politic thing to say or the most popular, but it's the truth. We don't need to stop x y or z using Tor, we need to get more people using Tor regardless of their purpose. Botnets are the result of design/security flaws and not something within the scope of Tor Project to address. You did mention the development of a workaround to avoid people who do block whatever resource they are trying to access, but what is the point? Once it is easy to start blocking hidden services like that, it's only a very small step to blacklists floating around, then like Spamhaus that list maintainer acts like a mafia to coerce other operators into using it. Even in the wording of what you admitted yourself, additional complexity, Tor should be spending time improving it's systems and fixing bugs rather than making censorship easier for the masses. This is one of the concerns I voiced in the Paris Tor developer meeting only a few weeks ago too. As I recall, you are also the person who raised the idea of coin tinting or a similar concept in the bitcoin community to identify suspect coins and that backfired spectacularly on you. Don't try to bring such ideas to Tor because they are not the same and I doubt you would try to propose blacklisting bitcoin addresses on the bitcoin network? Then again, after reading that message, I honestly don't know so while you are reading this, let me know if you run any relays so I can avoid them. I could go on for a lot longer, but I'll leave it at this for now or I will not be getting to sleep tonight. Just know I'd rather go to prison than act as an assistant of censorship. - -T On 21/07/2014 00:38, grarpamp wrote: 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.
