On 15/04/14 19:36, David Fifield wrote: > On Tue, Apr 15, 2014 at 02:03:43PM +0100, Ximin Luo wrote: >> ## The problem >> >> The problem with the above structure, is that it is incompatible with the >> metaphor of connecting to a specific endpoint. This is what the PT spec is >> about, even though it does not explicitly mention this viewpoint. Instead, >> meek and flashproxy provide the metaphor of connecting to a global >> homogeneous service. >> >> This has positive consequences, such as the user no longer having to bother >> to find Bridges, but also has several negative consequences: >> >> 1. The Tor client can no longer authenticate the endpoint. Although >> currently Tor makes this optional, it is strongly recommended, to prevent a >> MitM between the client and the server. Even if the midpoint does this, this >> is not end-to-end authentication that we would require for strong security. > > I see this somewhat differently. You still choose and authenticate the > second and third hops. I heard from Roger that it is a sort of accident > that bridge-using circuits use three hops, anyway. It should be that > there are four: the first hop is your untrusted bridge address you got > from wherever, and the second is your guard. Would a design like that > make most of these issues go away? > I think this would be OK conceptually, but it would extend the circuit by one hop, to 5 total hops. Currently, we have (with meek/fp): PT client -> midpoint -> untrusted bridge -> tor relay -> tor exit My proposed fix would turn it into: PT client -> midpoint -> trusted bridge -> tor relay -> tor exit Your suggestion would be analogous to: PT client -> midpoint -> untrusted bridge -> trusted guard -> tor relay -> tor exit It also confuses the model a little, since the untrusted bridge does not help toward anonymity (since it can be MitMd), but is still running Tor, solely to bypass censorship. > There's an old ticket here, "Let bridge users specify that they don't > care if their bridge changes fingerprint." > https://trac.torproject.org/projects/tor/ticket/3292 > which also ties with this blog post "Different Ways to Use a Bridge." > https://blog.torproject.org/blog/different-ways-use-bridge > Completion of #3292 would be a beautiful thing, I think, for flash > proxy, as it would allow us easily to round-robin multiple websocket > bridges. (Currently you can't do that because the tor client freaks out; > see https://trac.torproject.org/projects/tor/ticket/7153#comment:5.) > If by "bridge" you mean "authenticated relay, that is 2 hops before the exit", then I'm not sure how useful round-robin between multiple untrusted bridges really is, since this opens you up to MitM at that point. "What exactly are we protecting against by refusing to use the network when A's fingerprint changes?" - MitM on A, and relevation of my first-hop OR traffic to the attacker? Am I wrong here? Or is this not a big deal for anonymity? One can tweak #3292 to prevent MitM - instead of allowing *any* fingerprint, one would be able to specify multiple fingerprints for the same IP address, and the Tor client would treat these as separate Bridges (since they are separate). I believe this model is clearer and closer "to reality", namely the endpoints metaphor. It's also similar to my (3) suggestion from before. > Some other relevant tickets about non-authentication of bridges: > > "analyze security tradeoffs from using a socks proxy vs a bridge to > reach the Tor network" > https://trac.torproject.org/projects/tor/ticket/2764 > For "socks proxy", substitute "indirect proxy", and it works the same. I > think of indirect proxies like flash proxy as untrusted unauthenticated > things that just get you to the Tor network, which you then > authenticate, the same as a socks proxy. The quotes there that I agree > with are "from a *security* perspective (for a broad definition of > security), is there really any difference between a socks proxy and a > bridge relay?" and "I don't see any huge roadblocks to having bridges > that are just vanilla proxies. We should deploy them if we can make them > usable, and maybe someday somebody will show us it was a bad idea." > > "Tor build variant to support lightweight socks bridge" > https://trac.torproject.org/projects/tor/ticket/3466 > I largely agree with these quotes, but this would be assuming the socks proxy is authenticated (or, can be authenticated) *and* the end-client can completely control the second hop after it. Neither of these properties are true for the indirect proxying of meek/flashproxy. X -- GPG: 4096R/1318EFAC5FBBDBCE git://github.com/infinity0/pubkeys.git
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev