UpdateBridgesFromAuthority dangerous
Now that we've fixed #1138 (moved), 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 (moved).
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.)
Activity
changed milestone to %Tor: 0.2.3.x-final
Trac:
Points: N/A to N/A
Actualpoints: N/A to N/A
Cc: N/A to twilde@cymru.com
Trac:
Description: Now that we've fixed #1138 (moved), 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 (moved).
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.)
to
Now that we've fixed #1138 (moved), 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 (moved).
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.)
Trac:
Cc: twilde@cymru.com to twilde@cymru.com, ln5
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?
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.
-
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.
Trac:
Status: new to needs_review 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?
-
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?
-
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 (moved), which is not for 0.2.3.x.
Please shout if I'm doing something foolish here.
Trac:
Resolution: N/A to fixed
Status: needs_review to closed mentioned in issue #2510 (moved)
mentioned in issue #4392 (moved)
mentioned in issue #6010 (moved)
moved to tpo/core/tor#1938 (closed)
mentioned in issue tpo/core/tor#6010 (closed)