Re: [tor-dev] A meta-package for Pluggable Transports?
Dafwig: > Ximin Luo: >> I made something like this a few years ago: >> >> https://people.debian.org/~infinity0/apt/pool/contrib/t/tor-bridge-relay/ > > A general question, but related to the sample configuration you've > provided here, as well as other instructions I've seen online: > > I've heard that the Chinese government tests suspected bridges by > attempting to connect to them and seeing if they respond to the Tor > protocol. Whether China is actually doing this or not, it would not be a > terribly difficult thing for any competent censor to do. > > So with this in mind, wouldn't it be best for new bridges to support > ONLY obfs4, and not any of the older protocols? > > In particular, it seems like a very bad idea to enable the default > ORPort (9001), unless I'm missing something. Is it actually necessary to > have an open ORPort in order to work as an obfuscated bridge? If it is > necessary, at least that port should be picked randomly to make it > harder for censors to guess. If it's not needed, then that port should > presumably be set to listen only on 127.0.0.1 or similar. > > This isn't mentioned in any of the bridge-related documentation I've > seen, though I haven't looked very hard. > You are quite probably right. The thing I posted was a sample "initial attempt" and not an end product. (Other protocols like snowflake and meek-client might also be OK since they also don't expose a public listen port.) X -- GPG: ed25519/56034877E1F87C35 GPG: rsa4096/1318EFAC5FBBDBCE https://github.com/infinity0/pubkeys.git ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] A meta-package for Pluggable Transports?
> I've heard that the Chinese government tests suspected bridges by > attempting to connect to them and seeing if they respond to the Tor > protocol. Whether China is actually doing this or not, it would not be a > terribly difficult thing for any competent censor to do. It was probably the talk from Philipp Winter at the 32c3. Just for reference on this list or people who find it interesting. I think there is no general answer for what should be the default config/setup for a bridge. Maybe a (ncurses) menu at the install would be the best. The menu could inform new bridge operators about what is good/bad and why or even what types of proxies are currently needed more. Or provide at least a link to a wiki article (which should be written :)) [1] https://media.ccc.de/v/32c3-7196-how_the_great_firewall_discovers_hidden_circumvention_servers ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] A meta-package for Pluggable Transports?
Ximin Luo: > Nima Fatemi: >> [..] >> >> After some discussion on #tor-project a little while ago, the idea of >> having a meta-package that includes all or the most recent transports >> came up. Where people would install this meta package and it would >> automatically take care of the required steps to get the latest >> obfsproxy and set it up. >> >> [..] > > I made something like this a few years ago: > > https://people.debian.org/~infinity0/apt/pool/contrib/t/tor-bridge-relay/ > > I had planned to add a lot more things to it, like what you suggested in the > rest of the email, but never got around to it. > > Someone else could take this as a base to start working from, though. > One reason is because #1922 was never completed. I built the packaging assuming that it would be fixed by the time I finished it, but this hasn't happened yet. X -- GPG: ed25519/56034877E1F87C35 GPG: rsa4096/1318EFAC5FBBDBCE https://github.com/infinity0/pubkeys.git ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] A meta-package for Pluggable Transports?
Nima Fatemi: > [..] > > After some discussion on #tor-project a little while ago, the idea of > having a meta-package that includes all or the most recent transports > came up. Where people would install this meta package and it would > automatically take care of the required steps to get the latest > obfsproxy and set it up. > > [..] I made something like this a few years ago: https://people.debian.org/~infinity0/apt/pool/contrib/t/tor-bridge-relay/ I had planned to add a lot more things to it, like what you suggested in the rest of the email, but never got around to it. Someone else could take this as a base to start working from, though. X -- GPG: ed25519/56034877E1F87C35 GPG: rsa4096/1318EFAC5FBBDBCE https://github.com/infinity0/pubkeys.git ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] A meta-package for Pluggable Transports?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi, On 06/30/2016 04:15 PM, Nima Fatemi wrote: [...] > After some discussion on #tor-project a little while ago, the idea > of having a meta-package that includes all or the most recent > transports came up. Where people would install this meta package > and it would automatically take care of the required steps to get > the latest obfsproxy and set it up. This is an excellent idea and will add up many new plugable transport bridges to the network. Setting and configuring properly a bridge has been quite often an issue for users and sysadmins. > From a UX perspective, ideally you’d set up a bridge with small > and consistent steps like this: > > $ sudo apt-get install tor-bridge $ tor-bridge —-setup OR $ > tor-bridge-setup [...] It makes sense that we add support for various plugable transports (eg: fteproxy and scramblesuit) and versions (obfsproxy2..5) running on a number of ports/IPs. There are cases were censors block only newer versions of plugable transports, but not older ones. ~Vasilis - -- Fingerprint: 8FD5 CF5F 39FC 03EB B382 7470 5FBF 70B1 D126 0162 Pubkey: https://pgp.mit.edu/pks/lookup?op=get=0x5FBF70B1D1260162 -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJXdX/ZAAoJEF+/cLHRJgFixgAQAIa/hRPpdupiShtPuw+Xu+EA p0E8sqnxxHx0oN/oLD0Ga4/aL2DrkHmPkp96ja6EZi2YwileXGtlveGcw4SW2HEE QMh0IMibMqDhUnsDiziUniXyLmwlb25dP7APUvJsvLxO0Z2y9wW/Hm+3k4Yz6dK8 2+RJwPPnhHBtfyem56gKvQVlLMct1+53M3k44VVol5+1b3KxIh47ItGJOlIcIT6h REs3wEWrZRs12vVWoSgG/3a14erYNnBiwqtAmzOLh/9KQvzJtuB7DBayxTzLHzsf pzH+DFBe9EU263MMnPXk/Vl3o3iDl0q6CbxjkQ9jhNdJXtASq/iG58mIFetp+3uS QWXDj7qI5RxrpXtEElvxZtMKyHtcIWHn4xlvfh4sflWUftvjQf4p57Wk23Hew52u BRGnN9KMMGt0lXvOSkUPf1AXB5dj+3JwQZj7R5XgHXxYP3s/PtwDG6z48Ia13Sy3 5e2NqgLeLqeatfuZP3Y5dRDfPDs8pVj7pts7STyzQGFDY2CUl3yB+/3oqhNVGCMf 70c65lpGPj/YT1BgEXYK54/CroHpd87YbSwVjwXLbf7lk9YCi9ZcY5/JTItSQ6eG RYh6jz6AwKy0iHXEs3hSajCirE68qVGvjgkwDRMCmDm9YO/tuuX8L3XeRgkCb7Ku fwmR4hxbXB37+Uu2hAmx =xgsd -END PGP SIGNATURE- ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] A meta-package for Pluggable Transports?
Tom van der Woerdt: > How about a conf.d style folder that plugins like bridges can drop files in? > > $ yum install -y obfs4proxy > ... > $ cat /etc/tor/torrc.d/obfs4.conf > ServerTransportPlugin obfs3,obfs4 exec /usr/bin/obfs4proxy managed > ServerTransportListenAddr obfs4 0.0.0.0:9013 > ServerTransportListenAddr obfs4 0.0.0.0:9014 > $ systemctl restart tor In this case you'd still have to know what obfs4proxy is or when and where to get it. It doesn't solve the problem of the need to catch up with censorship and tor development. And to break a news for you... obfs5 is coming soon. What are we gonna do when that comes out? What do we call the package? This also doesn't help running any other transports like meek. Best, -- Nima 0X58C4B928A3E218F6 | @mrphs "I disapprove of what you say, but I will defend to the death your right to say it" --Evelyn Beatrice Hall signature.asc Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
