[tor-relays] Ops request: Deploy OpenVPN terminators

[grarpamp]

On Thu, May 15, 2014 at 9:36 AM, Jeroen Massar <jeroen at 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.]