Opened 9 years ago

Closed 7 years ago

Last modified 7 years ago

#1938 closed task (fixed)

UpdateBridgesFromAuthority dangerous

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

Description (last modified by arma)

Now that we've fixed #1138, it might be tempting to start distributing identity fingerprints along with our bridge addresses again, so clients can try the bridge authority for the descriptor.

In retrospect, though, the plan of "first go to the centralized place that is easily associated with being a Tor bridge user, then if it's unreachable go directly to the bridge for its descriptor" is unwise.

In practice we should go to our bridges directly for their descriptor, and if we learn no descriptors, fail closed. Then, for the bridges that we've configured but didn't get a descriptor for, we can ask the bridge authority *via Tor* if it happens to know a newer descriptor for them.

We'll have an opportunity to make things more robust once we get going on #1852.

In the mean time, we should continue to avoid putting fingerprints on bridge addresses. (I believe Vidalia still sets UpdateBridgesFromAuthority for you when you configure a bridge.)

Child Tickets

Change History (16)

comment:1 Changed 9 years ago by nickm

Milestone: Tor: 0.2.3.x-final

comment:2 Changed 9 years ago by twilde

Cc: twilde@… added

comment:3 Changed 9 years ago by arma

Component: Tor ClientTor Bridge

comment:4 Changed 9 years ago by arma

Description: modified (diff)

comment:5 Changed 8 years ago by nickm

Milestone: Tor: 0.2.3.x-finalTor: 0.2.4.x-final

Anybody think we can do this as a small thing in 0.2.3? If so, move back to the 0.2.3 timeframe.

comment:6 Changed 8 years ago by ln5

Cc: ln5 added

comment:7 Changed 8 years ago by rransom

Milestone: Tor: 0.2.4.x-finalTor: 0.2.3.x-final

This should be a simple matter of turning on the ‘perform directory request anonymously’ flag when starting a directory-fetch operation from the bridge authority.

comment:8 Changed 8 years ago by nickm

This should be a simple matter of turning on the ‘perform directory request anonymously’ flag when starting a directory-fetch operation from the bridge authority

So, if we set that flag, and we can't get any circuits because we don't have any bridge descriptors yet, would we fall back to asking the bridges for their own descriptors, or would we just break?

comment:9 in reply to:  8 Changed 8 years ago by rransom

Replying to nickm:

This should be a simple matter of turning on the ‘perform directory request anonymously’ flag when starting a directory-fetch operation from the bridge authority

So, if we set that flag, and we can't get any circuits because we don't have any bridge descriptors yet, would we fall back to asking the bridges for their own descriptors, or would we just break?

If you set that flag when launching requests aimed at the bridge authority, and Tor can't build circuits, those requests will fail. That shouldn't interfere with asking the bridges for their own descriptors.

If you set that flag when launching requests aimed at the bridges themselves, and Tor can't build circuits, those requests will fail, and Tor will thoroughly break. So don't do that then.

comment:10 Changed 7 years ago by nickm

Status: newneeds_review

So, could this be as simple as editing purpose_needs_anonymity() to change this:

  if (router_purpose == ROUTER_PURPOSE_BRIDGE && can_complete_circuit)

into this:

  if (router_purpose == ROUTER_PURPOSE_BRIDGE)

? I believe that in the case where we download descriptors from bridges, we don't call purpose_needs_anonymity() at all. And in any other case, we don't really want to fall back for bootstrapping purposes at all.

There's a patch in my branch "bug1938" that does that, but I believe it isn't complete. Looking at the logic in fetch_bridge_descriptors(), it seems like the requisite fallback logic doesn't exist. In other words, what we'd actually want is something like, "Try the bridge first and use the authority if it isn't there", or "Try the authority first and use the bridge if it can't answer." But from the way we set ask_bridge_directly, it seems like we always use it when we can and when UpdateBridgesFromAuthority is on.

I think what we want is a setting that makes us use ask_bridge_directly=1 unless we've tried to connect to the bridge and failed.

comment:11 in reply to:  10 ; Changed 7 years ago by ln5

Replying to nickm:

There's a patch in my branch "bug1938" that does that, but I believe it isn't complete. Looking at the logic in fetch_bridge_descriptors(), it seems like the requisite fallback logic doesn't exist. In other words, what we'd actually want is something like, "Try the bridge first and use the authority if it isn't there", or "Try the authority first and use the bridge if it can't answer." But from the way we set ask_bridge_directly, it seems like we always use it when we can and when UpdateBridgesFromAuthority is on.

I think what we want is a setting that makes us use ask_bridge_directly=1 unless we've tried to connect to the bridge and failed.

Should the user be able to choose between "first bridge, then
authority" and "first auth, then bridge"? Is that what the part about
"a setting" means? It seems to me that the second option would be
exactly what Roger thinks is a bad idea ("first go to the centralized
place that is easily associated with being a Tor bridge user, then if
it's unreachable go directly to the bridge for its descriptor").
Presumably because it'd enable a censor to easily block the bridge
authority and then look for users trying to connect to it and harvest
bridges by looking for TCP connections from that user.

In the first case, where we prefer fetching from the bridge, should we
try _all_ bridges before going to the authority?

In the second case, where we prefer asking the authority first, should
we ask for _all_ bridges before we fall back to trying to contact the
bridges themselves?

comment:12 in reply to:  11 Changed 7 years ago by Sebastian

I don't think we want another torrc config option here. What's wrong with never going to the bridge auth directly while we have at least one working bridge, and making UpdateBridgesFromAuthorities govern whether we try the bridge auth at all?

comment:13 Changed 7 years ago by nickm

So, merging my patch as-is would (I think) solve the problem of making UpdateBridgesFromAuthority "safe". But not actually "usable". The solutions that would make it "usable" seem to be too much for 0.2.3.

Would it be reasonable to merge my fix in 0.2.3, close this ticket, and open a new ticket to make UpdateBridgesFromAuthority usable?

comment:14 in reply to:  13 Changed 7 years ago by nickm

Resolution: fixed
Status: needs_reviewclosed

Replying to nickm:

So, merging my patch as-is would (I think) solve the problem of making UpdateBridgesFromAuthority "safe". But not actually "usable". The solutions that would make it "usable" seem to be too much for 0.2.3.

Would it be reasonable to merge my fix in 0.2.3, close this ticket, and open a new ticket to make UpdateBridgesFromAuthority usable?

Doing that. "UpdateBridgesFromAuthority" is now safe but not so usable. Making it usable is #6010, which is not for 0.2.3.x.

Please shout if I'm doing something foolish here.

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.