I run a bridge from a "semi-static" home internet account, where the address is dynamically assigned but only changes when either the ISP or my hardware router goes down and forces a reconnect, which only happens maybe once every several months. I've read in a few places that Tor bridges with dynamic IP addresses are just as useful as those with static addresses, even if their address changes pretty often, because the bridge user's client will use the bridge's fingerprint to look up its current address and port from the bridge authority if it fails to connect.
How certain are we that this is actually happening? It's not the behavior I'm seeing here. My IP address has changed maybe 3 times in the last year, once for an ISP outage after a storm, and for a couple of hardware router firmware updates on my end. In each case, my bridge's traffic plummeted back to essentially nil, with a long slow regrowth over several weeks (or months!) as the new address slowly propagated around to a new set of users. I like to monitor the "Who has used my bridge?" status from Vidalia, and I get a real heartwarming glow when I see places like Syria and Iran showing up regularly. I've had a nice steady clientele keeping my bridge pretty busy for the past few months, and then yesterday I needed to do a firmware update, and *pfft* all my clients are gone again and I'm back to square one. Sigh. What's worse, I then picture that hypothetical Syrian civil rights dissident who's come to rely on my bridge always being there, suddenly being stranded without a connection and needing to scramble to find another one. Unnecessarily, as I was back up in minutes, just with a new address.
It's pretty clear that the mechanism for clients to refresh their bridge's addresses is there, but I'm doubting that it's actually working right. I can think of two main failure modes: either the fingerprint isn't being distributed (or entered), leaving the user with just the current IP address and port with no way to query the bridge authority for an update. Or it's being entered, but not actually used by the client.
For the first, BridgeDB does distribute the fingerprints, but I note that the docs/bridges.html.en page mentions that it's optional, but then doesn't say anything about what it's good for or why you should include it, so I wonder if many users just don't bother, especially if they need to query BridgeDB from a different PC than they run their own copy of TBB on and can't easily copy & paste the whole thing. Also, it seems the email responder channel doesn't even give out the fingerprints at all, leaving all those users automatically without updates. I don't know the distribution split between BridgeDB site queries and email queries, so it's hard to guess the impact of that lack, but it seems like something that could be easily fixed regardless.
Probably more critical though, is the second option. Why would the fingerprint not be used if it was entered? Maybe some key option got disabled somehow? If I'm reading the torrc manual right, there's an option called UpdateBridgesFromAuthority that controls exactly this behavior... and it defaults to off. And to see how it ends up being set in the actual TBB, I installed that and checked its torrc, and it's not in there either, so apparently it stays disabled. "Well, there's your problem..."
So am I missing something, or has this feature somehow fallen through the cracks and ended up accidentally disabled for the vast majority of all bridge users? It seems like this must be having a pretty serious impact on overall bridge usage, as I was under the impression that a big percentage of bridges are run off of dynamic address accounts, and many of those will be changing addresses more often than mine, maybe as frequently as daily in the worst cases. And every time they do, they lose their entire clientele and have to restart the long, slow ramp up to a new user base again from scratch. This kind of forced, pointless churn can't possibly be good for the network. How many bridge operators are we losing every year because they never see significant traffic due to changing IP addresses too often? And if they ask about it, they're just told, "Sure, dynamic IP is fine, just be patient and they will come." And what's the impact on the bridge users of having their bridge connections going bad so much more often than they should? I think simply getting a bridge address might be a risk exposure for many of these people, and making them do it more often could be dangerous for them.
Or maybe I'm just totally misreading this, and my own experiences of losing all my bridge clients on each change aren't typical, but are due to some other unknown singular issue. How about you other bridge providers, how many of you are on dynamic IP addresses, and have you noticed a similar huge drop in traffic after a change, or does your traffic seem to snap back pretty quickly as it should?
On Tue, Jun 24, 2014, at 12:40 AM, Rick Huebner wrote: [snip]
Or maybe I'm just totally misreading this, and my own experiences of losing all my bridge clients on each change aren't typical, but are due to some other unknown singular issue. How about you other bridge providers, how many of you are on dynamic IP addresses, and have you noticed a similar huge drop in traffic after a change, or does your traffic seem to snap back pretty quickly as it should?
I run two bridges (one is obfs3) off my residential connection (I had to stop running a non-exit relay because Hulu and other big sites blacklist tor nodes) and I'd be happy if I had *any* traffic. Over a two-month period, with 1 IP change in the middle, I've probably only passed about 100MB in actual traffic. Sure, I only have about 2MB/s to spare, but I passed several hundred GB as a relay before I quit. Surely after this amount of time, my fingerprint would have been given out a few times. Or are bridges simply not used all that often? There's no problems on my end according to my Tor logs.
I know this is barely related to your experience, but I've been curious myself about bridge utilization.
It may be partially related, in that I've seen it take weeks to gradually gain a new set of clients after an IP change, which is why I think it's so important to not be abandoning all your clients each time but instead let them update their bridge entries to your new address. If you've been up for 2 months and changed your IP in the middle, you probably cut off and abandoned all your clients after a month just when you were starting to get somewhat known, and had to start over from scratch and are just now beginning to build up a fresh client list again. If you typically get a new IP address every month, you may never be able to build up enough clients to see much traffic with the way things currently seem to work.
And of course there's a large random factor in just which clients you end up being handed out to. If you end up with mostly just people doing a little web email once in a while, they won't add up to much traffic. I like to watch my bridge's status page on globe.torproject.org to see the traffic history and number of connected clients history graphs, and also the Vidalia "Who has used my bridge?" status (or the bridge-stats file in your bridge's data directory) to get more detailed feedback than just the total bandwidth used.
But another issue may be the random luck of the draw of which bridge assignment pool you end up being placed in. As I understand it, to make it harder for threats to find all the bridges and censor them, the bridges are partitioned off into pools which are only assigned to limited subsets of clients via particular distribution methods and client IP address ranges, so that no threat source can find out about bridges outside of the pool they're allowed to pull from. So if your bridge ends up placed in a pool that just doesn't have many clients using it, your info will be handed out that much less often. In the worst case (from the bridge provider's point of view anyway), I believe some bridges are simply held in reserve for emergency use, such as when a common obfuscation plugin becomes censored, so that there's a ready supply of previously unused and therefore uncensored bridges to hand out once Tor figures out how to avoid the new attack method. That's good for the network of course, but I'm afraid it's not very satisfying for the eager bridge provider who's basically left on the bench as a backup in case a first string player gets injured. I suspect there's a lot of churn in that pool as people feel useless and quit bothering to provide the unused bridge. For what it's worth, the globe status page will also show you what pool your bridge has been placed in, which may help reassure (or confirm :( ) that worry.
Rick Huebner rhuebner@radiks.net writes:
I run a bridge from a "semi-static" home internet account, where the address is dynamically assigned but only changes when either the ISP or my hardware router goes down and forces a reconnect, which only happens maybe once every several months. I've read in a few places that Tor bridges with dynamic IP addresses are just as useful as those with static addresses, even if their address changes pretty often, because the bridge user's client will use the bridge's fingerprint to look up its current address and port from the bridge authority if it fails to connect.
Hello Rick,
your intuition is correct. This feature does not work very well.
Here are a few reasons why:
a) As you said, UpdateBridgesFromAuthority is turned off by default. AFAIK, this is the case because the feature is not very useful atm: most places have already blocked all the Tor authorities including the bridge authority.
The feature needs to be slightly reworked. For example, maybe Tor needs to ask any working bridges it has about the descriptor of its dead bridges. Then the working bridges would query the bridge authority themselves and relay the descriptors to the client.
However, a Tor proposal is needed to implement the above feature and further analysis is required (for example, is it a good idea to reveal to a bridge what other bridges you are using). Feel free to help us out with this :)
b) Also, Tor clients are amnesiac with regards to bridges information. That is, even if they learn the fingerprint or the new IP address of a bridge, they don't write it down on a file. So next time they start up, they have to do the whole thing again. Sebastian wrote a proposal for this a few years ago, but it's still unimplemented: https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/192-store-bri... Feel free to help with this too :) The first step is probably to reread the proposal, and see if anything needs to be changed to reflect the current state of Tor.
Also, check out this related blog post by Sebastian: https://blog.torproject.org/blog/different-ways-use-bridge
Have a good day and sorry for the sad news :)
tor-relays@lists.torproject.org