On Sun, Aug 12, 2012 at 09:58:54AM +0200, Sebastian G. <bastik.tor> wrote:

You ask volunteers to achieve a funders goal. Those might run a bridge already, but "un-publish" it. Less bridges for the rest. They could run relays and turn them into unpublished bridges. Less relays for anyone.

Running a relay or bridge (published) would be a better contribution IMO.

Hi Sebastian, Thanks for starting the discussion. I totally agree that running a big relay (exit or non-exit) is more directly useful to the Tor network than running one of these unpublished bridges. We're in an interesting situation here, where we can use their bridge funding for other more important things if we don't spent it all on bridges. So maybe the subject should have been the more counterintuitive "Help fund Tor bundle usability by running a fast unpublished bridge". Another option would be to give it to Moritz et al at torservers.net so they can run more fast exits -- at which point Moritz might end up sending a similar mail saying "Help us run more exit relays by running a fast unpublished bridge". Now that I think about it, maybe the best way to phrase it would be as a matching donation: "Run a fast unpublished bridge with 2 IP addresses, and we have a funder who will match your donation by giving $200-300/mo to Tor." That's the reasoning that led me to say it's a great way to contribute to Tor if you can't run a fast relay yourself. Another model I've been pondering is to offer people some funding to run a fast *non*-exit relay along with a pair of extra IP addresses for these unpublished bridges. But on the theory that exits are more scarce than non-exits (and I don't want to muddy the current exit experiment with even more money), I figured it would be better to separate the roles. This discussion really goes back to a simple question: is it better to use our funding for more design and development, or for strengthening the network? For exit relays, I think choosing "strengthen the network" is a great and worthwhile experiment. But for bridges, since the current Tor transport and current bridge distribution strategies are not great, I think it's better to use funding for better designs and better code. I should note that I actually encouraged VoA to want unpublished bridges: if we set up fast bridges and published them via bridges.torproject.org today, they'd get blocked quickly in China. I'm especially hoping to hear from volunteers for whom setting up a few extra bridges is basically free -- for example, those already running fast non-exit relays who have a few more IP addresses nearby. This is also a nice way for students at universities to get involved if they're not ready to run a fast public relay quite yet. I hope that helps to explain. Sorry for exposing the internals of running a non-profit. But I think transparency is especially important here. :) --Roger

On 13.08.2012 12:56, Andrew Beveridge wrote:

I guess I fit into that category - the exit I run (mentioned previously in the exit funding thread) is on a server which has about 3 free IP addresses which I'm not using right now - I could easily use them as fast unpublished bridges if somebody explained briefly how.

Thank you! First, as you want to run both exit and bridge on one server, it will be useful to switch to a modified init script that makes it easier to handle multiple Tors: cd /etc/init.d wget -O tor https://www.torservers.net/misc/config/initd-tor chmod +x tor Example usage: # ls /etc/tor tor0.cfg tor1.cfg tor2.cfg tor3.cfg # /etc/init.d/tor start # starts tor 0-3 # /etc/init.d/tor stop # stops tor 0-3 # /etc/init.d tor reload tor2 tor3 # /etc/init.d/tor stop tor1 Next, in /etc/tor, rename your current torrc to tor0.cfg and create a new file called tor1.cfg: ----- snip ----- ## separate directories per tor process DataDirectory /var/lib/tor/bridge PidFile /var/run/tor/tor-bridge.pid Log notice file /var/log/tor/notices-bridge.log Address 109.163.233.200 # your second external IP OutboundBindAddress 109.163.233.200 ORListenAddress 109.163.233.200:443 ## default bridge port 443 ORPort 443 ## private bridge PublishServerDescriptor 0 SocksPort 0 BridgeRelay 1 Exitpolicy reject *:* ----- snip ----- -- Moritz Bartl https://www.torservers.net/

...

Sorry for exposing the internals of running a non-profit. But I think transparency is especially important here. :)

I don't know why you feel sorry. Transparency is important for non-profit, at least for most I guess.

Non-profit is just a tax and legal designation. After any necessary compliance with that, the degree of transparency, salaries paid, competitiveness, degree of being closely held, and indeed all other things... is completely variable.

On Tue, Aug 14, 2012 at 05:13:56PM +0200, tor-admin wrote:

My understanding of bridge detection was, that Chinas GFW is able to detect the Tor SSL handshake and does active bridge probing after a successful connection to a (for the GFW) unknown bridge IP. So they should be able to block any bridge publish or unpublished very quickly, if someone from behind the GFW connects to a bridge. Am I missing something?

We haven't made a big fuss about it, but Tor 0.2.3.17-beta uses a new ciphersuite in the ssl client hello, and I believe China's current DPI doesn't notice it. https://lists.torproject.org/pipermail/tor-talk/2012-June/024511.html The extra-fun part is that if a Tor 0.2.2 client connects to the bridge, it triggers the probing you describe (and thus the blocking). But if only Tor 0.2.3.17+ clients connect, no probing (and thus no blocking). Obfsproxy's obfs2 protocol is way better at not getting blocked currently; but I'm holding out for an obfs3 release, with a new protocol that's harder to DPI for, before we push for a big rollout there. --Roger

On Wed, Aug 15, 2012 at 11:55:55AM +0800, Lorenz Kirchner wrote:

I'm not a tor expert but I am in China and have been using tor... I brought this up before and I still feel that tor would benefit from having special (entry)relays inside the GFW that have a reliable link to relays outside the GFW. Clients inside GFW could then always connect to these relays. Actually, probably tens of thousands of people have VPN connections and they could host such relays to provide access to clients, even such that might be completely blocked from accessing addresses outside the GFW, which, sadly, that is not so uncommon either.

I guess, that would require a modification of the path selection on the clients side. Usually, Tor clients randomly pick relays weighted by bandwidth. Unless the Chinese relays would provide an enormous amount of bandwidth, they would barely get selected by clients which leads to a poor user experience. Perhaps it's better to focus on improved bridge distribution strategies [0] and hard-to-block transport protocols [1]. Also, that would be a universal solution which would also help in other countries and not a specific - and probably hard to maintain - Chinese-only solution.

Of course it would be great to reveal as little information as possible about such special relays in public... and continue to make the tor connections as un-conspicuous as possible

I guess, the firewall operators would notice that quite soon when Chinese relays would start popping up in the consensus or am I missing something here? And as soon as something is in the consensus, it's particularly easy to block.

20 mbit fiber connections are rapidly becoming commonplace in China. VPNs are commonplace already and I think in the case of GFW the tor project could make use of this situation.

Aren't these 20 mbit only achievable with domestic traffic? I thought that international traffic gets throttled a lot in China?

I'd love to see some sort of an easy deployable tor relay package that could listen on both the chinese and vpn address and relay traffic between the two...

For what it's worth, I and a few others are running bridges with the brdgrd tool [1]. The tool rewrites the first announced window size of a bridge and hence "forces" the client to split its cipher list in two halves. That way, the firewall has not been able to recognize Tor so far. The handy thing is, it only requires modification of bridges and not clients. Philipp [0] https://blog.torproject.org/blog/bridge-distribution-strategies [1] https://www.torproject.org/docs/pluggable-transports.html.en [2] https://github.com/NullHypothesis/brdgrd

Hi Loz, On Wed, Aug 15, 2012 at 11:00:11PM +0800, Lorenz Kirchner wrote:

...

I guess, that would require a modification of the path selection on the clients side. Usually, Tor clients randomly pick relays weighted by bandwidth. Unless the Chinese relays would provide an enormous amount of bandwidth, they would barely get selected by clients which leads to a poor user experience.

well compared to now the experience would be better, eventually the reachable Chinese relays would connect it just might take a while on first startup

Yes, assuming the users would not give up out of frustration before :-) We can actually do the math: According to [0], at the moment the Tor network has an advertised bandwidth of 3000 MiB/s. Let's assume that all Chinese relays would account for 30 MiB/s. Even then, the probability of a Chinese relay being selected as first hop is only 30/3000 = 0.01 = 1%!

...

Perhaps it's better to focus on improved bridge distribution strategies [0] and hard-to-block transport protocols [1]. Also, that would be a universal solution which would also help in other countries and not a specific - and probably hard to maintain - Chinese-only solution.

I think the solution is not a Chinese only solution as it would work anywhere where censorship actually exists

Only if you assume that the censor is always having a hard time censoring content within its own borders. That might hold more-or-less true for China but not everywhere else, right? For example, what about the networks of a company or a small organization?

...

I guess, the firewall operators would notice that quite soon when Chinese relays would start popping up in the consensus or am I missing something here? And as soon as something is in the consensus, it's particularly easy to block.

I am not sure how it works but I have a feeling that the firewall operators have difficulties in blocking hosts inside their networks

That might be due to the fact that a lot of filtering (but not all of it) is going on in border ASes. There even is a research paper about that if you are interested [1]. However, there still remains a legal problem! You will have a hard time hiding the fact that you are operating a relay within China. And if this turns out to be a viable strategy, even more so. I suppose it wouldn't be too hard for the government to simply confiscate or shut down Chinese relays? After all, I agree with you that it's an interesting strategy which would tackle the problem from a new angle and I would love to learn more about it. I just believe that right now we should spend the limited resources we have on bridge distribution and pluggable transports. It would surely be worth an experiment, though! Philipp [0] https://metrics.torproject.org/network.html#bandwidth [1] www.eecs.umich.edu/~zmao/Papers/china-censorship-pam11.pdf

On Thu, Aug 16, 2012 at 09:51:03AM +0800, Lorenz Kirchner wrote:

...

Yes, assuming the users would not give up out of frustration before :-) We can actually do the math: According to [0], at the moment the Tor network has an advertised bandwidth of 3000 MiB/s. Let's assume that all Chinese relays would account for 30 MiB/s. Even then, the probability of a Chinese relay being selected as first hop is only 30/3000 = 0.01 = 1%!

How long does it take to make 100 circuit attempts?

That would depend on when your OS thinks, a TCP connection timed out. It could be quite a while if you count several seconds for each connection attempt. Philipp

On Wed, Aug 15, 2012 at 11:42:08PM +0800, Lorenz Kirchner wrote:

...

Perhaps it's better to focus on improved bridge distribution strategies [0] and hard-to-block transport protocols [1]. Also, that would be a universal solution which would also help in other countries and not a specific - and probably hard to maintain - Chinese-only solution.

But how would tor help people that do not have direct access to outside the gfw? actually many 'consumer' ISP in China now seem to have separate NATed networks that can't even connect to each other and they seem to route international requests if they allow them at all to special third-party providers who will handle the filtering (I guess)

I still feel that a kind of 'peering relay' is needed for speed and to allow access for those users at all...

At the same time, these "peering relays" would become some sort of choke point. After all, outside its jurisdiction, the censor (mostly) only has technical control over the flow of information. Within its jurisdiction, however, we also have to deal with social and legal control. And I'm afraid that this is harder to defend against, than technical censorship. Philipp

On Tue, Aug 14, 2012 at 08:25:40AM +0200, tor-admin wrote:

ON Saturday, August 11. 2012, 18:25:03 Roger Dingledine wrote:

...

The constraints are: * 100mbit+ connectivity, though in practice I expect they will spend most of their time doing far less than that. * No more than 2 bridges per /24. If you're running fast (100mbit+) exits (which is more important), exits on that /24 count toward this 2. * No more than 7 bridges total per data center.

If you could set up 1 (or 2, or 20) and send me the address(es) privately, that would be grand.

If I ask my ISP for additional IPs, how do I check these constraints, given that I don't know other bridges/exits running at my ISP/DC.

Given that you're an early volunteer, I think you can approximate the constraints as if you are the only person running exits / bridges on those netblocks. That is, don't conflict with your own exits, and everything should be fine. In the future, I guess the better answer will be "send me mail with your planned netblocks, and I'll let you know if your plans are going to produce any conflicts." Thanks! --Roger