Opened 16 months ago

Last modified 7 months ago

#29260 new task

Should Snowflake proxies have a way to identify themselves to the broker

Reported by: ahf Owned by:
Priority: Medium Milestone:
Component: Circumvention/Snowflake Version:
Severity: Normal Keywords:
Cc: dcf, arlolra, cohosh, ahf Actual Points: 6
Parent ID: Points: 1
Reviewer: Sponsor: Sponsor28-can


Would it make sense for us to have an identity key (or something similar) for Snowflake proxies to allow them to identify themselves to the broker service.

This would allow us to later build reputation systems for the proxies and distribute snowflake proxies in a smart way based of stability/uptime. The downside from a privacy perspective is that the broker can follow the Snowflake proxies' movements on the internet, which means we might want to make it optional.

Child Tickets

Change History (15)

comment:1 Changed 16 months ago by gaba

Keywords: network-team-roadmap-2019-Q1Q2 added
Points: 1

comment:2 Changed 14 months ago by cohosh

Owner: set to cohosh
Status: newassigned

comment:3 Changed 14 months ago by cohosh

Parent ID: #29207

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.

comment:4 Changed 14 months ago by gaba

Keywords: network-team-roadmap-2019-Q1Q2 removed

comment:5 Changed 13 months ago by cohosh

Status: assignednew

just un-assigning myself because it's not high priority at the moment.

comment:6 Changed 12 months ago by gaba

Keywords: ex-sponsor-19 added

Adding the keyword to mark everything that didn't fit into the time for sponsor 19.

comment:7 Changed 12 months ago by phw

Sponsor: Sponsor19Sponsor28-must

Moving from Sponsor 19 to Sponsor 28.

comment:8 Changed 12 months ago by gaba

Keywords: anti-censorship-roadmap added
Owner: changed from cohosh to ahf
Status: newassigned

comment:9 Changed 12 months ago by ahf

Actual Points: 6
Status: assignednew

During the anti-censorship team meeting today we decided to skip doing this. The amount of complexity added to the Snowflake codebase is too great for this feature for now. Maybe we want to redo it in the future.

The patch to do this via WebSocket can be seen at

It uses the NIST P-256 Curve for public key authentication, which is chosen over for example Ed25519 because it's currently (as of 2019) available in the WebCrypto API available in most modern browsers.

comment:10 Changed 12 months ago by ahf

Cc: ahf added
Owner: ahf deleted
Status: newassigned

comment:11 Changed 12 months ago by ahf

Status: assignednew

comment:12 Changed 11 months ago by arlolra

Milestone: Tor: unspecified
Version: Tor: unspecified

comment:13 Changed 11 months ago by gaba

Keywords: anti-censorship-roadmap-october added; ex-sponsor-19 anti-censorship-roadmap removed

comment:14 Changed 11 months ago by gaba

Keywords: anti-censorship-roadmap-october removed
Sponsor: Sponsor28-mustSponsor28-can

comment:15 Changed 7 months ago by cohosh

Parent ID: #29207
Note: See TracTickets for help on using tickets.