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
