On Thu, May 15, 2014 at 9:36 AM, Jeroen Massar jeroen@massar.ch wrote:
the proposed setup breaks all anonymity (OpenVPN sends Raw IP packets) thus 1:1 mapping for the few people who will use it.
No, it does not break any anonymity. And it doesn't matter what OpvenVPN sends because it all happens over the users already secured Tor circuit '--'. You just don't understand the model. Here it is again. '<>' is a single computer, there are two computers pictured. Packets travel through the listed processes and computers from left to right. '++' is the usual clearnet beyond the exit box.
A) <user - ovpncli - torcli> -- <tor_exit_relay_or_ip - ovpn_term_ip> ++ world
B) <user - torcli> -- <tor_exit_relay_exit_via_non_or_ip> ++ world This other suggested model is: swap ovpn above with choosing exits that bind/route/nat their tor exit traffic out a different IP than their published OR_IP. ie: the exit IP is not scrapable off the consensus because it is not the OR IP.
Of these two ways for users to utilize IP's that do not appear in the consensus...
A) OpenVPN is more useful for end users by potentially allowing other-than-TCP and/or even possibly inbound connections. All of which are chooseable and configurable by the volunteer operator to suit their needs.
B) Non_OR_IP_exits are limited to TCP. And are fully integrated with tor's accept/reject exit policies.
[OpenVPN method 'A' would require additional host/ovpn rules to achieve pseudo exit policies, and the user would not know ahead of time what they are (not in the consensus). However, a survey of existing exit policies shows the user would be likely to reach their desired destination simply by trying any other ovpn enhanced exit, particularly in the case of typical HTTP[S] websurfing, because almost all exit operators permit that anyway.]
Running Ovpn directly on the relay box is not necessarily required, though not doing so would cost external bandwidth (such as to reach Mirmir's suggested disposable VPS IP's). Traffic off the box to those IP's could be further rate limited in that case to reduce cost if usage of these methods becomes nontrivial. Also, if the operator doesn't have nearby one-IP-up/down IP's available to them, the standard user clue to 'check for OpenVPN port 1194 one IP up/down from the OR_IP' would not work for the users. In that case, the operator must publish/leak the IP+port on the wiki, the list, or elsewhere.
few users will ever use this, few random exits will support it,
Typical negativity some people say regarding anything new. I hear people are trying to move to PFS suites, use secure messaging on phones and all sorts of new things these days. Feel free to downtalk them too.
Only reason why this is being asked: circumvent site policies
Absolutely correct. Yet you are not realizing that Tor *itself* is exactly such a circumvention tool, particularly against services and other things that don't try, or fail, to block all of Tor.
If you are opposed to circumvention tech for innocents, you want nice happy cooperation with whatever [web] services want, then you should not run this proposal, or even run a Tor relay. Because they are both circum-tech. And circum-tech should be listed, along with usage as liberation tech, here: https://www.torproject.org/about/torusers.html.en But that'll probably never happen because it's too 'hot' or hard to understand.
It is also useful for other things besides defeating dumb site policies...
- Getting around blocklists that sites blindly install by default without realizing what they are blocking, why, or even being given the chance to consider Tor users and agree with blocking them or not. - Making Tor a better network diagnostic tool for admins at work because OVPN can transport more protocols to test things with. - Similarly, allowing more Tor users to 'torify' more apps than just TCP ones.
Tor users and other proxies defying their access policy.
Cue and stir the tired debate about whether Tor users are good/bad or whether services really need to implement fine grained, intelligent management of users based on their *account*, not their *apparent ip*. I believe Tor users are good, and that better management models should be encouraged to evolve. If we are the ones to do that, by whatever means, outreach, this tech or otherwise, so be it.
please detail how exactly you handle abusive users
I delete their account per ToS. Point, click, gone, easy.
ask them to reconsider
I do this too. Yet it is the other innocent users that can't make headway, up against services that won't give enough thought, that this is really meant for. I support those users.
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.
You mean because people are trying to circumvent the policies of a site?
No, as I said before...
... 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!!!
And still, as the operator does not want anonymous users, you will have to abide by that.
There are careful distinctions between anonymous (once), pseudonymous (long term), impersonated, fictitious, 'real-id', untraceable, bad/good, etc. A service operator must be educated enough in those definitions before it may be certain of which of those it wants or does not want and why. Otherwise it is killing everyone.
Netflix, Hulu, content/geo 'restrictions', etc Did it help you to be anonymous? Not really.
1) Yes, it broadens users exposures to other cultures.
Did it damage lots of people who played ball, definitely.
2) No, not if done quietly, innocently (even if underhandedly).
And if not, sometimes the needs for (1) outweighs (2).
What would you do if it was your site, let them run rampant on your site or make it easy: filter those users out?
I myself don't mind spending a little busywork and just delete their accounts.
[Various things are not an intent of Tor.]
They are dual uses of Tor. Do not run a relay if you are not satisfied with that possibility.
If an operator does not want you on their site, do not circumvent it. You are thus stating: I want to circumvent a site's decision to block me.
No, you are still not understanding a (not so delicate, yet very important) distinction...
- IP blocking is NOT blocking a particular single user context (ie: 'you', 'me', joe, jane, anonuser1543), it is blocking whoever happens to be using that IP [1].
In my opinion, that is wrong because it takes out innocent users and thus I'm happy to suggest any number of ways to push back against it until this effectively 'anti-innocent' model changes.
[1] Both now, and beyond if there is no expiry, or if the blocking trigger is too sensitive. Many clearnet end users worldwide are behind some form of "not strictly guaranteed 1:1 static" IP:user mapping... be it DHCP, phone, wifi, cafe, corporate/edu/home/isp nat, shared computers, etc. Blocking those IP's is bad in the same way blocking Tor is.
Yes, you can likely pick a US exit to see 'some' US content or otherwise get geolocated differently, but that is not defying policy of the remote (exit) site directly.
More precisely, if you are innocent anon tor user or traveler, it is overriding the site's poor assumptions and implementions regarding such policies. (If you are actually subject to silly content restrictions, well lots of users post about that on tor-talk.) Either way, Tor enables such choice to override (that choice is often more thought out and rational than the site's choice to block). And until those poor things are corrected, I'm ok with that and these two new ways of getting around things as well.
I am actually wondering all of a sudden why you think there can be scanning on the outbound IP address.
As before, the Tor users will scan from behind their Tor client to (for these respective new services A and B):
A) find OVPN TCP/1194 open on one IP up or down from each exit's consensus OR_IP.
B) discover that 'what is my ip' does not show the exit's consensus OR_IP.
out of there. There does not have to be any anything listening on that IP address. Hence scanning is not possible.
Yes, you would have to scan only from behind Tor to find these. And the operator should set them up so that they only listen to connections from their OR_IP. And if OVPN cannot be configured without a user:pass it should be tor:tor, or without a common pki key such a key in common should be posted on the wiki.
Note that both client side and server side the OpenVPN can be listening on 127.0.0.1, which just means that:
browser-> ovpn -> tor -> {tornet} -> tor -> ovpn(lo:1194) -> [exit] -> {world}
I'm sorry about term 'localhost' if that implied binding to 127.0.0.1, I mean localhost refers to routing table destinations that are local to the box (interfaces/aliases), not explicitly 127/8 addresses.
In fact, the relay operator must not bind OVPN to 127.0.0.1 since: - the user's host is using that address and has the route to it - tor's exitpolicy blocks that by default
You also have to open *:1194, IP:1194, or IP:* in your exitpolicy to reach that 1 up/down IP, lots of exits have that *:1194 already. I would not use the latter two forms because no one has them today.
But, as you are sending Raw IP packets, all anonymity properties that Tor normally gives you are gone.
This is not true about 'anonymity', my diagram is clear on that. All user traffic is encrypted as normal over a full tor circuit. Ovpn is run privately on top of that... from the users host to barely past the exit tor daemon itself. You are sending encrypted openvpn packets over already established tor and terminating on a friendly ovpn endpoint. That is not insecure or non-anonymous.
Also, as the amount of users of this setup will be in the low 10s
We cannot know that, especially when it becomes more known to be deployed/available. And metrics.tpo says there are estimated 2.5M users currently, thousands of bridge users, Nx100k daily country users, etc. 10's would seem an actual underestimate of potential usage.
this special exit IP address will only have those 5 users, hence it is VERY easy to see which user it is. At least you can map it to 5 users.
No, a website/service cannot confirm an individual user based on source IP alone. They can only confirm based on username or well characterized/unique emissions of the user.
Further, some Tor users already manually lock their exit IP, they already know these issues. And these new tools are manual opt-in's. It has no bearing on other Tor users.
anonimity property [of users via tor]
Anonymity comes, in part, from how users manage their session metadatas, exits, usage patterns, account structures, etc... not from use of Tor alone. Some users only, and safely, use the parts of the entire picture that suit their particular needs.
The issue you represent is one of users: - Foremost, using an account on a site (tor doesn't help there either) - Choosing not to rotate their apparent exit IP in conjunction with said account.
This is not a weakness on our part. It is their choice to utilize our extended exit IP services as suits their needs. I see no issue here.
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.
If they do so, TorDNEL will properly list that IP address as it should be doing.
And if TorDNSel does not happen to be in use by the blocker, then this method wins for Tor users who would otherwise be affected and we should add it based on that win.
You should have just deleted their account, but whatever.
So that they can sign up again and start the abusive behavior from the start?
This is a known possibility, so add other defenses in depth. Many of which have been suggested by people in other threads. Some ideas are now on the wiki.
In your proposal those "extra" IPs will just be blocked next.
At least they won't be in the consensus, thus unlikely to happen to be blocked as quickly, or automatically, such as through things like CloudFlare and/or other consensus scraping BL's. The error messages on ListOfServicesBlockingTor should clue you that these are not being blocked manually, but through dumb BL plugin services somehow. It would be interesting project to track the consensus blocking speed vs. the blocking speed of this new hidden IP's. That alone merits deployment of these new ideas in order to research blocking further.
And like Mirmir hinted, dispose of these IP's as need be. Nothing wrong with a little arms race if it helps you win in the end :)
just specify the exit IP or use a TCP-proxy if you don't want them to show up in the TORBL.
The traditional exit IP is in the torDNSBL, so it does not help to specify one of those.
And there is a difference, this service would be run by supporting relay operators and thus would be 'legal' for tor users to use. Open 'TCP-proxy' lists are often populated with proxies that don't know they are proxies, so that is problematic for users to use and an abuse of the 'open' proxy.
TLDwtR:
I don't reply further to cool kid talk. Anyway...
I've made the starting reasons and technical diagrams, relay operators are free to implement them as they wish. On behalf of innocent Tor users, I hope that some of them do. And that some announce doing so in order to increase awareness.
[Prior suggestion was to not list these anywhere and just let users find them only by scanning. I now suggest listing some fraction of these new exit IP's on the wiki, mostly for ease of use. ie: If you set one up, roll a 6 sided dice, if you get a '1' or a '2' then list your ovpn node on the wiki.]