[tor-relays] How to reduce tor CPU load on a single bridge?

[David Fifield]

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 at 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.