Anti-censorship issueshttps://gitlab.torproject.org/groups/tpo/anti-censorship/-/issues2023-11-01T10:30:11Zhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake-webext/-/issues/86snowflake on local network2023-11-01T10:30:11Zcypherpunkssnowflake on local networkI don't know much about network so please help me on that.
I am running a web server on iOS, and I tried to put iframe embedding on my web server's html page.
It's only on the local network, which means I can access the webpage through...I don't know much about network so please help me on that.
I am running a web server on iOS, and I tried to put iframe embedding on my web server's html page.
It's only on the local network, which means I can access the webpage through same Wi-Fi, will the snowflake effective on that case?
and I find snowflake is very slow, may I ask how many deployed server can bring the snowflake to the speed of regular website browsing, I hope I can help with that.
Thanks!https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40302Proxy hourly stats did not actually happen during that hour2023-10-30T16:44:18ZRoger DingledineProxy hourly stats did not actually happen during that hourMy snowflake proxy today said in its logs:
```
2023/10/27 09:53:58 In the last 1h0m0s, there were 53 connections. Traffic Relayed ↓ 999064 KB, ↑ 167798 KB.
2023/10/27 10:53:58 In the last 1h0m0s, there were 67 connections. Traffic Relaye...My snowflake proxy today said in its logs:
```
2023/10/27 09:53:58 In the last 1h0m0s, there were 53 connections. Traffic Relayed ↓ 999064 KB, ↑ 167798 KB.
2023/10/27 10:53:58 In the last 1h0m0s, there were 67 connections. Traffic Relayed ↓ 561833 KB, ↑ 97282 KB.
2023/10/27 11:53:58 In the last 1h0m0s, there were 63 connections. Traffic Relayed ↓ 124717270 KB, ↑ 6237157 KB.
2023/10/27 12:53:58 In the last 1h0m0s, there were 48 connections. Traffic Relayed ↓ 745608 KB, ↑ 97699 KB.
```
That "125 gigabytes" entry translates to... almost 35 megabytes per second of traffic, on average during the hour? Probably by only a few or even one user? This did not happen during that hour.
Looking at proxy/lib/pt_event_logger.go:
```
case event.EventOnProxyConnectionOver:
e := e.(event.EventOnProxyConnectionOver)
p.inboundSum += e.InboundTraffic
p.outboundSum += e.OutboundTraffic
p.connectionCount += 1
```
I.e. what is happening here is that the stats for the entire connection are counted during the hour that it closed.
See the forum for somebody else reporting this same issue (forum post noticed courtesy MarkC on irc): https://forum.torproject.org/t/impossible-metric-for-snowflake-proxy/9941/1
We should either (a) make the hourly "In the last 1h0m0s," be accurate, in the sense that they actually tell me what happened in the last 1h0m0s, or (b) change the log message so it's clearer it is telling me how many connections finished during that hour along with total transfer on those recently-closed connections.
I'd prefer solution 'a', since it is what I thought I was getting out of these log entries, and I was using it to e.g. try to judge what timezones my snowflake is popular.https://gitlab.torproject.org/tpo/anti-censorship/lox/-/issues/34New Firefox CSP blocks WebAssembly.instantiate()2024-01-26T16:57:55ZCecylia BocovichNew Firefox CSP blocks WebAssembly.instantiate()After rebasing the lox client integration with Tor Browser (https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/116), I got a new error when trying to run the lox client code from the Preferences menu:
```
eval() and eval-lik...After rebasing the lox client integration with Tor Browser (https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/116), I got a new error when trying to run the lox client code from the Preferences menu:
```
eval() and eval-like uses are not allowed in the Parent Process or in System Contexts (Blocked usage in “chrome://browser/content/torpreferences/lox/lox_wasm.js”)
`WebAssembly.instantiateStreaming` failed because your server does not serve wasm with `application/wasm` MIME type. Falling back to `WebAssembly.instantiate` which is slower. Original error:
CompileError: call to WebAssembly.instantiateStreaming() blocked by CSP
load chrome://browser/content/torpreferences/lox/lox_wasm.js:154
init chrome://browser/content/torpreferences/lox/lox_wasm.js:312
eval() and eval-like uses are not allowed in the Parent Process or in System Contexts (Blocked usage in “chrome://browser/content/torpreferences/lox/lox_wasm.js”)
Could not request a lox open invitation CompileError: call to WebAssembly.instantiate() blocked by CSP
load chrome://browser/content/torpreferences/lox/lox_wasm.js:167
requestOpenInvite chrome://browser/content/torpreferences/lox/lox.js:36
```
The current branch I'm working on: https://gitlab.torproject.org/cohosh/tor-browser/-/commits/lox-115.4.0esr-13.5-1Cecylia BocovichCecylia Bocovichhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40301Non-fronted connections to the broker no longer work since 9fdfb3d1b53e911342...2023-10-30T16:27:44ZCecylia BocovichNon-fronted connections to the broker no longer work since 9fdfb3d1b53e9113422a7a2816b2a9af4450b4acThe changes in !182 caused a regression for client configurations that only provide a `url=` option and not a `front=` option. The check at https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/blob/4fa43a889...The changes in !182 caused a regression for client configurations that only provide a `url=` option and not a `front=` option. The check at https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/blob/4fa43a88927e42fb2e3864f706d3e3c72fd0dca3/client/lib/rendezvous_http.go#L49 is never false, causing a connection to a blank URL to happen if no front is provided:
```
2023/10/26 14:46:44 Negotiating via HTTP rendezvous...
2023/10/26 14:46:44 Target URL: snowflake-broker.torproject.net
2023/10/26 14:46:44 Front URL:
2023/10/26 14:46:44 WebRTC: closing DataChannel
2023/10/26 14:46:44 WebRTC: closing PeerConnection
2023/10/26 14:46:44 WebRTC: Closing
2023/10/26 14:46:44 WebRTC: dial tcp :443: connect: connection refused Retrying...
```Cecylia BocovichCecylia Bocovichhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/webtunnel/-/issues/28WebTunnel does not connect2023-10-24T16:35:16ZdinosmWebTunnel does not connectI cannot connect to Tor via WebTunnel. I am using Tor Alpha. My connection log is below.
```
2023-10-24 09:50:15.658 [NOTICE] DisableNetwork is set. Tor will not make or accept non-control network connections. Shutting down all existing...I cannot connect to Tor via WebTunnel. I am using Tor Alpha. My connection log is below.
```
2023-10-24 09:50:15.658 [NOTICE] DisableNetwork is set. Tor will not make or accept non-control network connections. Shutting down all existing connections.
2023-10-24 09:50:22.472 [NOTICE] Renaming old configuration file to "D:\Utils\Tor Browser\Alpha\Tor Browser\Browser\TorBrowser\Data\Tor\torrc.orig.1"
2023-10-24 09:50:36.887 [NOTICE] DisableNetwork is set. Tor will not make or accept non-control network connections. Shutting down all existing connections.
2023-10-24 09:50:36.887 [NOTICE] Switching to guard context "bridges" (was using "default")
2023-10-24 09:50:37.181 [NOTICE] Opening Socks listener on 127.0.0.1:9150
2023-10-24 09:50:37.181 [NOTICE] Opened Socks listener connection (ready) on 127.0.0.1:9150
2023-10-24 09:50:37.599 [NOTICE] Bootstrapped 1% (conn_pt): Connecting to pluggable transport
2023-10-24 09:50:37.611 [NOTICE] Bootstrapped 2% (conn_done_pt): Connected to pluggable transport
2023-10-24 09:50:38.348 [NOTICE] Bootstrapped 10% (conn_done): Connected to a relay
2023-10-24 09:50:38.466 [NOTICE] Bootstrapped 14% (handshake): Handshaking with a relay
2023-10-24 09:50:38.591 [WARN] Tried connecting to router at [2001:db8:c84d:9331:7c61:633b:6bdb:b352]:443 ID=<none> RSA_ID=945C8C659224ADD3C8AB99BDA5CB6178B6F55AFE, but RSA + ed25519 identity keys were not as expected: wanted 945C8C659224ADD3C8AB99BDA5CB6178B6F55AFE + no ed25519 key but got 719C8B27643CD9283DE52C45112EA61CD45B0D80 + wllgI7D+012eycMYn2wWtIbg+oKDwJgiN5YWjjL5X6o.
2023-10-24 09:50:38.591 [WARN] Problem bootstrapping. Stuck at 14% (handshake): Handshaking with a relay. (Unexpected identity in router certificate; IDENTITY; count 1; recommendation warn; host 945C8C659224ADD3C8AB99BDA5CB6178B6F55AFE at 2001:db8:c84d:9331:7c61:633b:6bdb:b352:443)
2023-10-24 09:50:38.599 [NOTICE] Closing no-longer-configured Socks listener on 127.0.0.1:9150
2023-10-24 09:50:38.599 [NOTICE] DisableNetwork is set. Tor will not make or accept non-control network connections. Shutting down all existing connections.
2023-10-24 09:50:38.968 [WARN] Managed proxy "N/A" process terminated with status code 0
```https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/webtunnel/-/issues/27IPv6 only on bridges web site2023-11-02T11:44:51ZJacobo NájeraIPv6 only on bridges web siteOn the site of the bridge, they only appear with IPv6 even when the bridges are only configured for IPv4
https://bridges.torproject.org/bridges/?transport=webtunnel
Thanks, JacoboOn the site of the bridge, they only appear with IPv6 even when the bridges are only configured for IPv4
https://bridges.torproject.org/bridges/?transport=webtunnel
Thanks, Jacobohttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/webtunnel/-/issues/26WebTunnel Bridge documentation2024-01-08T06:22:39ZJacobo NájeraWebTunnel Bridge documentationHi,
I think the documentation needs to mention the nginx.conf configuration about HTTP upgrade connection (https://community.torproject.org/relay/setup/webtunnel/):
```
#WebSocket Support
map $http_upgrade $connection_up...Hi,
I think the documentation needs to mention the nginx.conf configuration about HTTP upgrade connection (https://community.torproject.org/relay/setup/webtunnel/):
```
#WebSocket Support
map $http_upgrade $connection_upgrade {
default upgrade;
'' close;
}
```
Thanks, Jacobohttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40299snowflake-01: Change upper value for local port range2024-01-24T02:15:41ZLinus Nordberglinus@torproject.orgsnowflake-01: Change upper value for local port rangeWe have increased the range of local TCP and UDP ports to span from 15000 and 64000 inclusive.
The kernel has opinions and prints the following at boot:
> kernel: ip_local_port_range: prefer different parity for start/end values.
https...We have increased the range of local TCP and UDP ports to span from 15000 and 64000 inclusive.
The kernel has opinions and prints the following at boot:
> kernel: ip_local_port_range: prefer different parity for start/end values.
https://docs.kernel.org/5.10/networking/ip-sysctl.html explains that
> If possible, it is better these numbers have different parity (one even and one odd value).
I suggest we change the upper value to 63999 for upcoming boots by editing /etc/sysctl.d/ip_local_port_range.conf.
/cc @dcfLinus Nordberglinus@torproject.orgLinus Nordberglinus@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40298snowflake-01: Upgrade Debian 11 -> 122024-02-17T22:21:09ZLinus Nordberglinus@torproject.orgsnowflake-01: Upgrade Debian 11 -> 12I'd like to upgrade snowflake-01 to bookworm (12).
Which packages are crucial to have tested before, and have they been tested elsewhere?\
Is snowflake-02 running Debian?
/cc @dcfI'd like to upgrade snowflake-01 to bookworm (12).
Which packages are crucial to have tested before, and have they been tested elsewhere?\
Is snowflake-02 running Debian?
/cc @dcfLinus Nordberglinus@torproject.orgLinus Nordberglinus@torproject.org2024-02-18https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40297snowflake-01: Upgrade to Debian 11.82023-10-20T18:53:37ZLinus Nordberglinus@torproject.orgsnowflake-01: Upgrade to Debian 11.8I'd like to upgrade snowflake-01 from Debian 11.7 to 11.8.
This will bring, among other things, a new kernel, new grub and tor (`0.4.8.6-1~d11.bullseye+1` to `0.4.8.7-1~d11.bullseye+1`).
Is this something that needs coordination or ca...I'd like to upgrade snowflake-01 from Debian 11.7 to 11.8.
This will bring, among other things, a new kernel, new grub and tor (`0.4.8.6-1~d11.bullseye+1` to `0.4.8.7-1~d11.bullseye+1`).
Is this something that needs coordination or can I do it any time?Linus Nordberglinus@torproject.orgLinus Nordberglinus@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/lox/-/issues/33Implement reasonable handling for bridge blocking2023-11-29T16:30:32ZonyinyangImplement reasonable handling for bridge blockingCurrently the Lox distributor does not handle blocked bridges at all. This is due to two main issues. The first is that we do not yet have a well-established method for determining that a bridge is indeed blocked. The second is that when...Currently the Lox distributor does not handle blocked bridges at all. This is due to two main issues. The first is that we do not yet have a well-established method for determining that a bridge is indeed blocked. The second is that when bridges are blocked, they are blocked in some locations and not others and we have not yet come to consensus on how this should be handled by Lox.
For our alpha deployment however, we should have some kind of alpha solution.
For now, we will assume some `target` country and search for whether or not that country appears in the `blocked_in` list that Lox will receive for each resource from rdsys. If the `target` country is in the list, the bridge will be marked as blocked.onyinyangonyinyanghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40296Snowflake Broker Deployment 23-10-162023-10-19T17:12:53ZshelikhooSnowflake Broker Deployment 23-10-16This deployment is needed to end ip churn collection(https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40280).
Code to be deployed: v2.7.0
## Deployment Script
```
sv stop snowflake-broker
cp /et...This deployment is needed to end ip churn collection(https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40280).
Code to be deployed: v2.7.0
## Deployment Script
```
sv stop snowflake-broker
cp /etc/service/snowflake-broker/run ./snowflake-broker-run-23-10-16-backup-$(date +%N)
cp /usr/local/bin/broker ./snowflake-broker-23-10-16-backup-$(date +%N)
install --owner root ./snowflake-broker-run-23-10-16-candidcate /etc/service/snowflake-broker/run
install --owner root ./snowflake-broker-23-10-16-candidcate /usr/local/bin/broker
sv start snowflake-broker
```
## New Run File
```
#!/bin/sh -e
setcap 'cap_net_bind_service=+ep' /usr/local/bin/broker
exec chpst -u snowflake-broker -o 32768 /usr/local/bin/broker --metrics-log /home/snowflake-broker/metrics.log --acme-hostnames snowflake-broker.bamsoftware.com,snowflake-broker.freehaven.net,snowflake-broker.torproject.net --acme-email dcf@torproject.org --acme-cert-cache /home/snowflake-broker/acme-cert-cache --bridge-list-path /home/snowflake-broker/bridge_lists.json --default-relay-pattern ^snowflake.torproject.net$ --allowed-relay-pattern snowflake.torproject.net$ 2>&1
```
### Binary To Be Deployed
```
1be8764d1a9328bd0f36706fbc040557da102134c78463d0d5470d97cac90903 broker
```shelikhooshelikhoohttps://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/177export bridge ratio and acceptance in the collector metrics2024-03-19T08:48:07Zmeskiomeskio@torproject.orgexport bridge ratio and acceptance in the collector metricsLet's add a field with the bridge ratio status into the collector metrics.Let's add a field with the bridge ratio status into the collector metrics.meskiomeskio@torproject.orgmeskiomeskio@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/bridgestrap/-/issues/39test bridges every hour2024-03-19T13:14:07Zmeskiomeskio@torproject.orgtest bridges every hourWe want to use bridgestrap results to know if a bridge is running, instead of using the 'Running' flag (https://gitlab.torproject.org/tpo/network-health/team/-/issues/318). For that bridgstrap will need to update it's collector file ever...We want to use bridgestrap results to know if a bridge is running, instead of using the 'Running' flag (https://gitlab.torproject.org/tpo/network-health/team/-/issues/318). For that bridgstrap will need to update it's collector file every hour, currently bridgestrap tests bridges every 18h and publishes the collector file every day.
Is bridgestrap able to test all bridges every hour? Or do we need to consider other options (https://gitlab.torproject.org/tpo/core/arti/-/issues/717)?meskiomeskio@torproject.orgmeskiomeskio@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40295Restart broker without proxy churn measurements2023-11-02T16:43:25ZDavid Fifielddcf@torproject.orgRestart broker without proxy churn measurementsNow that the proxy churn code has been removed (#40280),
we need to restart the broker with the new code.
Then we can can call the current log file complete and ready it for publication.
The file /etc/runit/snowflake-broker/run needs to...Now that the proxy churn code has been removed (#40280),
we need to restart the broker with the new code.
Then we can can call the current log file complete and ready it for publication.
The file /etc/runit/snowflake-broker/run needs to be edited to remove `-ip-count-*` options.
The key in `-ip-count-mask` needs to be destroyed.
One difficulty here is that the /etc directory on the broker
is version-controlled using [etckeeper](https://etckeeper.branchable.com/) (Git).
It is necessary to remove the key not only from the file /etc/runit/snowflake-broker/run
but also from the version history.
That may require rewriting history with `git rebase -i`,
followed by `git gc`.shelikhooshelikhoohttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40294Client README recommends command-line options rather than bridge line arguments2024-01-05T22:28:35ZDavid Fifielddcf@torproject.orgClient README recommends command-line options rather than bridge line argumentssnowflake-client, for backward compatibility reasons,
accepts some configuration options as command line options (e.g. `-front`, `-ice`)
as an alternative to the (preferred) format of setting those options
in a bridge line (e.g. `front=`...snowflake-client, for backward compatibility reasons,
accepts some configuration options as command line options (e.g. `-front`, `-ice`)
as an alternative to the (preferred) format of setting those options
in a bridge line (e.g. `front=`, `ice=`).
The command-line versions are needed only for very very old versions of tor.
The bridge line args are preferred because the scope of command-line options is global,
while bridge line args are specific to a single tor SOCKS connection
(so you can have multiple bridge lines with different options).
The client README still documents and recommends the old command-line options:
https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/blob/d434549df88292ff6e61830dc06a49b0ac1b21c6/client/README.md#running-the-snowflake-client-with-tor
> The Snowflake client can be configured with either command line options or SOCKS options. We have a few example `torrc` files in this directory. We recommend the following `torrc` options by default:
>
> ```
> UseBridges 1
>
> ClientTransportPlugin snowflake exec ./client \
> -url https://snowflake-broker.torproject.net.global.prod.fastly.net/ \
> -front cdn.sstatic.net \
> -ice stun:stun.voip.blackberry.com:3478,stun:stun.antisip.com:3478,stun:stun.bluesip.net:3478,stun:stun.dus.net:3478,stun:stun.epygi.com:3478,stun:stun.sonetel.com:3478,stun:stun.sonetel.net:3478,stun:stun.uls.co.za:3478,stun:stun.voipgate.com:3478,stun:stun.voys.nl:3478
>
> Bridge snowflake 192.0.2.3:1
> ```
We should update these to recommend bridge line args instead,
as is already the case [in torrc](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/blob/d434549df88292ff6e61830dc06a49b0ac1b21c6/client/torrc).
The command-line options don't even need to be documented IMO.
Here's a case of a user on NTC being confused by the README:
https://ntc.party/t/in-case-snowflake-rendezvous-gets-blocked/1857/28.shelikhooshelikhoohttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40293snowflake-01: OOB unreachable2023-10-04T08:10:19ZLinus Nordberglinus@torproject.orgsnowflake-01: OOB unreachableThe OOB system for snowflake-01 was unreachable yesterday when we wanted to reboot in #40292.The OOB system for snowflake-01 was unreachable yesterday when we wanted to reboot in #40292.Linus Nordberglinus@torproject.orgLinus Nordberglinus@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40292snowflake-01: Reboot needed2023-10-12T16:25:26ZLinus Nordberglinus@torproject.orgsnowflake-01: Reboot neededI'd like to reboot snowflake-01 in order to restart every every thing.
I'm going to coordinate this with the data center people since our OOB system is sad.
LMK if there's a better or worse time for a reboot.
/cc @dcfI'd like to reboot snowflake-01 in order to restart every every thing.
I'm going to coordinate this with the data center people since our OOB system is sad.
LMK if there's a better or worse time for a reboot.
/cc @dcfLinus Nordberglinus@torproject.orgLinus Nordberglinus@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40291container image on Docker Hub behind current release2024-02-14T16:39:15ZHarmonics6527container image on Docker Hub behind current release"latest"-Tag on Docker hub (https://hub.docker.com/r/thetorproject/snowflake-proxy/tags) is at 2.6.0
Current release here is 2.6.1 - is some kind of automation broken?"latest"-Tag on Docker hub (https://hub.docker.com/r/thetorproject/snowflake-proxy/tags) is at 2.6.0
Current release here is 2.6.1 - is some kind of automation broken?https://gitlab.torproject.org/tpo/anti-censorship/bridgestrap/-/issues/38bridgestrap stats on CollectTor do not include the latest tests2024-03-19T12:34:48ZGeorg Koppenbridgestrap stats on CollectTor do not include the latest testsI was just checking the status of the `GeorgetownPontem` bridge with https://bridges.torproject.org/status?id=7C95AED7256E1D10D134942532CC72AD73AC1BD8 and got
```
Bridge 7C95AED7256E1D10D134942532CC72AD73AC1BD8 advertises:
* obfs4: func...I was just checking the status of the `GeorgetownPontem` bridge with https://bridges.torproject.org/status?id=7C95AED7256E1D10D134942532CC72AD73AC1BD8 and got
```
Bridge 7C95AED7256E1D10D134942532CC72AD73AC1BD8 advertises:
* obfs4: functional
Bandwidth Ratio: 1.480317
Blocked in: ru
Last tested: 2023-09-27 18:01:01.876057752 +0000 UTC (17h4m26.972642756s ago)
```
However, to my surprise checking the `bridgestrap` stats file from CollecTor (2023-09-28-03-27-04-bridgestrap-stats) it only has one entry for that bridge:
```
bridgestrap-test false 7C95AED7256E1D10D134942532CC72AD73AC1BD8
```
That stats file should have picked up the positive test it seems to me, though, given
```
bridgestrap-stats-end 2023-09-28 03:27:04 (86400 s)
```meskiomeskio@torproject.orgmeskiomeskio@torproject.org