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

[Ximin Luo]

On 16/04/14 16:24, Ximin Luo wrote:
> 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.
> 

Whoops, I was a little hasty here. The above design can already be implemented, as a normal HTTP/SOCKS proxy (that goes through a midpoint), that tor can use via a HTTPProxy/Socks5Proxy torrc option, instead of a ClientTransportPlugin option. The reason why we use Bridges is it gives us a bit more flexibility in terms of the protocol that the entry node can accept, in case the midpoint can't speak OR, which is the case in both meek and fp.

TL;DR: followers of this thread can ignore this and my previous email, sorry for the noise.

As a side point though, I realised another issue for flashproxy. At the moment, the PT client sets the facilitator (the controller) on the command line. This means we can't use Bridges that come from different facilitators. Meek seems to support taking params from the SOCKS args, though. The general point for indirect PTs then, is that information that helps to determine which bridge is used, should be given on the Bridge line.

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/509c33b1/attachment.sig>