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.