<div>                On Tuesday, December 13, 2022, 07:35:23 PM MST, David Fifield <david@bamsoftware.com> wrote:<br><br>On Tue, Dec 13, 2022 at 07:29:45PM +0000, Gary C. New via tor-relays wrote:<br>>> On Tuesday, December 13, 2022, 10:11:41 AM PST, David Fifield<br>>> <david@bamsoftware.com> wrote:<br>>> <br>>> Am I correct in assuming extor-static-cookie is only useful within the context<br>>> of bridging connections between snowflake-server and tor (not as a pluggable<br>>> transport similar to obfs4proxy)?<br><br>> That's correct. extor-static-cookie is a workaround for a technical<br>> problem with tor's Extended ORPort. It serves a narrow and specialized<br>> purpose. It happens to use the normal pluggable transports machinery,<br>> but it is not a circumvention transport on its own. It's strictly for<br>> interprocess communication and is not exposed to the Internet. You don't<br>> need it to run a Snowflake proxy.<br><br>Created a Makefile for extra-static-cookie for OpenWRT and Entware:<br><br>https://forum.openwrt.org/t/extor-static-cookie-makefile/145694<br><br>> I am not sure what your plans are with running multiple obfs4proxy, but<br>> if you just want multiple obfs4 listeners, with different keys, running<br>> on different ports on the same host, you don't need a load balancer,<br>> extor-static-cookie, or any of that. Just run multiple instances of tor,<br>> each with its corresponding instance of obfs4proxy. The separate<br>> instances don't need any coordination or communication.<br><br>The goal of running multiple obfs4proxy listeners is to offer numerous, unique<br>bridges distributed across several servers maximizing resources and availability.<br><br>> You could, in principle, use the same load-balanced setup with<br>> obfs4proxy, but I expect that a normal bridge will not get enough users<br>> to justify it. It only makes sense when the tor process hits 100% CPU<br>> and becomes  a bottleneck, which for the Snowflake bridge only started<br>> to happen at around 6,000 simultaneous users.<br><br>Hmm...  If normal bridges will not see enough users to justify the deployment <br>of numerous, unique bridges distributed over several servers--this may be a <br>deciding factor. I don't have enough experience with normal bridges to know.<br><br>>> What about a connection flow of haproxy/nginx => (snowflake-server =><br>>> extor-static-cookie => tor) on separate servers?<br><br>> You have the order wrong (it's snowflake-server → haproxy →<br>> extor-static-cookie → tor), but yes, you could divide the chain at any<br>> of the arrows and run things on different hosts. You could also run half<br>> the extor-static-cookie + tor on one host and half on another, etc.<br><br>I've installed and started configuring snowflake-server and have some questions <br>after reading the README:<br><br>https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/tree/main/server<br><br>1. How are Snowflake Bridges advertised? Will they compromise a Normal Bridge <br>running on the same public addresses?<br><br>2. I already have a DNS Let's Encrypt process in place for certificates and port 80 <br>(HTTP) is already in use by another daemon on my server. Is there an alternative method <br>to provide snowflake-server with the required certificates?<br><br>3. I'm using an init.d (not systemd) operating system. Do you have any init.d examples <br>for snowflake-server?<br><br>In short, I'm trying to get a sense of whether it makes sense to run a Snowflake Bridge <br>and Normal Bridge on the same public addresses?<br><br>Thanks, again, for your assistance.<br><br>Respectfully,<br><br><br>Gary            </div>