On 16/04/14 15:56, George Kadianakis wrote:
Ximin Luo infinity0@torproject.org writes:
<snip>
So instead of having, as currently:
(old, hacky) Bridge flashproxy (dummy addr)
We would have the following cases:
(1) Bridge flashproxy (real addr) (2) Bridge flashproxy (real addr) (fingerprint) (3, not-ideal) Bridge flashproxy (dummy addr) (fingerprint)
Option (3) is quite nice, since in indirect PTs the actual address is irrelevant - the Tor client never tries to connect to it. I suggest that we have a special syntax for it though, to explicitly discourage hacks that {use dummy addresses but which are treated as real addresses by the underlying application}, since this breaks assumptions of the PT spec.
Hm, but this kind of kills the magic of indirect PTs, right? That is, users who want to use flashproxy in the way above, will have to know an address or a fingerprint of the bridge beforehand. What is the use case? Advanced users? I guess most users (people who use the TBB) will still need to use the current scheme, right?
We can distribute the fingerprints of the default meek/fp Bridges in the default torrc, just like we distribute non-authenticated defaults currently. If we introduce new ones (e.g. if the old defaults are blocked or need to be shutdown, or just to increase capacity), BridgeDB can distribute these new ones with new fingerprints. (But indirect PTs should be harder to block anyways.)
Also, if all traffic goes over the midpoint, how can we make sure that the midpoint will connect us to the bridge requested with:
(1) Bridge flashproxy (real addr)
?
Yes, this by itself probably doesn't gain that much, I just included it for completeness. (If we imagine a PT that has a non-secret but parameterised obfuscation method (bananaphone?), then we would need this sort of thing if we wanted to use a controller to multiplex between multiple of those Bridges. But ideally everything would have a fingerprint and be strongly authenticated.)
X
FWIW, I liked your argument with regards to authentication, and David's reply citing a few tickets that detail the (lack of) threat model for Tor bridges...