Detected possible compression bomb on WebTunnel bridge

Support Relay Operator
,
1

I recently started offering a WebTunnel bridge behind one of my websites. It is running on Kubernetes behind Traefik using Gateway API. From my own tests it works fine and according to metrics.torproject.org it is distributed via “settings”. Its limited to 5MB/s with a 10MB/s peak + 100GB/day quota. No other ports are exposed to the internet.

However, I do not really see any traffic (i.e. 20-40MB a day). Is that expected? Will that grow over time?

Also I see those logs (similar to Possible Compression Bomb on Tor Logs ) which strike me as odd:

Jan 01 22:44:15.000 [notice] Bootstrapped 0% (starting): Starting
Jan 01 22:44:15.000 [notice] Starting with guard context “default”
Jan 01 22:44:21.000 [notice] Registered server transport ‘webtunnel’ at ‘[xxx]:443’
Jan 01 22:44:22.000 [notice] Bootstrapped 5% (conn): Connecting to a relay
Jan 01 22:44:22.000 [notice] Unable to find IPv4 address for ORPort 42744. You might want to specify IPv6Only to it or set an explicit address or set Address.
Jan 01 22:44:22.000 [notice] Bootstrapped 10% (conn_done): Connected to a relay
Jan 01 22:44:22.000 [notice] Bootstrapped 14% (handshake): Handshaking with a relay
Jan 01 22:44:22.000 [notice] Bootstrapped 15% (handshake_done): Handshake with a relay done
Jan 01 22:44:22.000 [notice] Bootstrapped 75% (enough_dirinfo): Loaded enough directory info to build circuits
Jan 01 22:44:22.000 [notice] Bootstrapped 90% (ap_handshake_done): Handshake finished with a relay to build circuits
Jan 01 22:44:22.000 [notice] Bootstrapped 95% (circuit_create): Establishing a Tor circuit
Jan 01 22:44:22.000 [notice] External address seen and suggested by a directory authority: x.x.x.x # note: correct IPv4
Jan 01 22:44:22.000 [notice] Bootstrapped 100% (done): Done
Jan 01 22:45:22.000 [notice] Not advertising Directory Service support (Reason: AccountingMax enabled)
Jan 01 22:49:22.000 [warn] Detected possible compression bomb with input size = 23059 and output size = 754016 (compression factor = 32.70)
Jan 01 22:49:22.000 [warn] Possible compression bomb; abandoning stream.
Jan 01 22:49:22.000 [warn] Unable to decompress HTTP body (tried Zstandard compressed, on Directory connection (client reading) with y.y.y.y:9001). # note: seems to be always the same IPv4
Jan 01 22:49:22.000 [warn] Detected possible compression bomb with input size = 25254 and output size = 808224 (compression factor = 32.00)
Jan 01 22:49:22.000 [warn] Possible compression bomb; abandoning stream.
Jan 01 22:50:22.000 [warn] Detected possible compression bomb with input size = 19694 and output size = 530725 (compression factor = 26.95)
Jan 01 22:50:22.000 [warn] Possible compression bomb; abandoning stream.
Jan 01 22:50:22.000 [warn] Detected possible compression bomb with input size = 18574 and output size = 514288 (compression factor = 27.69)

How can I receive a compression bomb on the directory connection? I do not expose that. Or am I missing something?

Other than that it seems to run and work fine. I am just a bit confused about the low usage.

1 Like
2

I don’t know about the compression bomb thing here, but if it’s not affecting the bridge, then possibly you’re getting low traffic because bridge users can’t connect to your bridge. It might be a manual SNI block, but it also might be some other block that’s happening recently in Russia where some hosting providers are nearly unreachable.

1 Like
3

I am on a known hosting provider which is mostly unreachable from Russia. For that reason I set up a separate bridge on rather unknown IP space. Lets see how that bridge will do in a few days.

Questions:

  1. Should I keep this bridge running even though its mostly unreachable?
  2. Will that do harm? Will it be filtered based on reachability to the audience? Should I shut it down?
  3. Should I better run OBFS4 or something else?
4

Well, my verdict is that advanced users are able to connect to it, the tool is linked here in the first post.

I wonder if running a Snowflake (standalone) bridge would not be subject to the packet blocking… The difference from obfs4 and WebTunnel is that it looks like a WebRTC call. (Standalone snowflakes are snowflakes that have open ports and can accept more connections concurrently than with closed ports)

Snowflake has logs that show usage statistics, if you want to you can run one and see how much traffic gets used after some time. (and try to filter the logs by country, too, if possible)

I guess obfs4 is subject to a similar block.

I don’t know how the bridge distribution system works exactly with that, but you wouldn’t have to shut it down if there either would be something built-in the Tor Browser for bypassing this kind of block, or if the users were aware of the tools that can help.

Well, I’d try running a standalone Snowflake.