Strategies for getting more bridge addresses

by arma | May 14, 2011

We need more bridges. When I first envisioned the bridge address arms race, I said "We need to get lots of bridges, so the adversary can't learn them all." That was the wrong statement to make. In retrospect, the correct statement was: "We need the rate of new bridge addresses to exceed the rate that the adversary can block them."

For background, bridge relays (aka bridges) are Tor relays that aren't listed in the main Tor directory. So even if an attacker blocks all the public relays, they still need to block all these "private" or "dark" relays too. We deployed them several years ago in anticipation of the upcoming arms race, and they worked great in their first showing in 2009. But since then, China has learned and blocked most of the bridges we give out through public (https and gmail) distribution channels.

One piece of the puzzle is smarter bridge distribution mechanisms (plus see this post for more thoughts) — right now we're getting 8000 mails a day from gmail asking for bridges from a pool of less than a thousand. The distribution strategy that works best right now is ad hoc distribution via social connections. But even if we come up with brilliant new distribution mechanisms, we simply need more addresses to work with. How can we get them? Here are five strategies.

Approach one: Make it easy to become a bridge using the Vidalia interface. This approach was our first try at getting more bridges: click on "Sharing", then "Help censored users reach the Tor network". Easy to do, and lots of people have done it. But lots here is thousands, not hundreds of thousands. Nobody knows that they should click it or why.

Approach two: Bridge-by-default bundles. People who want to help out can now simply download and run our bridge-by-default bundle, and poof they're a bridge. There's a lot of flexibility here. For example, we could provide a customized bridge-by-default bundle for a Chinese human rights NGO that publishes your bridge address directly to them; then they give out the bridge addresses from their volunteers through their own social network. I think this strategy will be most effective when combined with targeted advocacy, that is, after a given community is convinced that they want to help and want to know how they can best help.

Approach three: Fast, stable, reachable Tor clients auto-promote themselves. Tor clients can monitor their own stability, performance, and reachability, and the best clients can opt to become bridges automatically. We can tune the thresholds ("how fast, how stable") in the directory consensus, to tailor how many clients promote themselves in response to demand. Read the proposal for more details. In theory this approach could provide us with many tens of thousands of bridges in a wide array of locations — and we're drawing from a pool of people who already have other reasons to download Tor. Downsides include a) there's quite a bit of coding work remaining before we can launch it, b) there are certainly situations where we shouldn't turn a Tor user into a bridge, which means we need to sort out some smart way to interact with the user and get permission, and c) these users don't actually change addresses as often as we might want, so we're still in the "gets lots of bridges" mindset rather than the "increase the rate of new bridge addresses" mindset.

Approach four: Redirect entire address blocks into the Tor network. There's no reason the bridge and its address need to run in the same location, and it's really addresses that are the critical resource here. If we get our friends at various ISPs to redirect some spare /16 networks our way, we'd have a lot more addresses to play with, and more importantly, we can control the churn of these addresses. Past experience with some censors shows that they work hard to unblock addresses that are no longer acting as proxies. If we light up only a tiny fraction of the IP space at a time, how long until they block all of it? How much does the presence of other services on the address block make them hesitate? I want to find out. The end game here is for Comcast to give us a few random IP addresses from each of their /24 networks. All the code on the Tor bridge side already works here, so the next steps are a) figure out how to teach an ISP's router to redirect some of its address space to us, and then b) sign up some people who have a good social network of users who need bridges, and get them to play that arms race more actively.

Approach five: More generic proxies. Originally I had thought that the extra layer of encryption and authentication from a bridge was a crucial piece of keeping the user (call her Alice) safe. But I'm increasingly thinking that the security properties she gets from a Tor circuit (anonymity/privacy) can be separated from the security properties she gets from the bridge (reachability, and optionally obfuscation). That is, as long as Alice can fetch the signed Tor network consensus and verify the keys of each of the public relays in her path, it doesn't matter so much that the bridge gets to see her traffic. Attacks by the bridge are no more effective than attacks by a local network adversary, which by design is not much. Now, this conclusion is premature — adding a bridge into the picture means there's a new observation point in addition to the local network adversary, and observation points are exactly what the attacker needs to correlate traffic flows and break Tor's anonymity, But on the flip side, right now bridges already get to act as these observational points, and the extra layer of encryption they add doesn't seem to help Alice any. So it's too early to say that a socks or https proxy is just as safe as a bridge (assuming you use a full Tor circuit in either case), but I'm optimistic that these more generic proxies have a role to play.

If we go this route, then rather than needing volunteers to run a whole Tor (which is especially cumbersome because it needs libraries like OpenSSL), people could run socks proxies on a much broader set of platforms. For example, they should be easy to add into Orbot (our Tor package for Android) or into Seattle (an overlay network by UW researchers that restricts applications to a safe subset of Python). We could even imagine setting up a website where volunteers visit a given page and it runs a Flash or Java applet socks proxy, lending their address to the bridge pool while their browser is open. There are some gotchas to work through, such as a) needing to sign the applets so they have the required network permissions, b) figuring out how to get around the fact that it seems hard to allow connections from the Internet to a flash plugin, and c) needing to program the socks proxy with a Tor bridge or relay address so the user doesn't have to ask for it (after all, socks handshakes are unencrypted and it wouldn't do to let the adversary watch Alice ask for an IP address that's known to be associated with Tor). This 'flash proxy' idea was developed in collaboration with Dan Boneh at Stanford, and they are currently designing and building it — stay tuned.


Please note that the comment area below has been archived.

May 14, 2011


The sample torrc says “If you can be a real relay, please do; but if not, be a bridge!”, so I set up my two nodes as relays. Should I switch to being a bridge instead?

We need to get a REALLY good game developer to create a game for the tor project.
The game would contain a tor bridge that would try to obtain an ipv6 address as well as use an ipv4 address.

May 14, 2011


One thing I notice, no offense intended, is that in all these great thoughts, even the ones about making things easier on the user, is that the user's perceptions are not being addressed. I guess you call that aspect of things 'marketing'. Or, at least, 'educating'.

Many people, technically savvy or not, are wary of Tor because you must imagine that before downloading Tor, when they are only in the consideration stage for example, they are going to run several searches on the software to see what others think of it. Now, if they run across even one story about some guy who ran a bridge and the cops did a morning raid on him and his life went to hell all because he was just trying to be a nice guy, ( supposedly and from his pov ), then they may imagine this can happen to themselves as well. That's a fairly serious nightmare scenario for someone to consider risking. So, I really believe if your aim is to get more people, not just a small minority of network proficient folks, aka more bridges, then a greater emphasis on translating technical aspects of things to 'lay people' is beyond just necessary.

Even the non-technical are turning away from Google, like many turned from MS, because of invasion fears on some level. They're going to discover that Google is funding you and wonder if that reduces the credibility of Tor's original cause as well.

Your goals are noble and IMHO, necessary. It's just that there's not enough emphasis on, again IMHO, realizing that there's a big comprehension barrier between a 'geek', even one who *thinks* he's speaking 'non-geek', and, well, a 'non-geek'. Combine a lack of technical expertise with fears/rumours/horror stories about a) using Tor and/or b) being a bridge/relay, and you've got a bit of 'tough sell' on your hands. You can't respond by saying,"Well, then we don't need those types!" and simultaneously say,"We need more bridges!". Unless your goal is more to get more techy people to buy more equipment, I don't know.

"If you can't explain something to your grandmother, you don't really understand it." --Einstein

So, maybe you could run some of your doc past a non-savvy reader and ask them,"Do you understand what we're telling you here?". If the answer is 'No', then, get it I'm sure.

I have a question too btw: Why is that when I kill both a Vidalia process, Polipo, and Firefox...they start again on their own? This has happened to me a few times, and I find it a little disturbing but then, I'm one of the non-techy folks.

We've just started working with some people on usability. It's a larger problem than expected, and getting it right should dramatically improve tor for non-researcher/non-technical users.

The Google Summer of Code does fund some students working on various Tor code projects.

The larger question you ask seems to be related to why our communications are multi-faceted. We have academic researchers, highly technical developers, motivated people trying to protect their privacy, normal people who are creeped out by google and facebook, and various people who don't, nor want to, understand how their computer and operating system work. We have one blog and website for all of these different users. The posts you see reflect this reality.

As for your last question, I have no idea why that would happen. Details like operating system, which package you installed, and how you're killing the processes would help solve it.

May 14, 2011


There should be a bridge protocol between Tor and Bittorrent so that Tor traffic can be encapsulated in BT streams.

May 14, 2011


Don't forget that IPv6 will obsolete several of these approaches, and provide several new ones. For instance, China will need to start guessing about range allocations and blocking them. Different ISPs will provide different size blocks (or even just one IP), so to avoid blocking nearby servers/customers, they'll need to research how each ISP allocates and block accordingly. Failure to do so could provide a virtually infinite number of IPs for a single bridge to use, or block large portions of the internet.

May 14, 2011


The configuration in tor bundle should be for to be a bridge by default in all users, bridges dont consume lots of bandwith like relays, so, all the Tor uses should serve like a bridge by default, like a P2P plataform "if you dont share, you cant use the service or you will be limited by the service".

One more suggestion is that you need more generic proxies, cuz they are not only blocking bridges, they are blocking exit nodes, its quite easy to identify and block exit nodes, we need more proxy lists like this:

That list its updated every 8 seconds, we need proxy list who update that fast, so they are harder to block

Sorry for my bad english, but i'm not a native english speaker.

See for an open ticket that needs more attention.

Also, we already do use captchas for the bridges we give out via gmail -- or at least, we leave that to Google and they do. Bonus points that they maintain and update the captcha design for us -- I sure don't want to get into the captcha design arms race unless we need to.

May 15, 2011


I want to help dissidents to communicate and I would set up as a "bridge" but I am on a metered account. Is it possible to tell the software, be a bridge but do not give out more than 10 megabytes of throughput per day?

May 16, 2011


The idea of implementing a socks proxy using a flash/java applet is just awful. Are you serious?!

May 16, 2011

In reply to arma


It's easier to install once (install-and-forget) a socks proxy that automatically starts at boot than having to visit your site every time I start my browser in order to load your applet. And I wouldn't have to install flash nor a jvm.

May 17, 2011

In reply to arma


A java or flash applet its just a wrong idea, they will affect performance sooo badly, keep it all in C.

May 16, 2011


I had no idea Tor Project was so hard up for bridge relays. I agree should be updated because it gave me the wrong impression bridge relays aren't in high demand.

I set up a bridge relay and enabled "PublishServerDescriptor bridge" in the bridge's torrc file. This should prevent my bridge from being publicly announced in the consensus and descriptors listings. Correct?

^ This information is missing from documentation. Possibly causing bridges to easily be filtered because they're announcing themselves as both public relays and semi-private bridges. If I'm understanding things correctly.


Actually, the only thing you need to do is add "BridgeRelay 1" to your torrc file to be a bridge rather than a public relay:

Setting PublishServerDescriptor yourself is fine but Tor will set it for you.

The real problem here is that getting 100 new bridges isn't going to do very much, because we don't have good ways to give them out relative to the number of people who ask for bridges. The bad guys will learn them and block them, and then we're back to square one. We need to find ways to _sustainably_ get bridge addresses -- hoping that 100 new people will discover the page every day and set up a bridge is not (or least, so far hasn't been) realistic.

Perhaps you need to ask those people that give up why they stopped trying to run a bridge?

Then address the reasons.
Perhaps set your rate limiting at a minimum as default.
Default is max which you state some where may cause a problem.
Setting the number and the number when the only only number we can see reported are different types of numbers, well that is the much we simpler folk that would help see.

Also is the bridge rate limit really no applicable?

Then see it that works and allow the user to raise up if the think works.

Numerous things that make the program not work, for we simple Windows that you are too busy to address all the time keeps them from running the program and recommending it to others.


May 16, 2011


Adobe Flash is notoriously insecure. Surely you know that? Apple does. I think that's at least one of their biggest misgivings for banning it off the iPhone isn't it?

And, like disabling Jax content, many privacy or, particularly, security concerned individuals don't run Java willy-nilly when browsing and also disable it. So, that's two technologies - no, sorry, THREE - that savvier browsers tend to avoid. I thought about providing links, but you can Google any of that and find the info. ( e.g. applets that operate outside the sandbox, jax as malware, adobe exploits...)

Can the data flowing out of exit nodes, assuming whoever's running one, still be exploited as much as in years past? Will that ever be something you can 'track' and shut down?

Maybe everyone's just paranoid now :)

May 16, 2011


I don't think anything like being a relay or bridge should be built in 'by default' for the client. That's a little like saying,"Well, if you're going to come to the mall to buy stuff, or even just to browse the stores, you're going to have to pull a 2 hour shift in one of them too!"

Keep it optional but continue with your efforts to reach out to users and explain how it helps.

May 17, 2011


Easy answer. Create an anonymous, decentralised, p2p2p2p (...), content-sharing network, then have all participant nodes act as bridge relays, and a number of those configured as relays to exits.

Tada. Fixed.

But you will never entertain this idea (and that says a lot).

May 18, 2011


I agree with the comments above: a flash/java applet is a bad idea because it's way easier to contribute to the tor network by installing a tor bridge router that automatically starts at boot. Not to mention that people who use tor are mostly security minded people that prefer to leave flash and java disabled.

Why can't the tor client and the tor bundle be released in a bridge-by-default configuration? For instance i2p does exactly that, every i2p client is by default an i2p router.

May 18, 2011


I dunno man, maybe a survey might be helpful here to know what others think... but I surely won't trust a server written in flash running in a web browser.

May 19, 2011


Easy answer. Create an anonymous, decentralised, p2p2p2p (...), content-sharing network, then have all participant nodes act as bridge relays, and a number of those configured as relays to exits.

Tada. Fixed.

But you will never entertain this idea (and that says a lot).

May 30, 2011

In reply to phobos


Conveniently, you haven't mentioned any reason as to why it couldn't (or doesn't, if you're intent on drawing parallels to the i2p system) work.

Tor is a failure in my mind, as it only offers the usefulness of anonymous communication for so long as governing authorities permit it. Tor may publically proclaim to be actively working to thwart that control, but that is not entirely true, as Tor fails to defeat them not because of technological limitations to the software, but because of the restrictive ideologies of those behind it. Tor is bound to operate within the confines of the ideological framework that governs it.

Until that changes, I predict, Tor will remain the same.

Tor is not a darknet. I2P is a darknet. Right now, the majority of people in the world want access to the Internet, not a separate network. Tor has hidden services which operate like a darknet within the Tor Network.

What are the ideological frameworks that confine us?

June 01, 2011

In reply to phobos


The whole point is precisely to allow for people in the world to be able to access the Internet freely, not be confined within the internals of a darknet. Are you confused about what an outproxy (exit) is all of a sudden? The idea is in creating a mass of relays, enough that Tor client users would have the ability to be able to locate working access points to be able to establish a path to the open Internet. What happens to go on 'internally' within the network of relays is a completely separate thing. The 'darknet' side could be in the form of hiddenservice-to-hiddenservice transfers within the network of relays. The 'access to the Internet' side of things would remain your typical communication from client to relay for relaying to an exit.

You need bridge operators because your relays are trivially blocked. Your bridges don't work most of the time for people who need to use them because you don't have enough addresses to offer, and those that you do have are fast blocked because the limited number of available addresses are easily discovered.

"We need more bridges." - arma

I posit that you have the potential to beat this problem by engaging in a process of popularisation of Tor by making it a service of greater use to the popular masses. At present it's mostly attractive to an esoteric few, particularly with regard the act of becoming a participant in the form of a relay or bridge.

"We need the rate of new bridge addresses to exceed the rate that the adversary can block them." - arma

You don't necessarily need bridge addresses, accessible relays would suffice.

You answer to yourself about what it is that causes you to confine yourselves between lines you draw in the sand.

May 24, 2011


I wish that last comment, though repeated, were addressed even if it did sound a little snarky at the end.

I'm not afraid to confess I'm as stupid as I am. That said, I think the UI needs help because I use it sometimes. But it often raises more questions, from me the awful 'end user', than it answers ( either in the sw or the site here ). That's not helpful to users or your bridge issues.

Rather than a default, can you insert some options when someone starts Tor through the Vidalia interface such as:

* be a bridge?
* be a relay?
*be both?
* do not be a bridge or relay

Many people forget to program for the dumbest user ( me ;) ) rather than the smartest. Being asked this may infuriate the super-savvy ( of course, being super-savvy cs genius', they will go in and edit resources files anyway probably ), but unless you are specifically trying to keep bridges tied *only* to these folks, I'm not sure how your problem will improve Over Time.

Maybe that's not possible. If acting as a bridge is akin to being an astrophysicist, then you're not going to have a lot of bridges in your network. Ever. Unless you can also get these same people to volunteer to teach dumb end users again, like me, Bridge Configurations 101. Of course, they'll have to also dumb down the tech talk to teach future foot soldiers how to get from A to Z. Talking at a CS graduate level just will not achieve that, sorry. And a lot of the answers on the site here do just that from the perspective of some of us.

Yes, I can hear the super-geeks world over sighing and rolling their eyes as they read this. But it's not so much about how dumb end users are, but rather how smart you are in the design process. Please consider the dumbest in your audience, not the smartest. IMHO, either they're already serving up bridges or they're not.

That leaves a helluva lot of people/potential bridges :)

"I wish that last comment, though repeated, were addressed"

Well, they have their priorities to consider, of which the freedom for people to communicate and access information anonymously does NOT lie at the top of the list.

"...even if it did sound a little snarky at the end."

Indeed, it IS snarky, because the hypocrites annoy me. One could interpret their silence as saying a lot, too.

I would get annoyed being asked that question every time I started Tor. And, most users have little what about what are bridges, relays, or both. All relays are bridges by default.

The current plan is to have tor detect when it's reachable from the outside world and then prompt the user if they want to help censored users reach the internet, or to act as a relay for others traffic to help them protect their privacy online.

May 25, 2011


Turn on Tor and then go to and use Shields Up.

Without Tor, my connection passes all the tests and is 'stealth'.

WITH Tor, it failed. Open ports everywhere.


May 26, 2011


So I went back and changed to a bridge on my second isp.
If there is such demand why is the bridge usage so low?

Mostly because people can't find bridges. Most bridge IP addresses change often, so by the time a user finds one, it's usable for a short period. This is the problem we're trying to solve. How do you tell the world a secret but only tell it to the good people, not the adversary trying to block you?

June 13, 2011


You can't. So sometimes you have to hide in plain sight. :)

You have to swarm your adversary. That requires more people using Tor.

If the PR is poor, you won't get them. Tor should be accessible. Easy to use, easy to set up. It's best primary purpose should be put forth in a viral fashion.

So long as Tor is a niche product used by a niche group, then your adversary's current resources will remain sufficient to irritate your efforts for some time to come.

September 30, 2011



November 01, 2011


BlackBelt Privacy offers the ability to run bridge-by-default selected from options at install time.

You also have a WASTE darkNet that is anonymous and secure.
This can be used to distribute bridge addresses, either to individuals or groups that you create and invite people into.

The bundling of WASTE also helps the Tor network because now you can do p2p off the Tor network, with much higher performance since Tor is not really a p2p solution. p2p appears to harm the Tor network. Use WASTE instead.

You can grab a copy here:

November 02, 2011


Interestingly, a chinese dissident we know has penetrated the Chinese firewall with ADVOR.

I cant understand why that penetrates the wall and standard Tor does not ?

Can anyone shed light ?

November 03, 2011

In reply to arma


Arrrrrgggghhhhh !

Thanks for the update.... will relay this to the dissident and see if he/she can report the same results over time.

I can't wait for the day when 1 billion Chinese people are able to plug into the alternative news scene.

April 17, 2012


I am using Tor via Bridge relays on an uncensored connection (afaik) but had to find out that after a few day I had to get new bridge relays from the bridges-page supplied by the tor project. Is it usual that bridges are changing that often (I guess because they are set up by private users), or do I miss sth. here?

running tor on mac os 10.6.8, btw.

May 15, 2012


Good morning from china.

I have been forced to stop using Tor for quite a long time, for all the bridges seemed been blocked by the party in china. No single way out!