[tor-relays] Ops request: Deploy OpenVPN terminators

[Jeroen Massar]

On 2014-05-14 01:54, grarpamp wrote:
> On Tue, May 13, 2014 at 5:48 PM, Jeroen Massar <jeroen at 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/ListOfServicesBlockingTor

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