allow the client to pick a specific relay for its registration

added archived-closed-2018-07-04 component::archived/flashproxy owner::dcf priority::medium resolution::wontfix severity::normal status::closed type::enhancement labels

We need to think through the security implications of allowing the client to control what endpoints proxies connect to. If would allow a (potentially malicious) client to initiate a TCP connection to any IP address--and exchange data with any WebSocket server that exists anywhere. The client could cause the proxy to send and receive arbitrary plaintext, plaintext that will be examined by your company or university's firewall.

As it is now, a malicious client gets to control only one endpoint of the communication, and cannot force the proxy to carry plaintext.

Some variant of this would be necessary for interoperability with other projects, such as i2p.

To deal with the security concern, perhaps we can have a Tor-specific facilitator that knows about Tor bridges, and an i2p-specific facilitator that knows about i2p relays, etc etc etc.

Alternatively (a little more complex for us but simpler for the facilitator runner) we could have a side program for all facilitators that automatically whitelists and adds e.g. Tor entry nodes, public i2p relays, etc.

For a quick-and-dirty solution to "connect to a different relay" the current suggested approach is to run your own facilitator.

We have an eye on the white-listing solution should other projects like i2p begin to add infrastructure to support this and other PTs.

#10429 (closed) would help in this regard; the user could select multiple whitelisted bridges in his torrc.

Additionally, #9942 (closed) would help with the "run your own facilitator" option. In my experience, proxies are mostly idle anyways. If we had a list of facilitators, e.g. inc those run by i2p / other projects, we could have each proxy round-robin between them, and we or {whoever hosts the proxy js} could add new projects' facilitators to the default-list to help them get bootstrapped with proxies.

In authenticated transfers (that resist active attacks) such as scramblesuit, each bridge has its own shared secret. A fog client running scramblesuit|websocket needs to know the shared-secret for the bridge that it connects to.

One way of doing this, is to solve this bug, then let the client express the shared-secret on the Bridge line. This would be consistent with other PTs.

Another way of doing this, is to let the facilitator (somehow) communicate the shared-secret back to the client. This would involve additional complexity in the proxy-client protocol, but also on the fog client side, since flashproxy would (somehow) need to pass this shared-secret back to scramblesuit.

I believe this bug is a cleaner solution than the latter, but I haven't thought of all possible solutions, so there may be a better one.

Another option is to refer to the Bridge by its fingerprint, and specify this (instead of the IP address) in the client registration. That way, we don't actually need to reveal its IP address to the client (which might be a good thing to do), and the facilitator can still select the right Bridge.

This ticket is more important than I originally realised - we need this behaviour if we want to let the client authenticate the Bridge, which currently doesn't happen with flashproxy or meek, and is a general design flaw with PTs that ignore the Bridge line - i.e. it affects more things than the combiner. I will follow up with a longer email to tor-dev.