Re: [tor-dev] What little-t-tor bridge features/issues we should address?

[David Fifield <david@xxxxxxxxxxxxxxx>]

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@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev