What little-t-tor bridge features/issues we should address?
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) Some of those items are more long-term than others. What other tasks would you like to see in there? We are looking for tasks mainly related to bridges themselves, and not PTs. Thanks!
I would like to be able to bind to privileged ports when running a PT-enabled bridge in managed mode --- will any changes to little-t-tor be required for this feature? -Kevin On Fri, Jul 11, 2014 at 9:51 AM, George Kadianakis <desnacked@riseup.net> 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)
Some of those items are more long-term than others.
What other tasks would you like to see in there? We are looking for tasks mainly related to bridges themselves, and not PTs.
Thanks! _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
On Mon, 14 Jul 2014 12:30:06 -0700 Kevin P Dyer <kpdyer@gmail.com> wrote: (This is orthogonal to the bridge code, but since you asked...)
I would like to be able to bind to privileged ports when running a PT-enabled bridge in managed mode --- will any changes to little-t-tor be required for this feature?
(Assuming Lenooks for the sake of discussion.) At the dev meeting I was talking to dgoulet about having tor do the appropriate work to preserve the CAP_NET_BIND_SERVICE when dropping root so all PTs transparently get this capability. He mentioned difficulties with our python PTs, probably because the ServerTransportPlugin line was pointing directly at the script and it was getting invoked via the #! handler in the kernel. It may be possible that this "just works" if the ServerTransportPlugin line pointed at the python interpreter instead, but if it does not, this will probably require a kernel patch, that won't ever get accepted upstream. Regards, -- Yawning Angel
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
participants (4)
-
David Fifield -
George Kadianakis -
Kevin P Dyer -
Yawning Angel