[tor-relays] Ops request: Deploy OpenVPN terminators

[grarpamp]

> On Tue, May 13, 2014 at 5:48 PM, Jeroen Massar <jeroen at 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.