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

[David Fifield]

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?

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

David