Opened 4 years ago

Last modified 3 years ago

#10196 new enhancement

allow the client to pick a specific relay for its registration

Reported by: infinity0 Owned by: dcf
Priority: Medium Milestone:
Component: Archived/Flashproxy Version:
Severity: Keywords:
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

Currently the flashproxy-client will ignore the Bridge line in torrc and connect to whatever relay the facilitator chooses to give it. The means that the client has no control over which relay it connects to; and the facilitator has full control.

Possibly you avoided this design on purpose, but we could give this control back to the client - we can extend the client registration to support an optional explicit relay, and the facilitator will tell the proxy to connect to this relay. (If no relay is given, the facilitator falls-back to picking one of the relays it knows about, i.e. the current behaviour.)

Child Tickets

Change History (6)

comment:1 Changed 4 years ago by dcf

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.

comment:2 Changed 4 years ago by infinity0

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.

comment:3 Changed 4 years ago by infinity0

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 would help in this regard; the user could select multiple whitelisted bridges in his torrc.

comment:4 Changed 4 years ago by infinity0

Additionally, #9942 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.

comment:5 Changed 4 years ago by infinity0

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.

comment:6 Changed 3 years ago by infinity0

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.

Note: See TracTickets for help on using tickets.