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

Mailing Lists tor-relays
41

Gary C. New via tor-relays:

Georg,

Are there any "Issues" submitted for a similar change to Concensus Weight and Relay Probability to Tor Metrics on Onionoo? It appears these values are still only being reported for a Single Tor Node.

Hrm, good question. I don't think so and I am not sure yet, whether we

should make such a change.

Do you mind me asking what the reluctance might be to extending Tor Metrics to include correct reporting of Concensus Weight and Relay Probability for Loadbalanced Tor Relays? It would provide a more accurate assessment of Tor Network Resources and assist DirectoryAuthorities in making more informed decisions.

There is no real reluctance here on my side. It's just that I don't have thought about yet what kind of extra work it would involve and what the pros and cons of that actually are.

I would be happy to open an "Issue" on the topic for official Request For Consideration.

Yes, please do. I think The Tor Project / Network Health / Metrics / Relay Search · GitLab is a good project to file the issue and have some discussion and context in and then we can open child tickets in other projects in case we need to do work somewhere else as well to make your request happen.

Thank you and the Tor Metrics Team for all that you do in improving the Tor Network.

You are welcome! Thanks for running relays.

Georg

···

Respectfully,

Gary—
This Message Originated by the Sun.
iBigBlue 63W Solar Array (~12 Hour Charge)
+ 2 x Charmast 26800mAh Power Banks
= iPhone XS Max 512GB (~2 Weeks Charged)

     On Friday, March 4, 2022, 12:22:06 AM MST, Georg Koppen <gk@torproject.org> wrote:
    Gary C. New via tor-relays:

Georg,
Yes! That is precisely it!
Please know that the change appears to be working with my loadbalanced Tor Relay deployment as well.
Are there any "Issues" submitted for a similar change to Concensus Weight and Relay Probability to Tor Metrics on Onionoo? It appears these values are still only being reported for a Single Tor Node.

Hrm, good question. I don't think so and I am not sure yet, whether we
should make such a change.

A BIG Thank You to the Tor Metrics Team for the Issue-40022 implementation.

You are welcome. It seems, though, the implementation was not correct.
We therefore reverted it for now. However, we are on it. :slight_smile:

Georg

Respectfully,

Gary—
This Message Originated by the Sun.
iBigBlue 63W Solar Array (~12 Hour Charge)
+ 2 x Charmast 26800mAh Power Banks
= iPhone XS Max 512GB (~2 Weeks Charged)

   On Thursday, March 3, 2022, 1:28:12 PM MST, Georg Koppen &lt;gk@torproject\.org&gt; wrote:

     Gary C. New via tor-relays:

David,
Has Tor Metrics implemented your RFC related to Written Bytes per Second and Read Bytes per Second on Onionoo?

That's probably

Graphs for multiple relays that have the same fingerprint (#40022) · Issues · The Tor Project / Network Health / Metrics / Onionoo · GitLab

, no?

Georg

As of the 27th of February, I've noticed a change in reporting that accurately reflects the aggregate of my Tor Relay Nodes opposed to the previously reported Single Tor Node. Are you seeing a similar change for snowflake.torproject.org?
Additionally, other than the hourly stacktrace errors in the syslog, the secure_onion_key workaround seems to be working well without any ill side-effects. I've been able to operate with the same secure_onion_key for close to 5 weeks, now. Have you run into any issues?
Thank you for your response.
Respectfully,

Gary—
This Message Originated by the Sun.
iBigBlue 63W Solar Array (~12 Hour Charge)
+ 2 x Charmast 26800mAh Power Banks
= iPhone XS Max 512GB (~2 Weeks Charged)

     On Tuesday, February 8, 2022, 11:49:47 PM MST, Gary C\. New via tor\-relays &lt;tor\-relays@lists\.torproject\.org&gt; wrote:

       David,
Excellent Documentation and References!
I hope the proposed RFC's (auth, key, and metrics) for loadbalanced Tor topologies are seriously considered and implemented by Tor Core and Tor Metrics.
Great Work!
Respectfully,

Gary—
This Message Originated by the Sun.
iBigBlue 63W Solar Array (~12 Hour Charge)
+ 2 x Charmast 26800mAh Power Banks
= iPhone XS Max 512GB (~2 Weeks Charged)

     On Tuesday, February 8, 2022, 10:02:53 AM MST, David Fifield &lt;david@bamsoftware\.com&gt; wrote:

       The load-balanced Snowflake bridge is running in production since
2022-01-31. Thanks Roger, Gary, Roman for your input.

Hopefully reproducible installation instructions:
Snowflake Bridge Installation Guide · Wiki · The Tor Project / Anti-censorship / Team · GitLab
Observations since:
https://bugs.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/40095#note_2774428

Metrics graphs are currently confused by multiple instances of tor
uploading descriptors under the same fingerprint. Particularly in the
interval between 2022-01-25 and 2022-02-03, when a production bridge and
staging bridge were running in parallel, with four instances being used
and another four being mostly unused.
Relay Search
Users – Tor Metrics
Since 2022-02-03, it appears that Metrics is showing only one of the
four running instances per day. Because all four instances are about
equally used (as if load balanced, go figure), the values on the graph
are 1/4 what they should be. The reported bandwidth of 5 MB/s is
actually 20 MB/s, and the 2500 clients are actually 10000. All the
necessary data are present in Collector, it's just a question of data
processing. I opened an issue for the Metrics graphs, where you can also
see some manually made graphs that are closer to the true values.
Graphs for multiple relays that have the same fingerprint (#40022) · Issues · The Tor Project / Network Health / Metrics / Onionoo · GitLab

I started a thread on tor-dev about the issues of onion key rotation and
ExtORPort authentication.
The tor-dev February 2022 Archive by thread
_______________________________________________
tor-relays mailing list
tor-relays@lists.torproject.org
tor-relays Info Page
_______________________________________________
tor-relays mailing list
tor-relays@lists.torproject.org
tor-relays Info Page
       
_______________________________________________
tor-relays mailing list
tor-relays@lists.torproject.org
tor-relays Info Page

_______________________________________________
tor-relays mailing list
tor-relays@lists.torproject.org
tor-relays Info Page
     
_______________________________________________
tor-relays mailing list
tor-relays@lists.torproject.org
tor-relays Info Page

_______________________________________________
tor-relays mailing list
tor-relays@lists.torproject.org
tor-relays Info Page
   
_______________________________________________
tor-relays mailing list
tor-relays@lists.torproject.org
tor-relays Info Page

1 Like
42

I don't know if it is necessary for ordinary bridges to expose the
ORPort. For a long time, it was necessary, because BridgeDB used the
ORPort to check that a bridge was running, before distributing it to
users. See:

But now there is rdsys and bridgestrap, which may have the ability to
test the obfs4 port rather than the ORPort. I cannot say whether that
removes the requirement to expose the ORPort.

For the special case of the default bridges shipped with Tor Browser, it
is not necessary to export the ORPort, because those bridges are not
distributed by rdsys.

···

On Fri, Dec 09, 2022 at 01:09:05AM +0000, Gary C. New wrote:

Is it truly necessary to expose the ORPort to the World in a pluggable
transport configuration?

_______________________________________________
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

1 Like
43

David,

I finally have time to migrate my loadbalanced Tor relay to a loadbalanced Tor obfs4proxy configuration.

In the process, I’ve been reviewing this thread and was hoping you could help with one clarification regarding your loadbalanced Tor snowflake configuration?

I noticed that you are using “AssumeReachable 1” in your torrc and was wondering whether you are exposing your ORPort to the World?

In the obfs4proxy configuration examples, it states that the ORPort needs to be open to the World, but it isn’t clear in your torrc example whether you expose it to the World.

Is it truly necessary to expose the ORPort to the World in a pluggable transport configuration?

Thank you for your assistance.

Respectfully,

Gary

···

—
This Message Originated by the Sun.
iBigBlue 63W Solar Array (~12 Hour Charge)

  • 2 x Charmast 26800mAh Power Banks
    = iPhone XS Max 512GB (~2 Weeks Charged)

On Friday, March 4, 2022, 05:55:48 PM MST, Gary C. New garycnew@yahoo.com wrote:

David,

When I made my own combined graphs, I relied on different instances
having different nicknames. I don’t know an easy way to distinguish the
descriptors of different instances otherwise.

Please let me know what the Tor Metrics Team decides, if/when they reimplement the change.

You could conceivably do it by analyzing the periodicity of different
instances’ publishing schedules. (Start one instance on the hour,
another at :10, another at :20, etc.) But that seems fragile, not to
mention annoying to deal with.

I agree. I’d rather manage unique nicknames.

Thanks, again.

Gary
—
This Message Originated by the Sun.
iBigBlue 63W Solar Array (~12 Hour Charge)

  • 2 x Charmast 26800mAh Power Banks
    = iPhone XS Max 512GB (~2 Weeks Charged)

On Friday, March 4, 2022, 4:52:49 PM MST, David Fifield david@bamsoftware.com wrote:

On Fri, Mar 04, 2022 at 09:40:01PM +0000, Gary C. New wrote:

I see that the metrics change has been reverted.

If/When the metrics change is implemented, will loadbalanced Tor Relay Nodes
need to be uniquely named or will they all be able to use the same nickname?

When I made my own combined graphs, I relied on different instances
having different nicknames. I don’t know an easy way to distinguish the
descriptors of different instances otherwise.

You could conceivably do it by analyzing the periodicity of different
instances’ publishing schedules. (Start one instance on the hour,
another at :10, another at :20, etc.) But that seems fragile, not to
mention annoying to deal with.

tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

44

Would be a step toward to make scanning for bridges harder IMO, if the ORPort is no longer needed to be exposed.

···

On 12/9/22 07:02, David Fifield wrote:

But now there is rdsys and bridgestrap, which may have the ability to
test the obfs4 port rather than the ORPort. I cannot say whether that
removes the requirement to expose the ORPort.

--
Toralf

45

David,

In my implementation of the loadbalanced OBFS4 configuration, it appears that BridgeDB still tests the ORPort for availability and without it marks the OBFS4 bridge as being down.

I gather that default bridges don’t require a DistributionMethod as your loadbalanced Snowflake configuration is set to “none?”

BTW… I have the loadbalanced OBFS4 configuration up and running, and am able to manually confirm loadbalanced OBFS4 connections are successfull.

nginx => obfs4proxy => tor

I believe it’s time to enable a DistributionMethod.

Thank you for the clarifications.

Respectfully,

Gary

···

—
This Message Originated by the Sun.
iBigBlue 63W Solar Array (~12 Hour Charge)

  • 2 x Charmast 26800mAh Power Banks
    = iPhone XS Max 512GB (~2 Weeks Charged)

On Thursday, December 8, 2022, 10:03:09 PM PST, David Fifield david@bamsoftware.com wrote:

On Fri, Dec 09, 2022 at 01:09:05AM +0000, Gary C. New wrote:

Is it truly necessary to expose the ORPort to the World in a pluggable
transport configuration?

I don’t know if it is necessary for ordinary bridges to expose the
ORPort. For a long time, it was necessary, because BridgeDB used the
ORPort to check that a bridge was running, before distributing it to
users. See:
https://bugs.torproject.org/tpo/core/tor/7349
But now there is rdsys and bridgestrap, which may have the ability to
test the obfs4 port rather than the ORPort. I cannot say whether that
removes the requirement to expose the ORPort.
https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/merge_requests/36

For the special case of the default bridges shipped with Tor Browser, it
is not necessary to export the ORPort, because those bridges are not
distributed by rdsys.

tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

1 Like
46

You are entirely correct. It's been noted as a discoverability
vulnerability for over 10 years now. But so far attempts to resolve
https://bugs.torproject.org/tpo/core/tor/7349 have fallen short.

···

On Fri, Dec 09, 2022 at 10:16:47AM +0100, Toralf Förster wrote:

On 12/9/22 07:02, David Fifield wrote:
> But now there is rdsys and bridgestrap, which may have the ability to
> test the obfs4 port rather than the ORPort. I cannot say whether that
> removes the requirement to expose the ORPort.

Would be a step toward to make scanning for bridges harder IMO, if the
ORPort is no longer needed to be exposed.

_______________________________________________
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

47

In my implementation of the loadbalanced OBFS4 configuration, it appears that BridgeDB still tests the ORPort for availability and without it marks the OBFS4 bridge as being down.

I see. Then yes, I suppose it is still necessary to expose the ORPort.

I gather that default bridges don't require a DistributionMethod as your loadbalanced Snowflake configuration is set to "none?"

That's correct. Default bridges are not distributed by rdsys, they are
distributed in the configuration of Tor Browser itself. See
extensions.torlauncher.default_bridge.* in about:config.

···

On Fri, Dec 09, 2022 at 08:43:26AM +0000, Gary C. New wrote:
_______________________________________________
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

48

David,

I’m in the process of trying to cross-compile snowflake for OpenWRT and Entware. Are there any other dependencies to compile snowflake other than Go?

Do you know if it’s possible to configure multiple pluggable transports with different listeners within a single torrc?

Thanks, again.

Gary

···

—
This Message Originated by the Sun.
iBigBlue 63W Solar Array (~12 Hour Charge)

  • 2 x Charmast 26800mAh Power Banks
    = iPhone XS Max 512GB (~2 Weeks Charged)

On Friday, December 9, 2022, 8:43:03 PM PST, David Fifield david@bamsoftware.com wrote:

On Fri, Dec 09, 2022 at 08:43:26AM +0000, Gary C. New wrote:

In my implementation of the loadbalanced OBFS4 configuration, it appears that BridgeDB still tests the ORPort for availability and without it marks the OBFS4 bridge as being down.

I see. Then yes, I suppose it is still necessary to expose the ORPort.

I gather that default bridges don’t require a DistributionMethod as your loadbalanced Snowflake configuration is set to “none?”

That’s correct. Default bridges are not distributed by rdsys, they are
distributed in the configuration of Tor Browser itself. See
extensions.torlauncher.default_bridge.* in about:config.

tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

49

I'm in the process of trying to cross-compile snowflake for OpenWRT and
Entware. Are there any other dependencies to compile snowflake other than Go?

The README should list dependencies. Setting GOOS and GOARCH should be
sufficient.

Do you know if it's possible to configure multiple pluggable transports with
different listeners within a single torrc?

Yes. You cannot configure multiple listeners for the same transport, but
you can use multiple different transports at once. Use use different
sets of ServerTransportPlugin / ServerTransportListenAddr /
ServerTransportOptions, or ClientTransportPlugin / Bridge for the client
side.

···

On Sat, Dec 10, 2022 at 05:19:43AM +0000, Gary C. New via tor-relays wrote:
_______________________________________________
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

50

Great! I’ll work on compiling the Standalone Snowflake Proxy and see about implementing a loadbalanced OBFS & Snowflake configuration in parallel.

Thank you for your assistance.

Respectfully,

Gary

···

On Saturday, December 10, 2022, 8:01:15 AM MST, David Fifield david@bamsoftware.com wrote:

On Sat, Dec 10, 2022 at 05:19:43AM +0000, Gary C. New via tor-relays wrote:

I’m in the process of trying to cross-compile snowflake for OpenWRT and
Entware. Are there any other dependencies to compile snowflake other than Go?

The README should list dependencies. Setting GOOS and GOARCH should be sufficient.

Do you know if it’s possible to configure multiple pluggable transports with
different listeners within a single torrc?

Yes. You cannot configure multiple listeners for the same transport, but you can use multiple different transports at once. Use use different sets of ServerTransportPlugin / ServerTransportListenAddr / ServerTransportOptions, or ClientTransportPlugin / Bridge for the client side.

51

David,

I was successfully able to get Snowflake cross-compiled and installed for OpenWRT and Entware as a package.

opkg install ./snowflake_2.4.1-1_armv7-2.6.ipk

Installing snowflake (2.4.1-1) to root…
Configuring snowflake.

opkg info snowflake

Package: snowflake
Version: 2.4.1-1
Depends: libc, libssp, librt, libpthread
Status: install user installed
Architecture: armv7-2.6
Installed-Time: 1670730403

opkg depends snowflake

snowflake depends on:
libc
libssp
librt
libpthread

opkg files snowflake

Package snowflake (2.4.1-1) is installed on root and has the following files:
/opt/bin/proxy
/opt/bin/client
/opt/bin/probetest
/opt/bin/broker
/opt/bin/server
/opt/bin/distinctcounter

/opt/bin/proxy -version

snowflake-proxy 2.4.1

However, I still need to configure it within the torrc file and test it with its own listener in parallel with the loadbalanced OBFS configuration.

Thanks, again, for your guidance.

Respectfully,

Gary

P.S. I posted the Snowflake Package Makefile on the OpenWRT forum for reference:

···

On Saturday, December 10, 2022, 12:05:51 PM MST, Gary C. New garycnew@yahoo.com wrote:

On Saturday, December 10, 2022, 8:01:15 AM MST, David Fifield david@bamsoftware.com wrote:

On Sat, Dec 10, 2022 at 05:19:43AM +0000, Gary C. New via tor-relays wrote:

I’m in the process of trying to cross-compile snowflake for OpenWRT and
Entware. Are there any other dependencies to compile snowflake other than Go?

The README should list dependencies. Setting GOOS and GOARCH should be sufficient.

Do you know if it’s possible to configure multiple pluggable transports with
different listeners within a single torrc?

Yes. You cannot configure multiple listeners for the same transport, but you can use multiple different transports at once. Use use different sets of ServerTransportPlugin / ServerTransportListenAddr / ServerTransportOptions, or ClientTransportPlugin / Bridge for the client side.

Great! I’ll work on compiling the Standalone Snowflake Proxy and see about implementing a loadbalanced OBFS & Snowflake configuration in parallel.

Thank you for your assistance.

Respectfully,

Gary

1 Like
52

I was successfully able to get Snowflake cross-compiled and installed for
OpenWRT and Entware as a package.

Thanks, nice work.

# opkg files snowflake
Package snowflake (2.4.1-1) is installed on root and has the following files:
/opt/bin/proxy
/opt/bin/client
/opt/bin/probetest
/opt/bin/broker
/opt/bin/server
/opt/bin/distinctcounter

I don't think it makes sense to package the server or broker for
OpenWRT. The client and proxy, sure. But the server and broker do not
even run on the same host in an actual deployment. distinctcounter is
just a metrics utility for the broker:

···

On Sun, Dec 11, 2022 at 04:25:06AM +0000, Gary C. New via tor-relays wrote:
_______________________________________________
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

53

I agree it makes sense to package the client and proxy separate from the broker and server. This was just a quick and dirty test to see if I could get Snowflake cross-compiled and working on the OpenWRT and Entware platforms.

I am having some issues or misunderstandings with implementing Snowflake Proxy within Tor. I assumed that implementing Snowflake Proxy within Tor would be similar to OBFS4Bridge in that Tor would initialize Snowflake Proxy as a managed Pluggable Transport listening on the assigned ServerTransportListenAddr. I can see Snowflake Proxy initiate outbound requests, but I don’t see it listen on the specified ServerTransportListenAddr and Port.

NOTE: Basic Inbound Connection Flow is Nginx (xxx.xxx.xxx.xxx:6031) => Snowflake Proxy (192.168.0.31:6031) => Tor (192.168.0.31:9001)

NOTE: I am only running Snowflake Proxy within the test torrc configuration.

cat torrc

…
Nickname Snowflake31
ORPort xxx.xxx.xxx.xxx:443 NoListen
ORPort 192.168.0.31:9001 NoAdvertise
BridgeRelay 1
BridgeDistribution moat
ExtORPort 192.168.0.31:auto
###ServerTransportPlugin obfs31-1 exec /opt/bin/obfs4proxy -enableLogging
###ServerTransportListenAddr obfs31-1 192.168.0.31:3031
ServerTransportPlugin snowflake31-1 exec /opt/bin/proxy -log /tmp/snowflake.log -verbose
ServerTransportListenAddr snowflake31-1 192.168.0.31:6031

ps w | grep -I tor

26303 tor 253m S /opt/sbin/tor -f /tmp/torrc --quiet
26304 tor 795m S /opt/bin/proxy -log /tmp/snowflake.log -verbose

netstat -anp | grep proxy

tcp 0 0 192.168.0.31:49850 37.218.245.111:443 ESTABLISHED 26304/proxy
udp 0 0 192.168.0.31:33961 0.0.0.0:* 26304/proxy
udp 0 0 0.0.0.0:52654 0.0.0.0:* 26304/proxy

tail -f /tmp/snowflake.log

…
2022/12/12 04:28:33 snowflake-proxy 2.4.1
2022/12/12 04:28:33 Proxy starting
2022/12/12 04:28:33 WebRTC: Created offer
2022/12/12 04:28:33 WebRTC: Set local description
2022/12/12 04:28:33 Offer: {“type”:“offer”,“sdp”:“v=0\r\no=- 4129729503856148472 1670819313 IN IP4 [scrubbed]\r\ns=-\r\nt=0 0\r\na=fingerprint:sha-256 3B:60:50:33:72:A1:35:91:44:7E:02:2E:F2:4E:0E:21:C2:24:1C:47:F7:43:A1:A7:F3:DE:BA:AB:3E:82:9E:11\r\na=extmap-allow-mixed\r\na=group:BUNDLE 0\r\nm=application 9 UDP/DTLS/SCTP webrtc-datachannel\r\nc=IN IP4 [scrubbed]\r\na=setup:actpass\r\na=mid:0\r\na=sendrecv\r\na=sctp-port:5000\r\na=ice-ufrag:glNJtRHnBjaRYRkg\r\na=ice-pwd:OxntNuRslEPhLgSstUnzwJFTPzPUGmzt\r\na=candidate:551460743 1 udp 2130706431 [scrubbed] 50786 typ host\r\na=candidate:551460743 2 udp 2130706431 [scrubbed] 50786 typ host\r\na=candidate:1335998215 1 udp 1694498815 [scrubbed] 45684 typ srflx raddr [scrubbed] rport 45684\r\na=candidate:1335998215 2 udp 1694498815 [scrubbed] 45684 typ srflx raddr [scrubbed] rport 45684\r\na=end-of-candidates\r\n”}
2022/12/12 04:29:00 NAT Type measurement: unknown → restricted = restricted
2022/12/12 04:29:00 NAT type: restricted
…
2022/12/12 04:29:11 sdp offer successfully received.
2022/12/12 04:29:11 Generating answer…
…
2022/12/12 04:29:31 Timed out waiting for client to open data channel.
2022/12/12 04:29:41 sdp offer successfully received.
2022/12/12 04:29:41 Generating answer…
2022/12/12 04:30:02 Timed out waiting for client to open data channel.
…
2022/12/12 04:32:05 sdp offer successfully received.
2022/12/12 04:32:05 Generating answer…
2022/12/12 04:32:26 Timed out waiting for client to open data channel.

Is it possible to use Snowflake Proxy as a managed Pluggable Transport similar to OBFS4Bridge within Tor? It would be helpful to have a torrc configuration example within the Standalone Snowflake Proxy documentation.

Thanks, again, for your guidance and assistance.

Respectfully,

Gary

···

On Monday, December 12, 2022, 08:31:43 AM MST, David Fifield david@bamsoftware.com wrote:

On Sun, Dec 11, 2022 at 04:25:06AM +0000, Gary C. New via tor-relays wrote:

I was successfully able to get Snowflake cross-compiled and installed for
OpenWRT and Entware as a package.

Thanks, nice work.

opkg files snowflake

Package snowflake (2.4.1-1) is installed on root and has the following files:
/opt/bin/proxy
/opt/bin/client
/opt/bin/probetest
/opt/bin/broker
/opt/bin/server
/opt/bin/distinctcounter

I don’t think it makes sense to package the server or broker for
OpenWRT. The client and proxy, sure. But the server and broker do not
even run on the same host in an actual deployment. distinctcounter is
just a metrics utility for the broker:
Support Distinct IP Counting (!95) · Merge requests · The Tor Project / Anti-censorship / Pluggable Transports / Snowflake · GitLab

54

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.

Unlike, say, obfs4, in Snowflake the bridges are centralized and the
proxies are decentralized. If you run a proxy you don't also run a
bridge.

If it helps the mental model: the standalone proxy program in Snowflake
does exactly the same thing as the browser extension proxy
(The Tor Project / Anti-censorship / Pluggable Transports / Snowflake WebExtension · GitLab).
Those browser proxies don't have an attached tor process; neither does
the command-line proxy.

···

On Mon, Dec 12, 2022 at 08:19:53PM +0000, Gary C. New via tor-relays wrote:

I am having some issues or misunderstandings with implementing Snowflake Proxy
within Tor. I assumed that implementing Snowflake Proxy within Tor would be
similar to OBFS4Bridge in that Tor would initialize Snowflake Proxy as a
managed Pluggable Transport listening on the assigned
ServerTransportListenAddr. I can see Snowflake Proxy initiate outbound
requests, but I don't see it listen on the specified ServerTransportListenAddr
and Port.

_______________________________________________
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

55

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 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)?

What about a connection flow of haproxy/nginx => (snowflake-server => extor-static-cookie => tor) on separate servers?

Thanks, again.

Gary

···

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.

56

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

···

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:

_______________________________________________
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

57

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.

Created a Makefile for extra-static-cookie for OpenWRT and Entware:

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 goal of running multiple obfs4proxy listeners is to offer numerous, unique
bridges distributed across several servers maximizing resources and availability.

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.

Hmm… If normal bridges will not see enough users to justify the deployment
of numerous, unique bridges distributed over several servers–this may be a
deciding factor. I don’t have enough experience with normal bridges to know.

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.

I’ve installed and started configuring snowflake-server and have some questions
after reading the README:

  1. How are Snowflake Bridges advertised? Will they compromise a Normal Bridge
    running on the same public addresses?

  2. I already have a DNS Let’s Encrypt process in place for certificates and port 80
    (HTTP) is already in use by another daemon on my server. Is there an alternative method
    to provide snowflake-server with the required certificates?

  3. I’m using an init.d (not systemd) operating system. Do you have any init.d examples
    for snowflake-server?

In short, I’m trying to get a sense of whether it makes sense to run a Snowflake Bridge
and Normal Bridge on the same public addresses?

Thanks, again, for your assistance.

Respectfully,

Gary

···

On Tuesday, December 13, 2022, 07:35:23 PM MST, David Fifield david@bamsoftware.com wrote:
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:

58

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

Created a Makefile for extra-static-cookie for OpenWRT and Entware:

Extor-static-cookie Makefile - Community Builds, Projects & Packages - OpenWrt Forum

I appreciate the enthusiasm, but I should reiterate: there is no reason
to ever use this tool on OpenWRT. Packaging it is a mistake. If you
think you need it, you misunderstand what it is for.

> 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 goal of running multiple obfs4proxy listeners is to offer numerous, unique
bridges distributed across several servers maximizing resources and
availability.

If the purpose is running on several different servers, you don't need a
load balancer and you don't need extor-static-cookie. Those tools are
meant for running *one* instance of a pluggable transport on *one*
server. If you want to distribute bridges over multiple servers, just
run one instance each of tor and obfs4proxy on multiple servers, in the
normal way. You don't need anything fancy.

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

Hmm... If normal bridges will not see enough users to justify the deployment
of numerous, unique bridges distributed over several servers--this may be a
deciding factor. I don't have enough experience with normal bridges to know.

Some pluggable transports, like obfs4, need there to be many bridges,
because they are vulnerable to being blocked by IP address. Each
individual bridge does not get much traffic, because there are so many
of them. With obfs4, it's not about load, it's about address diversity.
Just run multiple independent bridges if you want to increase your
contribution.

Snowflake is unlike obfs4 in that it does not depends on there being
multiple bridges for its blocking resistance. Snowflake gets its address
diversity at a different layer—the Snowflake proxies. There are many
proxies, but there only needs to be one bridge. However, that one
bridge, because it receives the concentrated traffic of many users,
needs special scaling techniques.

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

I've installed and started configuring snowflake-server and have some questions
after reading the README:

In short, I'm trying to get a sense of whether it makes sense to run a
Snowflake Bridge and Normal Bridge on the same public addresses?

There is no reason at all to run a Snowflake bridge. No user will ever
connect to it, because Snowflake bridges are not distributed through
BridgeDB like obfs4 bridges are; they are shipping in configuration
files with Tor Browser or Orbot. There is no need for volunteers to run
Snowflake bridges, and no benefit to them doing so. If you want to help,
run a Snowflake proxy.

There is no reason for a volunteer bridge operator to run
snowflake-server or extor-static-cookie, ever. Packaging them for
OpenWRT can only cause confusion. You do not need these programs.

···

On Fri, Dec 16, 2022 at 04:27:06AM +0000, Gary C. New via tor-relays wrote:

On Tuesday, December 13, 2022, 07:35:23 PM MST, David Fifield > <david@bamsoftware.com> wrote:
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:

_______________________________________________
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

1 Like