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/ae09d13b4fa4caa8d0a0... 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