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

[Ximin Luo]

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

I suppose that, with an indirect PT, it is no longer necessary to connect to a Bridge - we should be able to connect, via the midpoint, directly to a normal public entry node. Then its fingerprint would be available in the consensus. Then as you say, the user would not need to bother with fingerprints (or Bridge lines at all), and I can definitely see why this was a strong motivator in the current design of meek/fp.

(This would be similar to the 5-hop separate "untrusted bridges" vs "trusted guard" suggestion in David's post, but cutting out the "untrusted bridge" part.)

So, I'd support an effort to move in this direction as well. However, it would take more changes and more thought than my original proposal, though it's also strictly better than it, I think - i.e. more flexibility, more usability, no less security.

X

-- 
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/9e35bdeb/attachment.sig>