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.
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Child items ...
Show closed items
Linked items 0
Link issues together to show that they're related.
Learn more.
Part of this ticket involves the websocket protocol between the proxy and the broker (#29260 (moved)).
=== 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 (moved)).
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 (moved)), or for more persistent proxies try to delay their blocking by handing them out in partitions similar to BridgeDB.
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.
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.
Trac: Status: assigned to new Actualpoints: N/Ato 6