[tor-dev] Call for a big fast bridge (to be the meek backend)

[Ximin Luo]

On 18/09/14 16:41, David Fifield wrote:
> On Thu, Sep 18, 2014 at 02:02:42PM +0100, Ximin Luo wrote:
>> On 18/09/14 03:31, David Fifield wrote:
>>> Currently in the bundles we're not setting a bridge fingerprint, so
>>> relays wouldn't have to share a key.
>>>
>>
>> This is something to be *fixed*, not to build future components on top of.
>>
>> Previously you mentioned that "the user could set their circuits to 4
>> hops" but I think this is a hack of a solution and we can do better,
>> by authenticating the Bridge.
> 
> I really disagree with you here :( I don't understand your point of
> view. Let's try and assume good faith.
> 
> Do you remember a couple of days ago, when I had to separate the tor
> processes for flash proxy and meek because the metrics were getting
> mixed up? That would have been *impossible* to do if there were
> hardcoded fingerprints out there in bundles. And how I recently put out
> a call for someone else to run the meek bridge? How is that transition
> supposed to work if changing the fingerprint means we suddenly and
> inexplicably break every existing client installation?
> 

Practically you are right, but this is only because of the weird dynamics of these particular PTs, namely that there is only one bridge that everyone relies on. This is not an ideal situation, and we should deploy more bridges.

If we had 10 meek PTs and everyone had 3 meek Bridge lines, your original problem wouldn't be a problem. Or at least, it would be solve in the same way as everything else - if your obfs3/fte bridge goes down, you go to BridgeDB and ask for another bridge line, or whatever other channel you used to get that line in the first place.

> The answer surely isn't "make sure the bridge's private key never
> changes" and it isn't "anticipate every possible eventuality
> indefinitely into the future."
> 
> Can you explain what you don't like about four hops? To me it feels like
> the right thing. It wouldn't just be for meek, you know, but for all
> bridge circuits (including ordinary plain-vanilla bridges). When you're
> using a bridge you treat the first hop as unauthenticated and
> unencrypted, as if it were a SOCKS proxy or third-party VPN or any other
> circumvention proxy. You treat the first hop as not chosen by you,
> because it's not: even with BridgeDB you're just pasting in some bytes
> the web site chose for you. After your first circumvention hop, then you
> add your own three hops, notably including your own chosen guard.
> 	bridge → guard → middle → exit
> 

What I don't like about "4 hops" is that it is actually "5 hops". In meek you have the reflector, and in flashproxy you have the proxy. I think it would be better to get this down to 4 actual hops.

You raise a good point about the first hop not being chosen (generally) by the user. This is partly a quirk with the design of Bridges. In a censored area, you have to go through the Bridge to even download the consensus, so the client then only picks 2 other hops. Then your Bridge pretty much acts as a Guard.

However, with meek/flashproxy, we have something else that bypasses the censorship (the reflector/flashproxy). To go along with your "SOCKS/VPN proxy" scenario, ideally what would happen is, the client goes through the reflector/flashproxy to download the consensus, then picks 3 more hops from the consensus that are authenticated.

You didn't pick this design for meek/flashproxy because it was a security risk to allow flashproxies to connect to arbitrary IPs, and it would be a lot of effort to implement code that restricts these connections only to allowing downloading of the consensus / connecting to IPs in the consensus. So you put another Tor Bridge beyond that, which already implements this logic, and restrict connections only to this Bridge. But it means we have to have 5 hops instead of 4 hops.

I do understand your arguments though, I just think it is better to have (4-real-hops and slightly extra work when a Bridge goes down) rather than (5 hops all the time).

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: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20140918/d34ce0b7/attachment.sig>