It’s currently difficult for bridge operators to keep up with the changes in pluggable transports world. You’ve to be following tor development and censorship-war very closely to know which transport is needed currently and how to run them.
There are many people who are still running vanilla bridges thinking they’re helping people in censored networks. Unfortunately those bridges are not anyone any good while burning operator’s resources.
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.
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
and then it will automatically get the most recommended PT (eg obfs4), tor itself (if not installed), config your torrc, do a reachability test, publish the bridge to bridgdb automatically and give you the result in stdout:
# Congrats! your bridge is up and running on $port # Your bridge is published in BridgeDB. # Thanks for fighting censorship!
Additionally we can have more flags for different transports, ip, port and so on. For example if you want to run obfs4proxy on an specific port and not publish it, I imagine running something like this should get you there:
$ tor-bridge-setup —-private —-obfs4 —-ip 1.2.3.4 —-port 5000
# Congrats! your bridge is up and running on port 5000 # You have chosen to not to publish your bridge. Users would need to manually copy and paste the following line in their Tor Browser to use your bridge. # # bridge obfs4 1.2.3.4:5000 C73ADBAC8ADFDBF0FC0F3F4E8091C0107D093716 cert=gEGKc5WN/bSjFa6UkG9hOcft1tuK+cV8hbZ0H6cqXiMPLqSbCh2Q3PHe5OOr6oMVORhoJA iat-mode=0
The purpose of this email is to see whether this is a good approach (if not, how can we improve it), and what is needed to move towards it.
Feedback from everyone, specially packagers and relay operators are encouraged and welcome :)
Best,
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
Tom
Op 30/06/16 om 21:15 schreef Nima Fatemi:
It’s currently difficult for bridge operators to keep up with the changes in pluggable transports world. You’ve to be following tor development and censorship-war very closely to know which transport is needed currently and how to run them.
There are many people who are still running vanilla bridges thinking they’re helping people in censored networks. Unfortunately those bridges are not anyone any good while burning operator’s resources.
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.
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
and then it will automatically get the most recommended PT (eg obfs4), tor itself (if not installed), config your torrc, do a reachability test, publish the bridge to bridgdb automatically and give you the result in stdout:
# Congrats! your bridge is up and running on $port # Your bridge is published in BridgeDB. # Thanks for fighting censorship!
Additionally we can have more flags for different transports, ip, port and so on. For example if you want to run obfs4proxy on an specific port and not publish it, I imagine running something like this should get you there:
$ tor-bridge-setup —-private —-obfs4 —-ip 1.2.3.4 —-port 5000
# Congrats! your bridge is up and running on port 5000 # You have chosen to not to publish your bridge. Users would need to manually copy and paste the following line in their Tor Browser to use your bridge. # # bridge obfs4 1.2.3.4:5000 C73ADBAC8ADFDBF0FC0F3F4E8091C0107D093716 cert=gEGKc5WN/bSjFa6UkG9hOcft1tuK+cV8hbZ0H6cqXiMPLqSbCh2Q3PHe5OOr6oMVORhoJA iat-mode=0
The purpose of this email is to see whether this is a good approach (if not, how can we improve it), and what is needed to move towards it.
Feedback from everyone, specially packagers and relay operators are encouraged and welcome :)
Best,
tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
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,
Op 30/06/16 om 21:31 schreef Nima Fatemi:
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,
Oops, should probably have elaborated a bit more.
You can combine conf.d with the meta-package. For example, when you run "yum install tor tor-bridge" the tor-bridge package could bring in obfs4proxy with it and automatically configure that : $ yum install -y tor tor-bridge $ systemctl start tor
--------------
The challenge, imho, is figuring out how to handle upgrades. A virtual package like the tor-bridge in my example would automatically pull in obfs5proxy, leaving obfs4proxy intact, but this may be considered bad behavior to the user, as it may also need firewall changes etc.
Questions that would need answering :
* Is it acceptable to automatically install newer transports? * If it is, should we automatically deprecate the older transports? And in that case, can we maybe just replace the old transport with the new one while reusing the port? Will that break UX for the user who actually set it up, as it now has a different type of proxy on the same port? * If it is not, how to we notify the user that they should renew their setup? * Most users don't compile Tor from scratch, but use packages that come with distributions such as Ubuntu, Debian and CentOS. How do you properly integrate with those?
Tom
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
Hi,
On 06/30/2016 04:43 PM, Tom van der Woerdt wrote:
The challenge, imho, is figuring out how to handle upgrades. A virtual package like the tor-bridge in my example would automatically pull in obfs5proxy, leaving obfs4proxy intact, but this may be considered bad behavior to the user, as it may also need firewall changes etc.
I wouldn't worry for that at the moment as pluggable transports are not being updated that often. Commit logs: obfs4proxy - https://github.com/Yawning/obfs4/commits/master fteproxy - https://github.com/kpdyer/fteproxy/commits/master obfsproxy(2,3), scramblesuit - https://gitweb.torproject.org/pluggable-transports/obfsproxy.git/log/obf sproxy/transports
Questions that would need answering :
- Is it acceptable to automatically install newer transports?
Installing newer pluggable transports doesn't mean that the tor bridge configuration will need to immediately since changes will be needed to the torrc, perhaps we could let the user decide by entering in a ncurses menu and selecting the desired transport(s) and options for each of them.
- If it is, should we automatically deprecate the older
transports? And in that case, can we maybe just replace the old transport with the new one while reusing the port? Will that break UX for the user who actually set it up, as it now has a different type of proxy on the same port?
I think it's of highly importance to keep the older transports active, so again we could let the user decide.
Additionally a user could set a selection and provide only upgrades/changes bases on the select transport(s) and private/public visibility.
- If it is not, how to we notify the user that they should renew
their setup?
By using the ContactInfo of the bridge?
- Most users don't compile Tor from scratch, but use packages that
come with distributions such as Ubuntu, Debian and CentOS. How do you properly integrate with those?
At this point it makes more sense to develop an install "recipe" in a software deployment component with minimal dependencies such as Ansible.
We could aim to package the missing pluggable transports for most/all distributions out there but this could take some significant amount of time depending on the distribution's policies and package dependencies.
~Vasilis - -- Fingerprint: 8FD5 CF5F 39FC 03EB B382 7470 5FBF 70B1 D126 0162 Pubkey: https://pgp.mit.edu/pks/lookup?op=get&search=0x5FBF70B1D1260162
-----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&search=0x5FBF70B1D1260162
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
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
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.
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
-
Dafwig -
Nima Fatemi -
Tom van der Woerdt -
Vasilis -
Ximin Luo