[tor-bugs] #29260 [Obfuscation/Snowflake]: Should Snowflake proxies have a way to identify themselves to the broker

Tor Bug Tracker & Wiki blackhole at torproject.org
Wed Mar 27 14:48:50 UTC 2019


#29260: Should Snowflake proxies have a way to identify themselves to the broker
--------------------------------------------+------------------------------
 Reporter:  ahf                             |          Owner:  cohosh
     Type:  task                            |         Status:  assigned
 Priority:  Medium                          |      Milestone:  Tor:
                                            |  unspecified
Component:  Obfuscation/Snowflake           |        Version:  Tor:
                                            |  unspecified
 Severity:  Normal                          |     Resolution:
 Keywords:  network-team-roadmap-2019-Q1Q2  |  Actual Points:
Parent ID:  #29207                          |         Points:  1
 Reviewer:                                  |        Sponsor:  Sponsor19
--------------------------------------------+------------------------------
Changes (by cohosh):

 * parent:   => #29207


Comment:

 Part of this ticket involves the websocket protocol between the proxy and
 the broker (#29260).

 === How to persistently identifying proxies

 Another part of it is figuring out a way to persistently identify the
 proxy. We could do something similar to the relay fingerprint, which is a
 hash of the relay's identity key. The identity key (from the tor-spec) is:
 {{{
     - A long-term signing-only "Identity key" used to sign documents and
       certificates, and used to establish relay identity.
 }}}
 While proxies don't necessarily need an identity key at this point, we
 could have them randomly generate some kind of identity marker and then
 compute the hash of that to send to the broker.

 We could also do something a bit fancier here to preserve the privacy of
 proxies (in addition to making identification optional) by having them
 perform some proof that they are a part of a set of returning proxies
 rather than authenticating them individually. I think for now it's best to
 try something simple and make sure that the protocol is extensible and the
 implementation logic can be easily modified if we decide to change it.

 === Implementation details

 I think it makes sense to focus on the standalone proxy-go instances for
 now, since we are in the process of overhauling the browser-based proxies
 and potentially shifting to a Cupcake-like webextension (#23888).

 We need a place to store the identity fingerprint so that it will be
 persistent across restarts of proxy-go. The way tor accomplishes this is
 by storing the fingerprint in the data directory, which defaults to
 /var/lib/tor on linux.

 The only persistent files that proxy-go currently stores are log files,
 but I don't think it makes sense to store the fingerprint with the logs.
 For now it might be easiest to have an additional optional argument that
 takes a path to an identity file. If that identity file does not exist,
 proxy-go will generate a new identity fingerprint and save it in the file.
 Otherwise, it will read in the identity fingerprint and use it to identify
 itself to the broker.

 === How this ties into the Snowflake roadmap

 Eventually these persistent identities can be used to distribute proxies
 to clients that results in more stable, reliable connections. We could
 prevent low-bandwidth or unreliable proxies from throttling or dropping
 client traffic (#25681), or for more persistent proxies try to delay their
 blocking by handing them out in partitions similar to BridgeDB.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/29260#comment:3>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online


More information about the tor-bugs mailing list