Opened 5 months ago

Last modified 6 days ago

#29260 new task

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

Reported by: ahf Owned by:
Priority: Medium Milestone: Tor: unspecified
Component: Circumvention/Snowflake Version: Tor: unspecified
Severity: Normal Keywords: ex-sponsor-19, anti-censorship-roadmap
Cc: dcf, arlolra, cohosh, ahf Actual Points: 6
Parent ID: #29207 Points: 1
Reviewer: Sponsor: Sponsor28-must

Description

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 (11)

comment:1 Changed 4 months ago by gaba

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

comment:2 Changed 3 months ago by cohosh

Owner: set to cohosh
Status: newassigned

comment:3 Changed 3 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 2 months ago by gaba

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

comment:5 Changed 2 months ago by cohosh

Status: assignednew

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

comment:6 Changed 3 weeks 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 3 weeks ago by phw

Sponsor: Sponsor19Sponsor28-must

Moving from Sponsor 19 to Sponsor 28.

comment:8 Changed 13 days ago by gaba

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

comment:9 Changed 6 days 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 https://github.com/ahf/snowflake/commit/4ca9e0acd7d711fbe2568b6375cd6b57a2c1f965

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 6 days ago by ahf

Cc: ahf added
Owner: ahf deleted
Status: newassigned

comment:11 Changed 6 days ago by ahf

Status: assignednew
Note: See TracTickets for help on using tickets.