On Tue, Dec 13, 2022 at 07:29:45PM +0000, Gary C. New via tor-relays wrote:
On Tuesday, December 13, 2022, 10:11:41 AM PST, David Fifield david@bamsoftware.com wrote:
The Snowflake proxy is not a pluggable transport. You just > run it as a normal command-line program. There is no torrc involved, and the proxy does not interact with a tor process at all.
Thank you for the clarification. It seems I incorrectly assumed that extor-static-cookie was a wrapper for snowflake-proxy.
"To work around this problem, there is a shim called [1]extor-static-cookie that presents an ExtORPort with a fixed, unchanging authentication key on a static port, and forwards the connections (again as ExtORPort) to tor, using that instance of tor's authentication key on an ephemeral port. One extor-static-cookie process is run per instance of tor, using ServerTransportPlugin and ServerTransportListenAddr."
Am I correct in assuming extor-static-cookie is only useful within the context of bridging connections between snowflake-server and tor (not as a pluggable transport similar to obfs4proxy)?
That's correct. extor-static-cookie is a workaround for a technical problem with tor's Extended ORPort. It serves a narrow and specialized purpose. It happens to use the normal pluggable transports machinery, but it is not a circumvention transport on its own. It's strictly for interprocess communication and is not exposed to the Internet. You don't need it to run a Snowflake proxy.
I am not sure what your plans are with running multiple obfs4proxy, but if you just want multiple obfs4 listeners, with different keys, running on different ports on the same host, you don't need a load balancer, extor-static-cookie, or any of that. Just run multiple instances of tor, each with its corresponding instance of obfs4proxy. The separate instances don't need any coordination or communication. The reason for all the complexity in the Snowflake is that there is *one* instance of the pluggable transport (snowflake-server) that needs to communicate with N instances of tor. And the only reason for doing that is that tor (C-tor) doesn't scale beyond one CPU. If tor could use more than one CPU (as we hope Arti will), we would not need or use any of these workarounds.
You could, in principle, use the same load-balanced setup with obfs4proxy, but I expect that a normal bridge will not get enough users to justify it. It only makes sense when the tor process hits 100% CPU and becomes a bottleneck, which for the Snowflake bridge only started to happen at around 6,000 simultaneous users.
What about a connection flow of haproxy/nginx => (snowflake-server => extor-static-cookie => tor) on separate servers?
You have the order wrong (it's snowflake-server → haproxy → extor-static-cookie → tor), but yes, you could divide the chain at any of the arrows and run things on different hosts. You could also run half the extor-static-cookie + tor on one host and half on another, etc.