> On Tue, May 13, 2014 at 5:48 PM, Jeroen Massar <jer...@massar.ch> wrote: > They do not care about solely Tor, that is just one of many many things > they block to restrict the majority of people from accessing 'free' > (ahem) content.
I've said multiple times this does not concern gfw or bootstrapping access to tor itself. Fuck the gfw, and if this helps do that in any amount by providing alternative 'exit ips' to tor users, great. > If GFW can detect it, any other adversary can do so too. It's called defense in depth, no particular part of which is bulletproof. Get off it. > Hence, you are mixing them. No, I know, and do not mix, up the difference, I choose to combine them into one class since this will help to defeat both equally. > Define "ours". I already did, those relay ops who wish to run OpenVPN or bind/route their exit via a different IP. You as an op are free to not do such things. Don't claim that others do not. > This service is there so that operators of sites can decide if they > want to serve anonymous users or not. As said and echoed in other threads, I warrant that a signifigant portion of them are not making such careful, balanced and thoughful decisions as you suggest. > Note that that is there to reduce the amount of abuse, and thus the > global and full blocking of Tor. As in other threads, prove that the incidence of abuse via tor is greater than the incidence via clearnet. > Typically an operator will only block > registration through Tor, while allowing logins through Tor. Doesn't matter which one is blocked, result is the same, a service unusable by legit users who care about their good privacy interests as noted on the tor front page. > Who is "We"? Which users complain, and about what exactly? Ever try to access a site via tor and be rejected for doing nothing wrong? That's who. > You seem to want to attempt avoiding blocks of a server, not that you > want to anonymous, or have an operator-in-the-middle blocking you from a > site that wants you as a user. Do not combine the two. Tor's encrypted circuits give source anonymity. Tor's exits (or this OpenVPN/binding) give the ways around things. Absolutely right, I wish to give users ways to avoid gratuitous unthoughtful (in respect and consideration to the individual legit user wishing access to such services) ways around such blocking. > By trying to avoid blocks that way, you > will only give a bad name to Tor and other similar projects. Only if you assume tor users are 'bad' actors. That is a shame people think that. >> They can then move to account >> based and other finer grained user management models. > Sites (eg wikipedia) that use TorDNSEL and similar constructs typically > allow registration from a non-anonymized address, while allowing logins > quite fine from them. Already answered. > It is no different than us deploying tor network to give users > ability to avoid blocks in first place. It is simply evolution > of making such tools available to users. > You are trying to defy policy of a site... Tor ITSELF is trying to defy all manner of policies, this fits that just fine. > not bypassing a bad operator. This makes no sense. I never said relay ops were bad. > You don't have to run described openvpn extension if you > don't want. > I don't think anybody will. There are too many ways to abuse that setup > and more importantly, too easy to detect. I'm putting the idea out there. Some relays will, some won't. You don't like it, you don't have to. Some blocklists and site ops will scan and detect these new IP's, some won't. Any that don't is a win for us. Abuse it? Laugh, no more than users abuse current Tor exits. Actually, it would likely be less incidence of mundane flood of abuse since the moronic masses of the internet won't bother figuring out how to scan and setup OpenVPN over tor or using controller to map non OR_IP exits. > Tor and other "open proxies" have a lot to do with abusive users. > Typically they come hand in hand. Seriously? A thousand Tor exits compared to a hundreds of millions of clearnet internet IP's cause more incidence of abuse reports that need handled by abuse desks and LEA? Please, GET REAL!!! > There are good users, and there are bad ones. Depending on how your user > base works and how much time one wants to spend, you might not want to > keep on banning the people who are obviously trying to hide. I'm sorry you feel that the majority of tor users are bad. Have you visited your local coffeeshop or home lately, how many of those teenage freeloaders are bad. No difference, maybe even worse incidence. > There is a list of these kind of services here: > https://trac.torproject.org/projects/tor/wiki/org/doc/ListOfServicesBlockingTor > Attempting to bypassing those restrictions will only cause them to block > that method too, and IMHO with good reason. They are free to do that, we are free to continue to deploy countermeasures against indiscriminate non user-account-based blocking. > Haha, yeah China and legalities.... so yes, obviously you are NOT trying > to circumvent entity like the GFW. > Thus what are you trying to circumvent? Duh. Already said this many times. Tor users complain about being blocked indiscriminantly when doing nothing wrong themselves. Posts from these users are frequent on tor-talk. And indeed as you listed, on that wiki page as well. We should try to help them. This is one way to do that. And to continue to put pressure on clearnet services to deploy their own account based, NOT archaic ip based, abuse management solutions. > <user - ovpn - torcli> -- <exit torrelay or_ip - localhost - ovpn_ip> -- world > That "ovpn" part on the left is easily detected by any party in the > middle doing No. Understand the diagram. It is not detectable by anyone between torcli and torrelay, because that is just normal tor. > Note that you are running IP over TCP over Tor (which is over TCP). Of course. Unless of course, as suggested before, some operators choose the method of binding/routing their exit over an ip different from their OR_IP, then it would just be native tor and native TCP. > The performance of that will be very bad. Tor network is already > overloaded enough as it is. No it won't, I've tested it, it works just fine. The only issue is the exit ip may change. So the exit operator is expected to block access to ovpn_ip from anything other than their associated or_ip, and the user is expected to config their client to use only the associated exit per whatever 'world' usage session they have in mind. It's not supposed to be point-click easy, only possible. > As for the ovpn part on the right, you could just let your Tor exit node > exit on a different IP instead. Already mentioned that many times. > The setup you describe above is something outside of Tor though, as > you are effectively doing VPN over Tor Obviously, and by design. > losing all the properties that Tor > has, as the traffic on the left can be matched to the traffic on the > right (one of the main reasons it does not pass the full IP datagrams). No it can't. The user is running ovpn and tor on their node, and the exit operator is running ovpn and tor on their node. The only thing that hits clearnet is tor, not ovpn. So there is zero difference to any observer between 'user' and 'ovpn_ip' there at all, all they see is tor. Same as before. > BridgeDB is not (well, it is not supposed to be) easily scraped. > See https://bridges.torproject.org/ for the details. I know how bridges, pt, and bridgedb works. BDB is not foolproof, neither is this, nor are they expected to be, it's an arms race, get it. If you don't come out with new permutations, you lose. > How is "scraping" different from "scanning"; either is automatable and > both are already being done. I suppose i refer to parsing the consensus (readily available to anyone who has no more elite skill than to run the client), as scraping. Yes, you could abuse the bridge email/captcha. Yes you could run your own 'webserver' and launch connections through all the exit FP's to find non OR_IP bound/routed exits. Yes you could even try the harder work to set up openvpn and scan around the OR_IP for an ovpn connection and test that. The point is, all of that is harder than parsing the consensus. Thus it is not nearly as likely to become part of blocklist services, or 'website' service operators personal blocklists, anytime soon. > As you will be exiting from the OpenVPN IP, I can only suggest > that you sign up for some VPN service somewhere and use that > instead. Then yhy don't you suggest users sign up and pay anonymously for three separate vpn/shell services and onionchain them all together and roam them around new vpn/shells once in a while. It's the same thing. You see. > That was not the setup you described originally. It was exactly the same setup, the diagram was added since people were confused. > Please note that you are not solving anything for most Tor users. They > get blocked from _accessing_ the Tor network, not from getting out of it. Users on ListOfServicesBlockingTor and tor-talk would dispute that these days of late. > As I noted, 'getting out', or better 'who allows Tor nodes to connect to > their sites' is a decision to be made by those operators. Yes, and they can still make those decisions. We're just making them think more about it. On clearnet you as a service op when you block an ip are usually taking out just one user. You should have just deleted their account, but whatever. When you block a tor ip you are stupidly taking out many many users who have nothing to do with the account that caused you grief. That, in my opinion, is WRONG. I run services, they are account based, and I refuse to block access to me via tor exits. You can do and advocate differently on your services or your exits. Just don't claim it is right for all. I'm presenting and advocating an option for relay operators to take up as they each to their own see fit. > most exits have a block list > for address space and ports. You would have to do the same for openvpn, > next to that, as that is not integrated into Tor, tor cannot make a > decision about when something is being blocked and thus chose another > 'exit'. I've already described this is NOT an integrated tor function. It is an extra thing relay operators can do on their own, that users have to scan for or otherwise find, configure on their own and generally deal with. Of course it won't be slickly integrated (unless the operator chooses the purely tor based non OR_IP binging/routing method). Users will try their termination, and if they can't get through to their chosen destination because the ovpn operator has blocked it, they'll try some other termination point. > You clearly do not understand why the DNSEL is published. Please read up > on it. I know exactly why DNSEL is published. On one hand it is great, on the other it is abused by clearnet service operators who, in my and others opinions, are not giving enough thought and effort into other ways they can address 'abuse'. I also know Tor Project has a budget for outreach, in part of which is meant to educate about some of these other local abuse management ways besides blocking access to services via tor. Maybe it's time that budget proportion and time allocation was increased. > OpenVPN, especially in crypted mode, requires quite a lot more CPU power > on the nodes running OpenVPN node. Obviously. AES-NI helps. However it does not necessarily need to be encrypted (or even heavily) since the user still has a full tor-cli to tor-exit path established. See the diagram. It is the exit that is their security, the ovpn is just adding a new ip/protocol service. > Next to that, due to the overhead of IP over OpenVPN-TCP which then goes > over Tor, your performance will be really bad. No, again, tested, quite tolerable for low sensitivity uses such as everyday web traffic. > You do not need OpenVPN to solve a 'different exit than published', the > exit operator can just randomly forward/NAT outbound packets over > different IPs. I suggested that as well. Feel free to do so. >> Same goes for binding/routing your tor exit out a different ip >> than your OR ip. Except that using OpenVPN can permit >> other protocols for help of user than only TCP. > > Which is likely the real requirement you have. Do you want to do gaming, > or is it torrenting you want to do? Or... even worse: the ability to > send raw packets? I do not speak for myself. I speak for all the users who may wish to do whatever it is they want. Exactly as they can do whatever it is they want over TCP today. If they want to setup GRE/IPv6 tunnels, if they want to use DNS and voip protocols, NFS/RPC mount, it they are an engineer and want test raw IP/ICMP, if they want to game, torrent or anything else... is *not* up to me. Relay operators are free to set up their own tor exit nodes and extended tor binding/routing/nat and openvpn services however they see fit to each their own as always. These two methods are something that can definitely help some legit users, therefore I suggest it be done by whoever in the relay community wants to. _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
