On 2014-05-14 01:54, grarpamp wrote:
On Tue, May 13, 2014 at 5:48 PM, Jeroen Massar jeroen@massar.ch wrote:
Thank you for suggesting the GFW folks now scan and/or directly block these IP addresses too.
The gfw is going to do what the gfw does. And many times that is dedicated to blocking access to tor, not access from tor, obviously, as once you have access, the exit is out of reach of gfw.
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.
If you don't want to be blocked by gfw, don't run this openvpn extension service on your node/ip.
If GFW can detect it, any other adversary can do so too.
As you are not defending against GFW, which adversary do you have in mind? What is the problem you are running into?
You are mixing the difference between an operator of a site selecting who their viewers are and a man-in-the-middle selecting that for both the user and the server. Don't mix those up.
No I'm not. I'm combining them.
Hence, you are mixing them.
Whether site op blocks an IP in its Apache/ipfw or subscribes to a service to do the same is immaterial to this countermeasure of ours.
Define "ours".
The Tor Project provides various ways to be able to detect a Tor-exit, eg: https://www.torproject.org/projects/tordnsel.html.en
This service is there so that operators of sites can decide if they want to serve anonymous users or not.
Note that that is there to reduce the amount of abuse, and thus the global and full blocking of Tor. Typically an operator will only block registration through Tor, while allowing logins through Tor.
We see them blocking legit users who complain about it,
Who is "We"? Which users complain, and about what exactly?
so we act to allow them alternative access.
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. By trying to avoid blocks that way, you will only give a bad name to Tor and other similar projects.
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.
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... not bypassing a bad operator.
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 am pretty-much-completely pro-Tor as there are good uses, but for controlling who logs in and who abuses you, Tor is a bad thing as you don't know what the source is. As an operator of a (server) site, being able to say "sorry, we do not accept connections from Tor" is a good thing, as there are situations where that is needed.
You just stated "[users] who 'log in' to sites", therefore you already have the tools you need... block the abusive account. Tor has nothing to do with it.
Tor and other "open proxies" have a lot to do with abusive users. Typically they come hand in hand.
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.
There is a list of these kind of services here: https://trac.torproject.org/projects/tor/wiki/org/doc/ListOfServicesBlocking...
Attempting to bypassing those restrictions will only cause them to block that method too, and IMHO with good reason.
Yes, blocklists could try the 'one IP up/down' scan method and list this project of ours too
As it can be done automatically, it is not "more work" for them.
I beg to you that it will be substantial work such certain subsets of them will not engage in it. Furthermore, they are bound to certain legalities which may prevent them from doing such scanning/testing. Either way, it is an advance of the art on our part.
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?
You do not need to participate if you do not wish.
And actually, they are likely already scanning every IP in the /24 where
No, what would they [gfw] scan for if they already have the consensus. And we are not talking bridges here, they can already poll for those. This scanning /24 topic is all moot, might as well scan for open 8080, etc. Again we are not talking about gfw or access to tor.
You totally avoided to state in your message that all you are about is circumventing a sites blocking of you. And likely that block is in place as you abused it? So, what site is it and what did you do to it?
Instead of doing OpenVPN (which Wireshark knows and thus is easily detected by port number but also protocol itself), look at the variety of Pluggable Transports[1] people have been developing and deploy these.
Umm, blocklists and/or site ops don't have access to your localhost to sniff it. PT is irrelevant on localhost as well. You do not understand the model to deploy here...
<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
Note that you are running IP over TCP over Tor (which is over TCP). The performance of that will be very bad. Tor network is already overloaded enough as it is.
As for the ovpn part on the right, you could just let your Tor exit node exit on a different IP instead.
The setup you describe above is something outside of Tor though, as you are effectively doing VPN over Tor, 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).
Of course, using BridgeDB is a good thing there to publish these details, or you could invent some new method of passing details to people (puzzle game solving ala captchas being a good start though defeatable by having slaving-away people getting paid for solving them).
In OP I suggest with reason not publishing them at all, the whole point is to *not* let the openvpn ip's be easily scraped like OR_IP are,
BridgeDB is not (well, it is not supposed to be) easily scraped.
See https://bridges.torproject.org/ for the details.
as a countermeasure, so let users scan for these new termination points.
How is "scraping" different from "scanning"; either is automatable and both are already being done. As such, you solve no problem, except for some hidden agenda that you might have.
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.
Greets, Jeroen