Re: [tor-relays] Ops request: Deploy OpenVPN terminators

[grarpamp <grarpamp@xxxxxxxxx>]

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

If you don't want to be blocked by gfw, don't run this
openvpn extension service on your node/ip.

> 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. 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. We see
them blocking legit users who complain about it, so we act
to allow them alternative access. They can then move to account
based and other finer grained user management models. 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 don't have to run described openvpn extension if you
don't want.

> 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.

>> 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.

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.

> 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

> 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, as a
countermeasure, so let users scan for these new termination points. But
absolutely yes, if you feel some reason to have to DB them do not ever
publish them in something dumb and easy scrapeable like consensus
or website list. Other relay ops will not even inform such DB that they
are running them, exactly so they can't be scraped and must be scanned
for.

You do not have to run this, other relay ops will see value and will.
_______________________________________________
tor-relays mailing list
tor-relays@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays