Opened 9 years ago

Closed 9 years ago

Last modified 7 years ago

#2510 closed defect (fixed)

bridge users who configure the non-canonical address of a bridge switch to its canonical address

Reported by: arma Owned by:
Priority: High Milestone: Tor: 0.2.2.x-final
Component: Core Tor/Tor Version:
Severity: Keywords: tor-bridge
Cc: twilde@… Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

If I run a bridge with

Address 128.31.0.34
ORListenAddress 128.31.0.39

and then somebody runs their Tor client with

bridge 128.31.0.39

then it will connect, fetch the bridge descriptor, try to build a circuit by using 128.31.0.34, fail, and then sit there circuitless and bridgeless.

This bug is important because it means if you run a multihomed bridge, all the clients will immediately switch to using its single canonical address, ignoring all the other addresses you configured. If that canonical address gets blocked, the other addresses don't matter even if they'd still work.

Child Tickets

Change History (16)

comment:1 Changed 9 years ago by arma

Status: newneeds_review

I can imagine two fixes here. Option one is to rewrite the addr:port info in the routerinfo when you get it, so your Tor keeps thinking of that bridge in terms of the address and port that you configured.

Option two is to add a second bridge entry for the new addr:port. That would be more robust in that you'd be more likely to connect (it could handle cases where the bridge stops being reachable on the address you've configured, but continues to be reachable on its canonical address), but it is also dangerous in a situation where the canonical address is known and somebody watches for connections to it.

The bug2510 branch in my arma implements option one. It's on maint-0.2.2, but should apply cleanly to maint-0.2.1 if we choose to cherry-pick it back, and should apply straightforwardly (though maybe not cleanly) to master.

One downside of 'option one' in the context of master is that we're modifying an element of routerinfo_t, and I think your abstraction really wants us to only be modifying elements of node_t (but node_t doesn't have addr or port in it).

comment:2 Changed 9 years ago by arma

Messy issue number 1: routerlist_descriptors_added(), the function that calls learned_bridge_descriptor(), gets called after router_add_to_routerlist() and thus after we've called signed_desc_append_to_journal() and written it to our cached-descriptors.new file. Oops. Of course, we don't want to be modifying the descriptor anyway, since then the signature will fail.

The specific problem that issue number 1 causes is that when we start our Tor again, it reads in the descriptor for the bridge at 128.31.0.34, reads from its state file that a node with that fingerprint is a guard node, and tries to connect to it (I think this is a separate bug). Then later, we get the new descriptor for 128.31.0.34 by fetching it from 128.31.0.39. But rather than giving us a chance to call our function, it instead says

Feb 08 04:22:37.008 [debug] router_parse_list_from_string(): Read router 'bridge', purpose 'bridge'
Feb 08 04:22:37.008 [info] router_load_routers_from_string(): 1 elements to add
Feb 08 04:22:37.008 [info] router_add_to_routerlist(): Dropping descriptor that we already have for router 'bridge'

and that's the end of that. One workaround would be to drop bridge descriptors as we read them from disk if their IP address isn't a configured bridge. Which leads to:

Messy issue number 2: should we still do this address rewriting if we got the descriptor from the bridge authority? After all, one of the features we talk about is being able to 'follow' a bridge on a dynamic IP address from day to day, so long as you can still reach the bridge authority. Does that mean we should only do the rewriting when we got the descriptor from a direct request, and leave the address:port alone when we learned it from the directory authority?

comment:3 in reply to:  2 ; Changed 9 years ago by arma

Replying to arma:

The specific problem that issue number 1 causes is that when we start our Tor again, it reads in the descriptor for the bridge at 128.31.0.34, reads from its state file that a node with that fingerprint is a guard node, and tries to connect to it (I think this is a separate bug).

Opened bug #2511 to handle that issue.

comment:4 in reply to:  2 ; Changed 9 years ago by rransom

Replying to arma:

Messy issue number 2: should we still do this address rewriting if we got the descriptor from the bridge authority? After all, one of the features we talk about is being able to 'follow' a bridge on a dynamic IP address from day to day, so long as you can still reach the bridge authority. Does that mean we should only do the rewriting when we got the descriptor from a direct request, and leave the address:port alone when we learned it from the directory authority?

Add a router descriptor line static-bridge to dir-spec, and a torrc option to put static-bridge in a bridge's descriptor. Non-bridge directory authorities should reject descriptors containing static-bridge; clients should ignore the IP address and port listed in a @purpose bridge descriptor containing a static-bridge line, and never ask a bridge authority for an update of a descriptor containing a static-bridge line.

comment:5 in reply to:  4 Changed 9 years ago by arma

Replying to rransom:

Add a router descriptor line static-bridge to dir-spec, and a torrc option to put static-bridge in a bridge's descriptor. Non-bridge directory authorities should reject descriptors containing static-bridge; clients should ignore the IP address and port listed in a @purpose bridge descriptor containing a static-bridge line, and never ask a bridge authority for an update of a descriptor containing a static-bridge line.

Not a crazy idea. That would solve the "bridge with one address that never changes" case, and the "bridge with many addresses that never change" case, and the "bridge with many addresses some of which change and some of which don't" case. Then the remaining case is the "bridge with one dynamic address" case, which doesn't use the static-bridge line.

More generally, I think we should aim for the simple fix for 0.2.2 (and maybe 0.2.1 if we become brave), and save smarter design changes for 0.2.3.x. In particular, I've been pondering a client-side config option which is "use precisely the bridges I've configured" or "I care most about connectivity". In the latter case, Tor would remember all the bridge addresses it's seen, keep stats on them, try the old ones again periodically, ask the bridge authority for new ones, etc. In the former case, it would behave like where bug2510 is heading.

comment:6 in reply to:  3 Changed 9 years ago by arma

Replying to arma:

Opened bug #2511 to handle that issue.

The bug2511 branch is a necessary prereq for the bug2510 branch working as intended. I just replaced my bug2510 branch with one that includes both. Please review bug2511 first.

I could imagine various possible fixes to let us do our lookups at the bridge directory authority again to follow dynamic-ip bridges, such as only rewriting routerinfo addresses if the bridge line we've configured doesn't have a declared digest. But while #1938 is outstanding, I'm inclined to ignore that direction -- we can solve it when we solve #1938.

comment:7 Changed 9 years ago by twilde

Cc: twilde@… added

comment:8 Changed 9 years ago by nickm

We need routers with multiple addresses for other stuff too: We should make sure that whatever solution we adopt here isn't a bridge-specific hack that will make multiple-address routers harder to implement.

comment:9 Changed 9 years ago by arma

Component: Tor ClientTor Bridge

comment:10 Changed 9 years ago by arma

<gamambel> can i influence someone to work on 2510 ? i want to set up 100
bridges on 100 IPs from different subnets routed to one server, and it would
be awesome if it only required one tor process instead of 100.

comment:11 in reply to:  8 Changed 9 years ago by arma

Replying to nickm:

We need routers with multiple addresses for other stuff too: We should make sure that whatever solution we adopt here isn't a bridge-specific hack that will make multiple-address routers harder to implement.

I don't know what we're planning to implement for multiple addresses. But I figure whatever it is, it will have a notion of "primary address" and "other addresses".

What I'm doing here is taking one of the 'other addresses' (currently implicit, but maybe in the future it will become explicit in the descriptor as you say) and declaring that it's the one I prefer to use as its primary address.

I think once we explicitly let relays have multiple addresses, that operation is one we'll want to support.

comment:12 Changed 9 years ago by arma

I just updated my bug2510 branch based on the changes to the bug2511 branch.

comment:13 Changed 9 years ago by nickm

Weirdly, I don't hate this. It's a hack, but I think it's isolated enough that it should work okay when multiple addresses become the rule of the day.

Meditating on multiple addresses here, so I don't lose my train of thought: when we have multiple addresses, we'll need to attach them all their routers and maybe keep track of which are "preferred" or "okay to use". When we do that, rewrite_routerinfo_address_... will want to add the new address if it isn't there, and make it "preferred" and all others "not okay". That seems reasonable and not too hard to do.

comment:14 Changed 9 years ago by nickm

Resolution: fixed
Status: needs_reviewclosed

Okay, merging and closing. Thanks!

comment:15 Changed 7 years ago by nickm

Keywords: tor-bridge added

comment:16 Changed 7 years ago by nickm

Component: Tor BridgeTor
Note: See TracTickets for help on using tickets.