[anti-censorship-team] Backward-compatible Turbo Tunnel in Snowflake

David Fifield david at bamsoftware.com
Thu Feb 6 03:17:34 UTC 2020


On Wed, Feb 05, 2020 at 05:03:33PM -0500, Cecylia Bocovich wrote:
> The compatibility code at the server seems like a good idea to me, but I
> want to add another option to consider even though I agree that the
> current way forward is the least complex for now.
> 
> We have in the unmapped future a desire to prepare snowflake for another
> bridge (https://trac.torproject.org/projects/tor/ticket/28651) and there
> is some desire for client choice about which bridge is used
> (https://trac.torproject.org/projects/tor/ticket/31661). One option is
> for the client to issue something like a SOCKS connect request to a
> proxy when it first makes a connection and for the proxy to read the
> first X bytes and use that information to open a connection to a
> Snowflake bridge of the user's request. They could default to a known
> bridge if the old version of the protocol is used.
> 
> As David mentioned, this has the disadvantage of requiring a proxy
> upgrade. However, we've done a non-backwards compatible proxy upgrade
> before with https://trac.torproject.org/projects/tor/ticket/29207 and it
> worked pretty well. The webextension proxies updated quickly and we run
> (half?) of the standalone proxies now so we can restart them ourselves.
> The broker will send back error messages that will be logged by
> non-updated standalone proxies if we force the update at the broker by
> bumping the required broker-proxy protocol version.

Yeah I'm not opposed to coordinating proxy upgrades in all cases, I just
don't want to do it if we don't have to, especially if it's going to
require its own non-trivial design.



More information about the anti-censorship-team mailing list