[tor-dev] Improving the structure of indirect-connection PTs (meek/flashproxy)

[Ximin Luo]

On 16/04/14 15:56, George Kadianakis wrote:
> Ximin Luo <infinity0 at 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...
> 

-- 
GPG: 4096R/1318EFAC5FBBDBCE
git://github.com/infinity0/pubkeys.git

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 880 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20140416/f254cf22/attachment.sig>