Tim Wilson-Brown - teor transcribed 19K bytes: >> On 12 Sep 2015, at 17:26, isis <i...@torproject.org> wrote: >>> Tim Wilson-Brown - teor transcribed 23K bytes: >>>> On 10 Sep 2015, at 17:01, isis <i...@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. >>>> 3. 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! -- ♥Ⓐ isis agora lovecruft _________________________________________________________ OpenPGP: 4096R/0A6A58A14B5946ABDE18E207A3ADB67A2CDB8B35 Current Keys: https://blog.patternsinthevoid.net/isis.txt
signature.asc
Description: Digital signature
_______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev