Tim Wilson-Brown - teor transcribed 23K bytes: > > > On 10 Sep 2015, at 17:01, isis <isis@xxxxxxxxxxxxxx> wrote: > > > >> 4.4.1. Bridge Reachability Self-Testing > >> > >> Before a Bridge uploads its descriptors to the BridgeAuthority, it > >> creates a special type of testing circuit which ends at itself: > >> > >> Bob -> Guillaume -> Charlie -> Bob > >> > >> Thus, going to all this trouble to later use loose-source routing in > >> order to relay Alice's traffic through Guillaume (rather than > >> connecting directly to Charlie, as Alice intended) is diminished by > >> the fact that Charlie can still passively enumerate Bridges by > >> waiting to be asked to connect to a node which is not > >> contained within the consensus. > > Extending to an ORPort not in the consensus can also be used to enumerate > single onion services (prop252). Any defences could apply to both, and if > they are indistinguishable, single onion services could provide cover for > bridges. (Except, of course, for the defence of a single onion service being > a relay. That doesnât help bridges.) For single onion services, hiding the location/IP of the server shouldn't matter much, since the operator has opted into less server-side anonymity. (That is, it doesn't matter if an adversary can enumerate them, since they are services like Facebook and Blockchain.info which have chosen to be quite public.) However, for "double onion services" â or whatever we're calling the thing that is (historical) hidden services 2.0 â your point is a good one; I'm starting to realise more and more that defences for "double onion services"Â are possibly defences for bridges and vice versa. > > 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. > > 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). Â Sorry, but â after having to type that twice â that name sucks. Best Regards, -- ââ isis agora lovecruft _________________________________________________________ OpenPGP: 4096R/0A6A58A14B5946ABDE18E207A3ADB67A2CDB8B35 Current Keys: https://blog.patternsinthevoid.net/isis.txt
Attachment:
signature.asc
Description: Digital signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev