Draft: feat: allow client to specify relayURL directly
...instead of relying on the broker to know the URL by fingerprint.
This change is backwards-compatible, i.e. clients can still specify servers by fingerprint.
A side effect is that clients can now ask proxies to connect to an arbitrary port of the server, and provide an arbitrary HTTP path and query parameters (as long the proxy allows the specified hostname). Path being arbitrary should not really be a big concern for security, since the data being sent to the server through WebSocket is already arbitrary. The port thing can be fixed by !381 (closed).
This change does not affect proxy, since it is already receiving
relayURL in the offer from the broker and checks that URL against its
RelayDomainNamePattern.
It's worth mentioning that the broker, unlike the proxy, doesn't check
the requested relayURL's scheme, so in fact the proxy might reject
the client's offer based on the scheme, despite the client's request
passing the broker's allowed-relay-pattern check.
With this change it is now possible to get rid of the broker's
bridge-list-path parameter: the broker needs not be aware of
the concept of "fingerprints".
It only needs to check whether the proxies are able to connect to
the server requested by the client (see allowed-relay-pattern).
But of course we'd want to keep the "old way" at least for
backwards-compatibility.
Motivation for the change
Snowflake is advertised to be a generic pluggable transport not specific to Tor, and the "fingerprint" thing is specific to Tor, so it is desirable to make Snowflake not reliant on that.
To be more practical, the current way (mapping fingerprints to URLs on the broker side) requires that the broker knows all the URLs that the clients might want to access through proxies. This is not good if someone wants to set up a Snowflake network where the proxies can connect to arbitrary (or more or less arbitrary) addresses. See
- Dedicated Snowflake server port as a way to tell if host allows Snowflake connections
- (More) Distributed servers
Things to check
-
Does the metrics code need to be updated? -
I did not test the client binary with Tor browser (the relay-urlSOCKS parameter). Using as a library works good. -
If you are feeling conservative, we can add a parameter to the broker that disallows the new behavior (i.e. disallow clients to specify relayURLdirectly).
Related: