Ops request: Deploy OpenVPN terminators
Ops request: Deploy OpenVPN terminators We are ops because we want to allow people to avoid censorship and speak freely. But are we doing all we can? It is well known that all relays, exit or non-exit are added to a variety of blocklists. Primarily through scraping the consensus. And those blocklists are then used to indiscriminately deny legitimate users/people access to sites, regardless of their 'behaviour', which more often than not has simply not been determined yet. So we need to augment what we're doing in order to be effective in our mission. Here's how... We already run Tor on an IP, that IP is blackballed as noted above, so using another port on it as a vpn terminator is pointless. Yet our hosting packages often offer other IP's in the same range, or we already have them to use as part of the deal (or, failing that, we can forward the openvpn TCP port on our bad relay IP to another clean non-bulk-blocked IP we control). We obviously cannot publish this new openvpn 'exit/termination' IP anywhere, such as in the comment field of the consensus as it will be banned. *But we can bind to it and let users find it with their own openvpn scans close to (one up or down from) our OR IP.* Just use the standard openvpn TCP port on it. There is no bandwidth cost to us to do this because all the traffic is moved between the exit IP and the openvpn termination IP over localhost. (Well, unless you are forwarding openvpn port on OR IP to another termination real IP off your box.) At minimum we should allow TCP transport out from the vpn to the world, aka the usual nat, so as to make websurfing work for our users. Bonus for allowing nattable outbound UDP, ICMP, etc. Further bonus for allowing inbound binds on whatever port on the IP that is available to be bound to. Obviously sine the IP is scarce to us, we can't allow full unnatted use of the IP. The point is, we already own these extra IP's, and legitimate people are being blocked from services for no reason other than kneejerk or blind reactions to Tor via blocking services. Ahem, cloudflare, et al and other blocking 'services' well known to us. So to the extent we have other IP's available to us, we should set them up to be unpublished openvpn nodes and let users find us by trying to terminate their vpn connections on us at that IP and openvpn port. Yes, blocklists could try the 'one IP up/down' scan method and list this project of ours too, but it's more work for them and they're unlikely to do it in any sort of global fashion. Especially since they can't prove it's part of Tor (because we don't publish the IP's as such). If we wish to make an announcement that we are running such terminators, obviously it should not be made from addresses related to our OR IP's. [FWIW, there is another openvpn terminator project out there. Unlike ours would be, its nodes are public, and even with that detriment (though possibly only because it is lesser known) it obtains more freedom from blocklisting than Tor. However its termination points perform poorly/unreliably whereas ours would be both nonpublished and better managed.]
On 2014-05-13 23:09, grarpamp wrote: [..]
*But we can bind to it and let users find it with their own openvpn scans close to (one up or down from) our OR IP.* Just use the standard openvpn TCP port on it.
Thank you for suggesting the GFW folks now scan and/or directly block these IP addresses too. [..]
The point is, we already own these extra IP's, and legitimate people are being blocked from services for no reason other than kneejerk or blind reactions to Tor via blocking services. Ahem, cloudflare, et al and other blocking 'services' well known to us.
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. 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. [..]
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. And actually, they are likely already scanning every IP in the /24 where a relay is located (well, actually they just scan the whole IPv4 space anyway, with zmap it is done very very quickly)
but it's more work for them and they're unlikely to do it in any sort of global fashion. Especially since they can't prove it's part of Tor (because we don't publish the IP's as such).
If the address space (eg the /24) does not contain anything "normally useful" they will just block it based on that. 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. They are typically scan and protocol analysis resistant which will give much better bang for your buck. 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). Greets, Jeroen [1] = https://www.torproject.org/docs/pluggable-transports.html.en
Hi Tor, Please remove my email from the lists.torproject.org Eric
On 14-05-13 07:34 PM, Eric Giannini wrote:
Hi Tor, Please remove my email from the lists.torproject.org Eric
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Please consider adding a phrase such as "To remove yourself from the list or see archives, visit the below link:" just above the url.
Actually, there is a great description on "How to unsubscribe from a mailman mailinglist" available. Maybe link this in the footer section. http://article.gmane.org/gmane.network.opennms.general/7202 Regards, Sven. -- PGP Key: https://0x80.io/pub/files/key.asc PGP Key Fingerprint: 2DF2 79CD 48DD 4D38 F0B6 7557 2E68 D557 49AA 1D99 Note: I'll be transitioning away from this key in the near future. On 05/14/2014 04:17 AM, krishna e bera wrote:
On 14-05-13 07:34 PM, Eric Giannini wrote:
Hi Tor, Please remove my email from the lists.torproject.org Eric
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Please consider adding a phrase such as
"To remove yourself from the list or see archives, visit the below link:"
just above the url.
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
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. 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.
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
This seems very similar to the idea of having private exit nodes: https://www.torproject.org/docs/faq#HideExits It's also easy to enumerate Exit IPs not by scanning up/down, by just building a circuit through every exit node to a server you control, and looking at the originating IP. -tom
On Tue, May 13, 2014 at 8:27 PM, Tom Ritter <tom@ritter.vg> wrote:
This seems very similar to the idea of having private exit nodes: https://www.torproject.org/docs/faq#HideExits
Tor daemon must of course know its exit OR ip's+ports via some mechanism (currently, distributed consensus), or Tor would not work. There is no such thing as private exits in that context. Every anon protocol learns its own peers somehow. Running OpenVPN terminators on your exit box on a different ip than your tor exit is unrelated to Tor itself. It is an extra/enhanced service relay operators would choose to provide on their own.
It's also easy to enumerate Exit IPs not by scanning up/down, by just building a circuit through every exit node to a server you control, and looking at the originating IP.
Given that very few exit relays exit via an IP not in the consensus, enemies of tor do not have to scan or build, they can just look at the consensus. This is not relevant to the context of this proposal.
On Tue, May 13, 2014 at 8:40 PM, Andy Isaacson <adi@hexapodia.org> wrote:
Anecdotally, the GFW blocks OpenVPN endpoints as well.
You need to specify context... access *to* ovpn nodes?, which is moot because that is not the deployment specified here in diagram... you already guaranteed access via the localhost exit you can already reach, (or via the exit op's clear forward path to their off exit box ovpn node). Or *from* ovpn nodes?... well as before, if your node is in gfw area trying to get out, or is outside trying to get in, it really doesn't matter, gfw will block exit or ovpn as it will. So, this is not about such gfw things. It's about enabling quite some other users other means to get around silly ip based blocklists derived from the consensus, the tor dns query thing, or poor management models by the site the user wishes to access, etc. We provide tor exits exact so users can get around stuff, so adding in an ovpn on a spare ip is no philosophical difference there. Yes, it is a fuck you to old way of playing nice by saying "here's all our public nodes, block us", and it might cost $few more a month for the ip, and eat some cpu on localhost, but that's about it. If it helps some users it's worth doing, to each operators own desire. 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.
On 2014-05-14 03:58, grarpamp wrote:
On Tue, May 13, 2014 at 8:40 PM, Andy Isaacson <adi@hexapodia.org> wrote:
Anecdotally, the GFW blocks OpenVPN endpoints as well.
You need to specify context... access *to* ovpn nodes?, which is moot because that is not the deployment specified here in diagram...
That was not the setup you described originally. The diagram that you included makes your intentions much clearer. 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. [..]
It's about enabling quite some other users other means to get around silly ip based blocklists derived from the consensus, the tor dns query thing, or poor management models by the site the user wishes to access, etc.
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. Trying to circumvent that will just cause more blockage there, noting it is much easier to do so for such an operator and in their full right (if you like it or not).
We provide tor exits
Who is "we" here? I am fairly confident you do not speak for any kind of majority of exit node operators. Note that most exit nodes have a port and network blocks themselves to avoid them from being abused.
exact so users can get around stuff
What site is it again that you are trying to circumvent? Did you list it on: https://trac.torproject.org/projects/tor/wiki/org/doc/ListOfServicesBlocking... or is it some private thing you are banned from?
so adding in an ovpn on a spare ip is no philosophical difference there.
There is a HUGE difference. As noted above, 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'.
Yes, it is a fuck you to old way of playing nice by saying "here's all our public nodes, block us",
You clearly do not understand why the DNSEL is published. Please read up on it.
and it might cost $few more a month for the ip, and eat some cpu on localhost, but that's about it. If it helps some users it's worth doing, to each operators own desire.
OpenVPN, especially in crypted mode, requires quite a lot more CPU power on the nodes running OpenVPN node. Next to that, due to the overhead of IP over OpenVPN-TCP which then goes over Tor, your performance will be really bad. 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.
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? Greets, Jeroen
On Tue, May 13, 2014 at 5:48 PM, Jeroen Massar <jeroen@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/ListOfServicesBlocking... 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.
On 2014-05-15 05:06, grarpamp wrote: [..big snip skipping over the complete nonsense..] TLDwtR: the proposed setup breaks all anonymity (OpenVPN sends Raw IP packets) + few users will ever use this, few random exits will support it, thus 1:1 mapping for the few people who will use it. Only reason why this is being asked: circumvent site policies where the operator has already had enough problems with random Tor users and other proxies defying their access policy. [.. moved from the reply up here as it is useful ..]
I run services, they are account based, and I refuse to block access to me via tor exits.
If you want to make a positive contribution, please detail how exactly you handle abusive users, make a good post about this somewhere (and link it from the blocking services page) and when you encounter a site operator that for you "wrongly blocks Tor" ask them to reconsider based on your proposal. Greets, Jeroen --- further blurb... [..]
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.
Even though you are guessing that other people, who operate a site, don't make a "balanced and thoughtful decision", it is not for you to attempt to circumvent that decision. That is like saying "they should not have connected it to the network at all if they did not want me to access it" or "hey look the space shuttle designs, they should not have allowed me to exploit that hole to get access to it". If an operator does not want you on their site, do not circumvent it. It will only cause more problems for other people who are allowed access to it.
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?
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.
And still, as the operator does not want anonymous users, you will have to abide by that. As an example: a service like Netflix. They can provide content because the "owners" of that content allow them to do so in certain jurisdictions. Bypassing those rules might cause the "owner" of the content to drop Netflix as a service. Hence, if you are bypassing the regulations that Netflix has put in place, you might damage the content availability for all those users. Did it help you to be anonymous? Not really. Did it damage lots of people who played ball, definitely.
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.
Obviously you are accessing sites who had problems with Tor users abusing the functionality of the site. Not unlogical that they thus classify that access as bad. What would you do if it was your site, let them run rampant on your site or make it easy: filter those users out? As they are anonymous there is little way to differentiate between user A and user B and if the majority coming through whatever-open-proxy is being malicious, then it is a good thing to block them. [..]
Tor's encrypted circuits give source anonymity.
And that is the primary intent of Tor.
Tor's exits (or this OpenVPN/binding) give the ways around things.
That is NOT an intent of Tor.
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.
You are thus stating: I want to circumvent a site's decision to block me. That is not a target of Tor. Please, don't abuse it as such. Please, go abuse some Open Proxy somewhere like most people do.
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.
Tor users are typically not bad actors. But there are always the people who do do so and thus cause damage for the normal people who really do just want to be anonymous. [..]
You are trying to defy policy of a site...
Tor ITSELF is trying to defy all manner of policies, this fits that just fine.
It might "defy" a policy to get access to the Tor network (ingress) to give you anonymity, but Tor itself does not give you the ability to defy the policy of the site one is connecting to (exit). 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.
not bypassing a bad operator.
This makes no sense. I never said relay ops were bad.
'operator' in that sentence context is that of "ISP operator", eg that big old lovely Chinese firewall.
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.
I am actually wondering all of a sudden why you think there can be scanning on the outbound IP address. Thus say that the 'exit' IP from OpenVPN is 192.0.2.1, thus all traffic coming out of your setup comes out of there. There does not have to be any anything listening on that IP address. Hence scanning is not possible. 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} Hence, no listening addresses needed at all on the [exit] IP. Hence, no scanning or discovery that way either. Indeed TorDNSEL won't get that special exit IP as well, it does not know about you tunneling OpenVPN over Tor. But, as you are sending Raw IP packets, all anonymity properties that Tor normally gives you are gone. Also, as the amount of users of this setup will be in the low 10s, let say 5, and likely even less, 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. Remember, with real normal exits, nobody knows how many users there are as it is a mixnet. Thus 10 mbit of traffic might be 1 or 100 or 1000 users. Hence, why are you using Tor again? It does not seem to be the anonimity property you care about that much.
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.
Thank you for calling most Tor users "moronic masses". See above, you lost all your anonymity properties. Please simply do not use Tor. You give the rest of the users a bad name.
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!!!
Please indeed abuse those resources instead, they better fit your purpose.
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.
I've never stated anything in that direction, quite the contrary.
Have you visited your local coffeeshop or home lately, how many of those teenage freeloaders are bad. No difference, maybe even worse incidence.
Everybody is aware that one is semi-anonymous[1] in a Starbucks. But that is not a problem to do with Tor is it? [1] your computer will show all traces of you though, thus too late.
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.
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.
You obviously have never run a service of any size that had to deal with that kind of abuse. IP based blocking is the easiest and best method as it takes care of most of the abusers. Please look at Wikipedia, they are pretty open about how they block things. [..]
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.
If they do so, TorDNEL will properly list that IP address as it should be doing. [..]
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.
Of course it can. For the traffic out of OpenVPN to go anywhere it is either using a real IP address or doing NAT. Voila, Raw IP. Or are you connecting through another TCP based proxy inside the OpenVPN VPN? [..]
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.
Far from. Please watch "The Net" and other such funny movies where they "hack into each IP" and "trace the user around the world". Please read up on Mix Networks, eg https://en.wikipedia.org/wiki/Mix_network That explains the background concept of Tor and that if you have a 1000 users you will not know which source belongs to which.
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.
Indeed, you will make sure that they will never want to have any Tor users at all, as clearly their intent is to circumvent their blocks.
On clearnet you as a service op when you block an ip are usually taking out just one user.
Ever heard of NAT? Especially with 3G exit IPs or the fun with DSLITE, there will be a lot more than one single person behind it.
You should have just deleted their account, but whatever.
So that they can sign up again and start the abusive behavior from the start?
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.
Because for most operators there is no difference. In your proposal those "extra" IPs will just be blocked next.
That, in my opinion, is WRONG.
While you might think that, it is THEIR site, thus for them to decide. [.. moved up..]
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.
Please read: https://www.torproject.org/about/sponsors.html.en and contribute. If you make a large enough donation you can ask for your own milestones: https://trac.torproject.org/projects/tor/wiki/org/sponsors
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.
Instead of OpenVPN, which is Raw-IP, just specify the exit IP or use a TCP-proxy if you don't want them to show up in the TORBL. Saves on the overhead and avoids losing anonimity features.
Jeroen Massar <jeroen@massar.ch> once said:
Even though you are guessing that other people, who operate a site, don't make a "balanced and thoughtful decision", it is not for you to attempt to circumvent that decision.
That is like saying "they should not have connected it to the network at all if they did not want me to access it" or "hey look the space shuttle designs, they should not have allowed me to exploit that hole to get access to it".
If an operator does not want you on their site, do not circumvent it. It will only cause more problems for other people who are allowed access to it.
By this logic, support for pluggable transports should be removed. Surely if a country or ISP doesn't want Tor users on their network we shouldn't try to circumvent their blocks, right? I don't buy it. I'm glad that people are thinking about censorship resistance for both ends of a Tor circuit. Anthony
On Thu, May 15, 2014 at 9:36 AM, Jeroen Massar <jeroen@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.]
On Monday, June 16, 2014 2:29 AM, grarpamp <grarpamp@gmail.com> wrote:
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
It seems to me in this case the OpenVPN endpoint would know who the user is, based on their OpenVPN client certificate or shared secret. Even absent those, they might be able to do packet fingerprinting, since the packets won't be scrubbed.
On Mon, Jun 16, 2014 at 12:59 PM, Bogglesnatch Candycrush <bogglesnatch@yahoo.com> wrote:
On Monday, June 16, 2014 2:29 AM, grarpamp <grarpamp@gmail.com> wrote:
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
It seems to me in this case the OpenVPN endpoint would know who the user is, based on their OpenVPN client certificate or shared secret. Even absent those, they might be able to do packet fingerprinting, since the packets won't be scrubbed.
'know who the user is' ... you need to precisely define that. know their location [real ip]? - No, Tor protects them from that. know it's the same recurring OVPN nym? - Not if OVPN is setup to use ephemeral keying or a single shared secret posted on the wiki. know their name? - Any exit can sniff users at the tor daemon, OVPN or not. know their traffic? - Any exit can sniff users at the tor daemon, OVPN or not. scrubbing? - There is some visibility to the 'raw' tunneled packets from the user's stack. Similar to OnionCat, or to how browsers 'Panopticlick'... we should document that so that users can make their own choices, we provide an openvpn config file, etc. Ultimately, this essentially brings what would otherwise be third party OpenVPN service to pair with Tor via the exit relay operators model everyone is familiar with today. Other than that it is an external bolt-on after Tor, and it is improper to compare it with the expectations/capabilities of Tor as if it were Tor... they are two completely separate things. It is optional for operators to run one. And optional for users to use one. Another aspect... the consensus is scraped and imported into blocklists because Tor makes no restrictions on such use. And they are unlikely to do so because TPO wants to play nice. Now since maybe only a third of these independantly operated OVPN IP's might be published on the wiki (the die roll thing), the other two thirds must be found by scanning and then used to see if the shared access token works. This OVPN service could be ToS'd as being only for Tor users and not blacklists. Thus any appearance of an unpublished OVPN IP on a BL could be challenged as to its listing source... one such successful case of illlegal access to computer against ToS would send a strong message to BL's not to do that. A rather thin defensive tactic, but it is worth noting how the consensus and OVPN differ in this regard.
On 6/16/14, grarpamp <grarpamp@gmail.com> wrote:
On Thu, May 15, 2014 at 9:36 AM, Jeroen Massar <jeroen@massar.ch> wrote:
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.
This is foundational I say - some of us are willing to give up a little (or a lot) of convenience, for the long term benefits/ freedoms which we anticipate and strive for. Today we have an abundance of libre/free software. When Richard Stallman, and later others, sacrificed their time and their statutory proprietary-ownership possibilities, for the long term vision, they did not have the abundance that has since been created - their sacrifice was MUCH greater than ours today. Yet the spirit of sacrifice/inconvenience for the longer term greater good, lives strongly in some of us. I wholeheartedly support those who live this principle. Rock on! Zenaan
participants (10)
-
Andy Isaacson -
Anthony Martin -
Bogglesnatch Candycrush -
Eric Giannini -
grarpamp -
Jeroen Massar -
krishna e bera -
Sven Reissmann -
Tom Ritter -
Zenaan Harkness