Anti-censorship issueshttps://gitlab.torproject.org/groups/tpo/anti-censorship/-/issues2024-01-24T02:15:41Zhttps://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.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40290standalone snowflake README still says go 1.15+ needed2023-10-20T15:25:32ZRoger Dingledinestandalone snowflake README still says go 1.15+ neededThe proxy/README.md file still says you need Go 1.15+, but it appears from e.g. https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/merge_requests/184 like the go version requirement is now 1.21.
So, two t...The proxy/README.md file still says you need Go 1.15+, but it appears from e.g. https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/merge_requests/184 like the go version requirement is now 1.21.
So, two things:
* We should update the README to reflect current requirements
and
* We should figure out what we want to tell people on Debian, who can no longer build snowflake, if they don't want to engage in installing and maintaining the whole toolchain manually. Do they stick with v2.6.1? Do they turn off their snowflake? Something even smarter? ...and then write that in the README too.https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/176run some experiments with CAPTCHAs2023-12-18T18:28:37Zmeskiomeskio@torproject.orgrun some experiments with CAPTCHAsAs we are planning to phase out CAPTCHAs (#173), can we run some experiments and see if they can be still effective?
We could either use the existing moat CAPTCHA API as we have some months until clients stop using it, or we could do it...As we are planning to phase out CAPTCHAs (#173), can we run some experiments and see if they can be still effective?
We could either use the existing moat CAPTCHA API as we have some months until clients stop using it, or we could do it in the HTTPS distributor as soon as we have migrated it to rdsys (#2).
There was a thread in the mailing list some years ago about this:
https://lists.torproject.org/pipermail/tor-dev/2021-July/014604.html
We should explore the space and see what better options for CAPTCHAs exist now a days.meskiomeskio@torproject.orgmeskiomeskio@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/175moat should use mime application/json2023-10-04T15:03:40Zmeskiomeskio@torproject.orgmoat should use mime application/jsonmeskiomeskio@torproject.orgmeskiomeskio@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/174Send authentication cookie to onbasca2023-10-05T16:33:55Zmeskiomeskio@torproject.orgSend authentication cookie to onbascaLet's add a header with an authentication cookie.Let's add a header with an authentication cookie.meskiomeskio@torproject.orgmeskiomeskio@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/docker-snowflake-proxy/-/issues/13Upload the container to our registry2024-03-03T14:07:46Zmicahmicah@torproject.orgUpload the container to our registryRight now, the only place you can pull the built container is from dockerhub. Now that Tor's gitlab has the container registry enabled, we should be building and pushing the container to our registry and consider that the main place we a...Right now, the only place you can pull the built container is from dockerhub. Now that Tor's gitlab has the container registry enabled, we should be building and pushing the container to our registry and consider that the main place we ask people to pull from.
This can be integrated into the CI relatively easily, and I've got some example for that, if it would be helpful!meskiomeskio@torproject.orgmeskiomeskio@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/conjure/-/issues/37Dependency Dashboard2023-09-18T14:14:03ZRenovate BotDependency DashboardThis issue lists Renovate updates and detected dependencies. Read the [Dependency Dashboard](https://docs.renovatebot.com/key-concepts/dashboard/) docs to learn more.
## Open
These updates have all been created already. Click a checkbo...This issue lists Renovate updates and detected dependencies. Read the [Dependency Dashboard](https://docs.renovatebot.com/key-concepts/dashboard/) docs to learn more.
## Open
These updates have all been created already. Click a checkbox below to force a retry/rebase of any.
- [ ] <!-- rebase-branch=renovate/gitlab.torproject.org-tpo-anti-censorship-pluggable-transports-snowflake-v2-2.x -->[Update module gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/v2 to v2.6.1](!18)
- [ ] <!-- rebase-branch=renovate/github.com-refraction-networking-gotapdance-1.x -->[Update module github.com/refraction-networking/gotapdance to v1.7.2](!16)
## Ignored or Blocked
These are blocked by an existing closed MR and will not be recreated unless you click a checkbox below.
- [ ] <!-- recreate-branch=renovate/golang-1.x -->[Update golang Docker tag to v1.20](!11)
## Detected dependencies
<details><summary>gitlabci</summary>
<blockquote>
<details><summary>.gitlab-ci.yml</summary>
- `golang 1.18-buster`
- `golang 1.19-buster`
- `golang 1.20-buster`
</details>
</blockquote>
</details>
<details><summary>gomod</summary>
<blockquote>
<details><summary>go.mod</summary>
- `go 1.17`
- `git.torproject.org/pluggable-transports/snowflake.git/v2 v2.5.1`
- `github.com/pires/go-proxyproto v0.7.0`
- `github.com/refraction-networking/gotapdance v1.5.0`
- `gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/goptlib v1.5.0`
- `gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/v2 v2.6.0`
</details>
</blockquote>
</details>https://gitlab.torproject.org/tpo/anti-censorship/lox/-/issues/32Dependency Dashboard2023-09-18T14:12:44ZRenovate BotDependency DashboardThis issue lists Renovate updates and detected dependencies. Read the [Dependency Dashboard](https://docs.renovatebot.com/key-concepts/dashboard/) docs to learn more.
## Open
These updates have all been created already. Click a checkbo...This issue lists Renovate updates and detected dependencies. Read the [Dependency Dashboard](https://docs.renovatebot.com/key-concepts/dashboard/) docs to learn more.
## Open
These updates have all been created already. Click a checkbox below to force a retry/rebase of any.
- [ ] <!-- rebase-branch=renovate/chrono-0.x -->[Update Rust crate chrono to 0.4.31](!54)
## Ignored or Blocked
These are blocked by an existing closed MR and will not be recreated unless you click a checkbox below.
- [ ] <!-- recreate-branch=renovate/aes-gcm-0.x -->[Update Rust crate aes-gcm to 0.10](!35)
- [ ] <!-- recreate-branch=renovate/rand-0.x -->[Update Rust crate rand to 0.8](!38)
- [ ] <!-- recreate-branch=renovate/sha2-0.x -->[Update Rust crate sha2 to 0.10](!40)
- [ ] <!-- recreate-branch=renovate/curve25519-dalek-4.x -->[Update Rust crate curve25519-dalek to v4](!45)
- [ ] <!-- recreate-branch=renovate/ed25519-dalek-2.x -->[Update Rust crate ed25519-dalek to v2](!46)
## Detected dependencies
<details><summary>cargo</summary>
<blockquote>
<details><summary>crates/lox-distributor/Cargo.toml</summary>
- `julianday 1.2.0`
- `base64 0.21.4`
- `hyper 0.14.27`
- `hex_fmt 0.3`
- `futures 0.3.28`
- `time 0.3.28`
- `tokio 1`
- `rand 0.8.5`
- `serde 1.0`
- `serde_with 3.3.0`
- `zkp 0.8.0`
- `clap 4.4.3`
- `serde_json 1.0.107`
- `sled 0.34.7`
- `chrono 0.4.30`
</details>
<details><summary>crates/lox-library/Cargo.toml</summary>
- `curve25519-dalek 3`
- `ed25519-dalek 1`
- `zkp 0.8`
- `bincode 1`
- `chrono 0.4`
- `rand 0.7`
- `serde 1.0.188`
- `serde_with 3.3.0`
- `sha2 0.9`
- `statistical 1.0.0`
- `lazy_static 1`
- `hex_fmt 0.3`
- `aes-gcm 0.8`
- `base64 0.21`
- `time 0.3.28`
- `subtle 2.5`
- `thiserror 1.0.48`
</details>
<details><summary>crates/lox-utils/Cargo.toml</summary>
- `serde 1`
- `serde_json 1.0.107`
- `serde_with 3.3.0`
</details>
<details><summary>crates/lox-wasm/Cargo.toml</summary>
- `julianday 1.2.0`
- `lazy_static 1.4.0`
- `wasm-bindgen 0.2`
- `time 0.3.28`
- `serde_json 1.0.107`
- `console_error_panic_hook 0.1.7`
- `js-sys 0.3.64`
- `rand 0.7`
- `zkp 0.8.0`
- `chrono 0.4.30`
</details>
<details><summary>crates/rdsys-backend-api/Cargo.toml</summary>
- `serde_json 1`
- `futures-util 0.3`
- `serde 1`
- `bytes 1`
- `hex 0.4.3`
- `crc64 2.0.0`
- `sha1 0.10.5`
- `tokio 1`
- `reqwest 0.11`
- `tokio-stream 0.1.14`
- `futures 0.3.28`
- `tokio-util 0.7.8`
- `chrono 0.4.30`
</details>
</blockquote>
</details>
<details><summary>gitlabci</summary>
<blockquote>
<details><summary>.gitlab-ci.yml</summary>
</details>
</blockquote>
</details>