On Fri, Jul 11, 2014 at 07:51:49PM +0300, George Kadianakis wrote: > Hello Roger and Nick, > > as far as I know, bridge support was hastily implemented in > little-t-tor, and it does not support all the features we would like > it to support. > > During the dev meeting roadmapping, we added a task about improving > the bridge implementation in Tor. Some of the items in the task are: > > - Bridges should save bridge information to the state file (proposal 192) > - Fix UpdateBridgesFromAuthority. > - Obfsbridges should be able to hide their ORPort (#7349)
I'd like the ability to have a four-hop circuit when using bridges. Some transports that aim at IP blocking resistance have you do a leap of faith: the transport connects you to some bridge--you don't control which--and after that you get to pick the next two hops. (It's essentially the same situation you're in with ordinary bridges: BridgeDB gives you an IP and a fingerprint and you just connect blindly to it.) I get the impression that it was originally intended that there be four hops in a bridge-using circuit (cf. https://lists.torproject.org/pipermail/tor-dev/2014-April/006694.html). As a mitigation against the possibility of MITM of the first hop, Ximin added the fingerprint of the bridge that's currently backing flash proxy: https://gitweb.torproject.org/flashproxy.git/commitdiff/ae09d13b4fa4caa8d0a0dd07b1add66605466953 It's a good idea, but also a bit problematic. It means we can't change the bridge behind the system, or round-robin several bridges, without breaking all the users who have hardcoded the fingerprint. A proposed workaround for flash proxy (#10196) that would allow the client to control its first hop through an in-band channel is, I believe, mistaken. It would prevent load-balancing by the transport and prevent backing bridges from ever changing their keys. I would rather see the first hop continue to be a leap of faith--as if were a dumb SOCKS proxy--and then you authenticate the next three hops, just like always. To go with the above, #3292 would be nice. "Let bridge users specify that they don't care if their bridge changes fingerprint" https://trac.torproject.org/projects/tor/ticket/3292 Also relevant is #2764. The first-hop unauthenticated and untrusted bridge takes the place of a SOCKS proxy. "analyze security tradeoffs from using a socks proxy vs a bridge to reach the Tor network" https://trac.torproject.org/projects/tor/ticket/2764 David Fifield _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev