[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #1938 [Tor Bridge]: UpdateBridgesFromAuthority dangerous
#1938: UpdateBridgesFromAuthority dangerous
------------------------+---------------------------------------------------
Reporter: arma | Owner:
Type: task | Status: needs_review
Priority: major | Milestone: Tor: 0.2.3.x-final
Component: Tor Bridge | Version:
Keywords: | Parent:
Points: | Actualpoints:
------------------------+---------------------------------------------------
Comment(by ln5):
Replying to [comment:10 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?
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/1938#comment:11>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs