Re: [tor-relays] Ops request: Deploy OpenVPN terminators
On Thu, May 15, 2014 at 9:36 AM, Jeroen Massar jer...@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,
Re: [tor-relays] Ops request: Deploy OpenVPN terminators
On Monday, June 16, 2014 2:29 AM, grarpamp grarp...@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.___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Ops request: Deploy OpenVPN terminators
On Mon, Jun 16, 2014 at 12:59 PM, Bogglesnatch Candycrush bogglesna...@yahoo.com wrote: On Monday, June 16, 2014 2:29 AM, grarpamp grarp...@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. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Ops request: Deploy OpenVPN terminators
On 6/16/14, grarpamp grarp...@gmail.com wrote: On Thu, May 15, 2014 at 9:36 AM, Jeroen Massar jer...@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 ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Ops request: Deploy OpenVPN terminators
Jeroen Massar jer...@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 ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Ops request: Deploy OpenVPN terminators
On Tue, May 13, 2014 at 8:27 PM, Tom Ritter t...@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. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] 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.] ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Ops request: Deploy OpenVPN terminators
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 ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Ops request: Deploy OpenVPN terminators
On Tue, May 13, 2014 at 5:48 PM, Jeroen Massar jer...@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. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Ops request: Deploy OpenVPN terminators
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 ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Ops request: Deploy OpenVPN terminators
On Tue, May 13, 2014 at 05:09:50PM -0400, grarpamp wrote: Ops request: Deploy OpenVPN terminators Anecdotally, the GFW blocks OpenVPN endpoints as well. -andy ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Ops request: Deploy OpenVPN terminators
On Tue, May 13, 2014 at 8:40 PM, Andy Isaacson a...@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. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
