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