Tim Wilson-Brown - teor transcribed 19K bytes:
On 12 Sep 2015, at 17:26, isis isis@torproject.org wrote:
Tim Wilson-Brown - teor transcribed 23K bytes:
On 10 Sep 2015, at 17:01, isis isis@torproject.org wrote:
2.b. If it is useful to people, then the best way I can think of so far to keep it, but refactor it to be safer, would be to create a circuit like:
Bridge → Guard → Middle → OtherMiddle → Guard → Bridge Clearly, that circuit is just a little bit insane… but we can't do: Bridge → Guard → Middle → Guard → Bridge because the Middle would refuse to extend back to the previous node (all ORs follow this rule). Similarly, it would be stupid to do: Bridge → Guard → Middle → OtherMiddle → Bridge because, obviously, that merely shifts the problem and accomplishes nothing. But is there something smarter I could do?I quite like this idea, and a 5-hop circuit is below the 8-hop limit.
Okay, thanks! I'll keep this in mind as a self-testing manoeuvre we might want to enable for both HSes and bridges. Hopefully there's something smarter than "Yo! Throw some extra hops in that shit!", but if it works it works, I guess.
Well, this is “onion" routing after all… extra hops are the core of our anonymity design(s).
Okay, I added this part to the bridge reachability self-testing section of prop#188 earlier today.
- Should we change how the BridgeAuthority tests Bridge ORPort reachability?
If so, how?
The bridge authority could connect via a 3-hop path, but that would suffer from the same issues as bridge reachability self-testing - the bridge authority extending to an ORPort not in the consensus would reveal the bridge to the last hop.
But the bridge authority could choose a set of guards (vanguards?, last-hop guards?) for this purpose, reducing the chances that one is an adversary.
I started thinking about this idea, but discarded it due to thinking: "Why expose the bridges to other nodes at all, now that we have bridge guards?"
If anything, I suppose we could consider having the BridgeAuthority simply use its guards to connect to bridges… but still something feels wrong. I feel like this whole bridge testing system needs a giant rethinking and overhaul — rather than simply bolting more nodes on top of a thing which doesn't really do what we want anyway (i.e. testing PT reachability).
Do you mean that the bridge authority should receive and use the bridge’s guards, or the bridge authority’s guards?
Sorry, I meant the BridgeAuth's guards.
If the authority already knows each bridge’s IP and ORPort, I guess that it’s ok for it to know the bridge’s guards.
Hrm. Perhaps it's not okay for the BridgeAuth to connect to bridges through their bridge guards?
My reasoning here is that, if you're a bridge guard, we want it to look (as much as possible) like you're actually the entry guard for a normal client. Having the BridgeAuth suddenly connect to you, and ask you to connect to something you think is actually a client would look pretty weird.
Thanks for the great feedback!