Re: [tor-relays] Remove From LIST
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
Re: [tor-relays] Ops request: Deploy OpenVPN terminators
On Tue, May 13, 2014 at 8:40 PM, Andy Isaacson 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
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
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 5:48 PM, Jeroen Massar 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... -- -- 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
[tor-relays] Remove From LIST
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
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
[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] Linux CVE-2014-0196
> > > > I received a notice from a server provider to immediatly > > update/upgrade/reboot if I would use Debian. It's the CVE-2014-0196 issue. I > > did and it came up with Wheezy 3.2.57-3+deb7u1 which should be fine. How > > relevant is this issue? > > From what I gather, you're only affected if you're not the only user in the > box. If you run a system dedicated only to tor, you should be safe. > I understand from what you say and what I read. At least a good chance for an update. Thanks, Felix ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Linux CVE-2014-0196
On 2014-05-13 20:11:28 (+0200), zwie...@quantentunnel.de wrote: > > I received a notice from a server provider to immediatly > update/upgrade/reboot if I would use Debian. It's the CVE-2014-0196 issue. I > did and it came up with Wheezy 3.2.57-3+deb7u1 which should be fine. How > relevant is this issue? From what I gather, you're only affected if you're not the only user in the box. If you run a system dedicated only to tor, you should be safe. -- David Serrano GnuPG id: 280A01F9 signature.asc Description: Digital signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] Linux CVE-2014-0196
Hi I received a notice from a server provider to immediatly update/upgrade/reboot if I would use Debian. It's the CVE-2014-0196 issue. I did and it came up with Wheezy 3.2.57-3+deb7u1 which should be fine. How relevant is this issue? Felix ==-- - - - - - - - - - - --== -BEGIN PGP PUBLIC KEY BLOCK- Version: GnuPG v2.0.22 (MingW32) mQENBFL/5VoBCAC8l2gGmuy2hZf866dDkwzOvMkyJlfnFZU6T5LWe4uPIx0a8R1U cmj/Vut2yUCaJgvFpdOVA3mmXC58zoDeiW7Um6q6otD6BR2hXdgyBTAgqkQ0BsYx epb4UXBz/u3TJmv655fBnXeDgCB8L5BIkcsmX6EoBNUs6a3TPMhX3UXOtEKLXJeZ 2QtoDxwXqHNSmW7jLq+qkpriVDqxDTFv+muZRE+Zn/6PZpEASvpSdVdT/1giEMUL QQFIP6cBPY2GYIaNCO1dYRj9ebM7ewWjCiOiOw6/eylxan8vfFntgaPU3J7W2wJp RiRtUIjT+TDycVyNk7gy4wV2Rj8+58+Krk1tABEBAAG0IEZlbGl4IDx6d2llYmVs QHF1YW50ZW50dW5uZWwuZGU+iQE5BBMBAgAjBQJS/+VaAhsPBwsJCAcDAgEGFQgC CQoLBBYCAwECHgECF4AACgkQC2jb92rYqyMGxQf/d9oJf0qpgXZaUmcqujQ3DVsc uvYOnK2MJCpDIvvZYdQTcnG2jz8/na1ZyfAGeKhYZ18ypONwSQYthC17L5GHQ2H3 Pg/H0GARtx4aJR5TtIKnhPR8yYdlikCuTBb5QSFJUUtEz91SqDW7EXNbMC4RRSEd BWWirADCJWitoR3JCC13r+CF6TCFDluClAht/t56f7prBzARVYWmlbgYD2yx4Uzs FOl0vvhW2o9dpVaLZ6mSHAyNzefCFcNumRUxqa+V6nY94dd8BV8xH0lOd1xaMtZW HuxIU9Sbh13OlJyBAvVffVBL+4sEOpc8XB6Yl/pmyjEjUSvC7lP3T+Ix9Mnk/A== =kfXw -END PGP PUBLIC KEY BLOCK- ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
