Anti-censorship issueshttps://gitlab.torproject.org/groups/tpo/anti-censorship/-/issues2022-11-04T16:56:29Zhttps://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/133deal with email loops in gettor2022-11-04T16:56:29Zmeskiomeskio@torproject.orgdeal with email loops in gettorWe are sending tens of thousands of emails to a single email address, it looks like we have a loop.We are sending tens of thousands of emails to a single email address, it looks like we have a loop.Sponsor 96: Rapid Expansion of Access to the Uncensored Internet through Tor in China, Hong Kong, & Tibetmeskiomeskio@torproject.orgmeskiomeskio@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/gettor-project/OnionSproutsBot/-/issues/45Telegram gettor distributor is not working after Tor Browser update2022-12-02T17:04:47Zchampionquizzerchampionquizzer@torproject.orgTelegram gettor distributor is not working after Tor Browser updateIt is trying to query https://dist.torproject.org/torbrowser/11.5.4 and that folder doesn't exist anymore since the [latest update](https://blog.torproject.org/new-release-tor-browser-1155/) to 11.5.5.
Complete error message when I try ...It is trying to query https://dist.torproject.org/torbrowser/11.5.4 and that folder doesn't exist anymore since the [latest update](https://blog.torproject.org/new-release-tor-browser-1155/) to 11.5.5.
Complete error message when I try with for example, Linux 64-bit ar
```
GetTor:
The version you have requested (linux64, ar) hasn't been uploaded to Telegram's servers yet. Please wait...
We are uploading the signature file first...
Upload failed! Please try again later. Reason: 404, message='Not Found', url=URL('https://dist.torproject.org/torbrowser/11.5.4/tor-browser-linux64-11.5.4_ar.tar.xz.asc')
We are now uploading the program...
Upload failed! Please try again later. Reason: 404, message='Not Found', url=URL('https://dist.torproject.org/torbrowser/11.5.4/tor-browser-linux64-11.5.4_ar.tar.xz')
Failure!
Something went wrong during the upload! Please try again.
```https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/132Telegram gettor distributor is not working after Tor Browser update2022-10-26T08:37:55Zchampionquizzerchampionquizzer@torproject.orgTelegram gettor distributor is not working after Tor Browser updateIt is trying to query https://dist.torproject.org/torbrowser/11.5.4 and that folder doesn't exist anymore since the [latest update](https://blog.torproject.org/new-release-tor-browser-1155/) to 11.5.5.
Complete error message when I try ...It is trying to query https://dist.torproject.org/torbrowser/11.5.4 and that folder doesn't exist anymore since the [latest update](https://blog.torproject.org/new-release-tor-browser-1155/) to 11.5.5.
Complete error message when I try with for example, Linux 64-bit ar
```
GetTor:
The version you have requested (linux64, ar) hasn't been uploaded to Telegram's servers yet. Please wait...
We are uploading the signature file first...
Upload failed! Please try again later. Reason: 404, message='Not Found', url=URL('https://dist.torproject.org/torbrowser/11.5.4/tor-browser-linux64-11.5.4_ar.tar.xz.asc')
We are now uploading the program...
Upload failed! Please try again later. Reason: 404, message='Not Found', url=URL('https://dist.torproject.org/torbrowser/11.5.4/tor-browser-linux64-11.5.4_ar.tar.xz')
Failure!
Something went wrong during the upload! Please try again.
```meskiomeskio@torproject.orgmeskiomeskio@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/connectivity-measurement/logcollector-admin/-/issues/7Keep irl's dynamic bridges around for a few days after rotation2023-03-19T12:46:16ZRoger DingledineKeep irl's dynamic bridges around for a few days after rotationRight now as I understand it, the moment we get a "blocked!" result out of bridgestatus in any country, we tell irl's dynamic bridge farm that it's time to rotate that bridge.
This is good from an overall reachability perspective, becau...Right now as I understand it, the moment we get a "blocked!" result out of bridgestatus in any country, we tell irl's dynamic bridge farm that it's time to rotate that bridge.
This is good from an overall reachability perspective, because any waiting, if we're right and the bridge got blocked, is bad for users.
But also, by spinning the old bridge down right then, we lose out on a lot of potential understanding:
* How often are these 'blocked' events false positives? That is, how often do we rotate away from a bridge when actually it was just a brief connectivity issue or a slow bootstrap? These are cases that we are labeling "blocked" in our data yet we don't know how much we're overcounting the blocked cases.
* By rotating the bridge immediately, we make it hard to figure out what happened in other countries. We have what look like a bunch of false positives in Turkey and Russia in the https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/92 analysis, where we get one connection failure from Turkey but it works from other countries, and then the next day the bridge is down, because we intentionally took it down after that first 'blocked' case.
This approach of taking the bridge down after the first failure prevents us from using a more nuanced definition of blocked such as "down three days in a row in this country while still reachable from some other countries during that time".
So my proposed fix is to change irl's dynamic bridge framework to schedule a spin-down of the old bridge for N (e.g. N=3) days in the future. We can still spin up the new one right then, pass the bridge lines back, etc just as we do now.
This way we get a view into the future -- of how that bridge works from each of our countries after the initial potential blocking event.
One downside is that irl might be running more total VM's than he originally expected, for the overlap period. This one seems solvable though.Sponsor 96: Rapid Expansion of Access to the Uncensored Internet through Tor in China, Hong Kong, & Tibetirlirlhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40225Snowflake Broker Deployment 22-10-252022-11-08T18:21:09ZshelikhooSnowflake Broker Deployment 22-10-25We are going to deploy a new version of snowflake broker configuration to snowflake broker.
The broker binary isn't updated, and remain [v2.3.1](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/tags/v2.3...We are going to deploy a new version of snowflake broker configuration to snowflake broker.
The broker binary isn't updated, and remain [v2.3.1](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/tags/v2.3.1).
This will rollout the change we did in [Snowflake Broker Deployment 22-10-03](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40193) plus [include](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40212) [secondary bridge](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40122) definition, and [Remove GOMAXPROCS=1](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40205).
## Deployment Script
```
sv stop snowflake-broker
cp /etc/service/snowflake-broker/run ./snowflake-broker-run-22-10-25-backup-$(date +%N)
cp /home/snowflake-broker/bridge_lists.json ./bridge_lists_json-22-10-25-backup-$(date +%N)
install --owner root ./snowflake-broker-run-22-10-25-candidcate /etc/service/snowflake-broker/run
install --owner root ./bridge_lists_json-22-10-25-candidcate /home/snowflake-broker/bridge_lists.json
sv start snowflake-broker
```
## New Run File
(the difference is at --allowed-relay-pattern)
(-ip-count-mask's value is not real value used on the production system)
```
#!/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$ -ip-count-log /home/snowflake-broker/metrics-ip-salted.jsonl -ip-count-interval 1h -ip-count-mask ****** 2>&1
```
## Old Run File
```
#!/bin/sh -e
setcap 'cap_net_bind_service=+ep' /usr/local/bin/broker
export GOMAXPROCS=1
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$ -ip-count-log /home/snowflake-broker/metrics-ip-salted.jsonl -ip-count-interval 1h -ip-count-mask ****** 2>&1
```
## New bridge_lists.json
```
{"displayName":"default", "webSocketAddress":"wss://snowflake.torproject.net/", "fingerprint":"2B280B23E1107BB62ABFC40DDCC8824814F80A72"}
{"displayName":"Bridge02", "webSocketAddress":"wss://02.snowflake.torproject.net/", "fingerprint":"8838024498816A039FCBBAB14E6F40A0843051FA"}
```
## Old bridge_lists.json
```
{"displayName":"default", "webSocketAddress":"wss://snowflake.torproject.net/", "fingerprint":"2B280B23E1107BB62ABFC40DDCC8824814F80A72"}
```
## Side effect to be watched
The network capacity of the snowflake may be decreased(again).Sponsor 96: Rapid Expansion of Access to the Uncensored Internet through Tor in China, Hong Kong, & Tibetshelikhooshelikhoohttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40224utls RoundTripper does not work when it is supposed to use HTTP/12022-12-06T14:17:27ZDavid Fifielddcf@torproject.orgutls RoundTripper does not work when it is supposed to use HTTP/1Try setting `utls=hellorandomizednoalpn` in the bridge line. snowflake-client's rendezvous will fail with:
```
WebRTC: incorrect ALPN negotiated Retrying...
```
Lack of ALPN should cause a fallback to HTTP/1, and the connection should ...Try setting `utls=hellorandomizednoalpn` in the bridge line. snowflake-client's rendezvous will fail with:
```
WebRTC: incorrect ALPN negotiated Retrying...
```
Lack of ALPN should cause a fallback to HTTP/1, and the connection should still work. What's going wrong.
The problem is the internal `connectWithH1` map, which is inconsistently keyed. Entries are written to the map with `host:port` keys. Entries are read from the map using sometimes `host:port` keys, and sometimes `host` keys.
* [`RoundTrip`](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/blob/v2.3.1/common/utls/roundtripper.go#L64) calls gets its domain name from `req.URL.Host`; i.e., it uses a key like `"cdn.sstatic.net"`.
* [`dialOrGetTLSWithExpectedALPN`](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/blob/v2.3.1/common/utls/roundtripper.go#L124) gets its domain name from an `addr` argument to `DialTLS`; i.e., it uses a key like `"cdn.sstatic.net:443"`.
Adding a few debugging logs makes it clear what is going wrong:
```
2022/10/21 23:26:48 Target URL: snowflake-broker.torproject.net.global.prod.fastly.net
2022/10/21 23:26:48 Front URL: cdn.sstatic.net
2022/10/21 23:26:48 getShouldConnectWithH1("cdn.sstatic.net") -> false
2022/10/21 23:26:48 getShouldConnectWithH1("cdn.sstatic.net:443") -> false
2022/10/21 23:26:48 setShouldConnectWithH1("cdn.sstatic.net:443")
2022/10/21 23:26:48 getShouldConnectWithH1("cdn.sstatic.net") -> false
2022/10/21 23:26:48 getShouldConnectWithH1("cdn.sstatic.net:443") -> true
2022/10/21 23:26:48 getShouldConnectWithH1("cdn.sstatic.net") -> false
2022/10/21 23:26:48 getShouldConnectWithH1("cdn.sstatic.net:443") -> true
2022/10/21 23:26:48 getShouldConnectWithH1("cdn.sstatic.net") -> false
2022/10/21 23:26:48 getShouldConnectWithH1("cdn.sstatic.net:443") -> true
2022/10/21 23:26:48 getShouldConnectWithH1("cdn.sstatic.net") -> false
2022/10/21 23:26:48 getShouldConnectWithH1("cdn.sstatic.net:443") -> true
2022/10/21 23:26:48 WebRTC: closing DataChannel
2022/10/21 23:26:48 WebRTC: closing PeerConnection
2022/10/21 23:26:48 WebRTC: Closing
2022/10/21 23:26:48 WebRTC: incorrect ALPN negotiated Retrying...
```shelikhooshelikhoohttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake-webext/-/issues/65No connected user2022-11-08T18:17:40ZcypherpunksNo connected userI am using snowlake web extension for some weeks now and usually it connects to several users every day. But today (since at least 12 hours) not one single user connected to my snowflake, although it is "active". I tried rebooting my lap...I am using snowlake web extension for some weeks now and usually it connects to several users every day. But today (since at least 12 hours) not one single user connected to my snowflake, although it is "active". I tried rebooting my laptop and re-connecting my router but it didn't help.https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40223Spread snowflake-01 bridges' tor traffic over several IP addresses2024-01-22T15:19:37ZRoger DingledineSpread snowflake-01 bridges' tor traffic over several IP addressesWe discussed a few days ago how 12 super active snowflake back-end bridges on one IP address could trigger the "too many connections plus too many circuits from one IP address" anti-ddos defenses at Tor relays.
I asked Linus if we can g...We discussed a few days ago how 12 super active snowflake back-end bridges on one IP address could trigger the "too many connections plus too many circuits from one IP address" anti-ddos defenses at Tor relays.
I asked Linus if we can get a few more IP addresses for snowflake-01, and he thinks it sounds doable.
(They don't even need to be the sort of addresses that can receive incoming connections. So they could in theory be outbound natted or something. If that's easier -- I suspect it does not make it easier. :)
So step one is that @Linus gets those addresses and adds them to the computer and says here what they are. I think 3 or 4 or 6 total addresses would be good, but even 2 would be a lot more than 1.
And then step two is that @dcf or somebody goes in to the torrc's of the bridges and configures each of them to use the right outbound IP address. This is done by setting the "outboundbindaddress" line in their torrc.
(And I guess step zero, which can happen at any point, is that somebody notices this is a poor idea and jumps in to explain why.)https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/102future of builtin bridges2024-02-27T18:46:44Zmeskiomeskio@torproject.orgfuture of builtin bridgesWe've being removing obfs4 builtin bridges (#44 #98) without replacing them. Talking with others about it we started questioning the value of builtin bridges and if it makes sense to keep them around and find more bridge operators for th...We've being removing obfs4 builtin bridges (#44 #98) without replacing them. Talking with others about it we started questioning the value of builtin bridges and if it makes sense to keep them around and find more bridge operators for them.
I guess they were created because getting bridges (before moat) was hard and in many cases builtin bridges are enough to overcome restricted networks (like corporate firewalls). With connect assist getting bridges is trivial and is easier than configuring builtin bridges.
Another reason to use builtin bridges is that they are operated by trusted members of our community and hopefully are more stable than a random bridge. But we solve that by providing multiple bridges in each request to circumvention settings.
Currently there are two situations in Tor Browser where builtin bridges are used in two cases:
* Circumvention settings API configure builtin bridges when we don't know anything about the country of the IP address. I expect this mostly to be used in corporate firewalls, where builtin bridges work fine, but I hope circumvention settings ones should work as good.
* When users enable them manually. I'm not sure when will this happen. I expect that if circumvention settings is not reachable (our domain front is blocked) builtin bridges will not work.
I don't think we can't stop using builtin bridges from one day to another, as TB is not the only user of them. But if we don't see the need of them we can slowly move into the direction of deprecating them.
What kind of usecases might people have for builtin bridges that I'm missing? Is there any original reason form them that I don't know?meskiomeskio@torproject.orgmeskiomeskio@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40222Inactive connections with 510 second duration2023-06-28T11:15:43ZVortInactive connections with 510 second durationAfter commit 1bc54948 (!108), I started to notice lots of connections in logs with similar duration (510s-512s), which were closed due to inactivity.
I see several possible reasons for such behaviour:
1. All such connections come from ...After commit 1bc54948 (!108), I started to notice lots of connections in logs with similar duration (510s-512s), which were closed due to inactivity.
I see several possible reasons for such behaviour:
1. All such connections come from non-standard clients.
2. Timeout value from !108 is too small.
3. Lots of connections broke because of high rate of UDP losses in my network.
```bash
$ grep -c "over 51[012]" log_crop2.txt && grep -c "Traffic throughput" log_crop2.txt
52
459
```
If connections are closed because of problems with my network (3), then, most likely, nothing should be done from snowflake side.
If this is a sign of attack or other bot activity (1), then it may need further investigation.
And, most importantly, if all of them are legit and my network is good enough for snowflake (2), it means losing >11% of user connections just because of bug, which I think is not acceptable.
```bash
$ grep "over 51[012]" log_crop2.txt | tail -20
2022/10/20 09:20:16 Traffic throughput (up|down): 1 MB|45 KB -- (209 OnMessages, 2641 Sends, over 510 seconds)
2022/10/20 09:49:23 Traffic throughput (up|down): 7 MB|367 KB -- (750 OnMessages, 6452 Sends, over 510 seconds)
2022/10/20 10:18:56 Traffic throughput (up|down): 184 KB|12 KB -- (53 OnMessages, 1236 Sends, over 510 seconds)
2022/10/20 11:05:02 Traffic throughput (up|down): 1 MB|26 KB -- (193 OnMessages, 1156 Sends, over 510 seconds)
2022/10/20 11:11:46 Traffic throughput (up|down): 51 KB|16 KB -- (93 OnMessages, 853 Sends, over 510 seconds)
2022/10/20 11:52:27 Traffic throughput (up|down): 11 MB|180 KB -- (428 OnMessages, 11799 Sends, over 510 seconds)
2022/10/20 12:16:46 Traffic throughput (up|down): 48 KB|13 KB -- (169 OnMessages, 334 Sends, over 510 seconds)
2022/10/20 12:30:28 Traffic throughput (up|down): 3 MB|353 KB -- (1053 OnMessages, 4517 Sends, over 510 seconds)
2022/10/20 12:31:58 Traffic throughput (up|down): 4 MB|47 KB -- (500 OnMessages, 3478 Sends, over 511 seconds)
2022/10/20 12:39:16 Traffic throughput (up|down): 27 KB|28 KB -- (58 OnMessages, 297 Sends, over 510 seconds)
2022/10/20 12:56:22 Traffic throughput (up|down): 1 MB|12 KB -- (72 OnMessages, 1206 Sends, over 510 seconds)
2022/10/20 13:16:58 Traffic throughput (up|down): 29 KB|5 KB -- (28 OnMessages, 224 Sends, over 510 seconds)
2022/10/20 13:29:10 Traffic throughput (up|down): 159 KB|4 KB -- (17 OnMessages, 1997 Sends, over 510 seconds)
2022/10/20 13:30:19 Traffic throughput (up|down): 244 KB|199 KB -- (444 OnMessages, 1257 Sends, over 510 seconds)
2022/10/20 13:52:30 Traffic throughput (up|down): 259 KB|77 KB -- (236 OnMessages, 1230 Sends, over 510 seconds)
2022/10/20 13:58:37 Traffic throughput (up|down): 33 KB|7 KB -- (39 OnMessages, 760 Sends, over 511 seconds)
2022/10/20 14:00:25 Traffic throughput (up|down): 23 KB|15 KB -- (89 OnMessages, 398 Sends, over 510 seconds)
2022/10/20 14:51:09 Traffic throughput (up|down): 102 KB|30 KB -- (344 OnMessages, 538 Sends, over 511 seconds)
2022/10/20 15:06:10 Traffic throughput (up|down): 132 KB|31 KB -- (87 OnMessages, 305 Sends, over 510 seconds)
2022/10/20 15:10:26 Traffic throughput (up|down): 161 KB|111 KB -- (194 OnMessages, 1157 Sends, over 510 seconds)
```https://gitlab.torproject.org/tpo/anti-censorship/censorship-analysis/-/issues/40036Censorship analysis for UDP traffic between Iran and rest of Internet: 2022 Q42023-01-26T19:03:20ZshelikhooCensorship analysis for UDP traffic between Iran and rest of Internet: 2022 Q4This issue documents the analysis of censorship of UDP traffic between an VPS in Iran and rest of Internet conducted in 2022 Q4.
This is an ongoing test, and this issue will be updated as the test continue.
## Initial Anomaly Observed
...This issue documents the analysis of censorship of UDP traffic between an VPS in Iran and rest of Internet conducted in 2022 Q4.
This is an ongoing test, and this issue will be updated as the test continue.
## Initial Anomaly Observed
When trying to set up kcptun tunnel between an VPS in Iran and another VPS in another part of the world, the connection setup was unsuccessful, while short text UDP message can be transmitted.
## Research Mythology
There are 3 tools currently used in this experiment:
#### Packet Generator
Packet Generator generate a sequence of packet content as test vector based on the specification. The specification define the number of packet to be generated and the regular expression of packets to be generated.
#### Packet Sender
Packet Sender read test vector file, and send UDP packets to a specified network address. It can either send all packet from a single source port, or send them from different source port. It will by default wait 10 ms before sending next packet.
#### Packet Receiver
Packet Receiver receives UDP packet, and record the keyed hash of source IP address, source port, and content of the packet.
## Tests conducted
#### Residual block test
Packet specification:
```
10 [a-z]{10}
10 [\0-\255]{256}
10 [a-z]{10}
```
Test Result when sending to the outside host that can receive some UDP packet:
```
wc -l *
20 iran_dynamicport.csv
10 iran_staticport.csv
30 ireland_dynamicport.csv
30 ireland_staticport.csv
```
Conclusion from this test:
1. `[a-z]{10}` don't trigger this block.
2. `[\0-\255]{256}` trigger this block.
3. There is residual block.
[Test Vector](https://gist.githubusercontent.com/xiaokangwang/92b5bc4699573182de340e4c7ef95f18/raw/28fa2abbddc755e2a3a73568fce632ac66322df0/ResidualBlockTestVector.tsv)
The [result](https://gist.githubusercontent.com/xiaokangwang/92b5bc4699573182de340e4c7ef95f18/raw/28fa2abbddc755e2a3a73568fce632ac66322df0/ireland_dynamicport.csv) from packet receiver when sending packet from Ireland with a new source port for every packet.
The [result](https://gist.githubusercontent.com/xiaokangwang/92b5bc4699573182de340e4c7ef95f18/raw/28fa2abbddc755e2a3a73568fce632ac66322df0/ireland_staticport.csv) from packet receiver when sending packet from Ireland with a stable source port for every packet.
The [result](https://gist.githubusercontent.com/xiaokangwang/92b5bc4699573182de340e4c7ef95f18/raw/28fa2abbddc755e2a3a73568fce632ac66322df0/iran_dynamicport.csv) from packet receiver when sending packet from Iran with a new source port for every packet.
The [result](https://gist.githubusercontent.com/xiaokangwang/92b5bc4699573182de340e4c7ef95f18/raw/28fa2abbddc755e2a3a73568fce632ac66322df0/iran_staticport.csv) from packet receiver when sending packet from Iran with a stable source port for every packet.
#### Residual block reset time test
Packet specification:
```
1 [a-z]{10}
1 [\0-\255]{256}
1 [a-z]{10}
```
Test Result when sending packet from Iran to outside network with a different sending interval in ms:
```
wc -l *
1 iran_001000.csv
1 iran_010000.csv
1 iran_060000.csv
1 iran_067500_2.csv
1 iran_067500.csv
1 iran_069375.csv
1 iran_070313_2.csv
1 iran_070313.csv
1 iran_070782.csv
2 iran_070899.csv
2 iran_071016.csv
2 iran_071250.csv
2 iran_075000.csv
2 iran_090000.csv
2 iran_120000.csv
21 total
```
Conclusion from this test:
1. The residual block reset time is between 70.899s to 70.782s.
#### Look like nothing packet censorship test
Test packet generation pattern:
```
10000 ([a-z]){1,1000}
10000 [A-Z]{1,1000}
10000 [0-9]{1,1000}
10000 [a-zA-Z]{1,1000}
10000 [a-z0-9]{1,1000}
10000 [A-Z0-9]{1,1000}
10000 [a-zA-Z0-9]{1,1000}
10000 [\0-\255]{1,1000}
```
Test result for packet received:
Pattern, number of packet sent, number of packet received, probability of receiving the packet.
```
"^([a-z]){1,1000}$",10033,149,0.0149
"^[A-Z]{1,1000}$",10036,133,0.0133
"^[0-9]{1,1000}$",10011,98,0.0098
"^[a-zA-Z]{1,1000}$",30106,399,0.0133
"^[a-z0-9]{1,1000}$",30027,319,0.0106
"^[A-Z0-9]{1,1000}$",30016,301,0.0100
"^[a-zA-Z0-9]{1,1000}$",70002,694,0.0099
"^[\0-\255]{1,1000}$",80000,781,0.0098
"^([a-z]){1,10}$",132,131,0.9924
"^([a-z]){10,20}$",130,11,0.0846
"^([a-z]){10,15}$",65,11,0.1692
"^([a-z]){10,13}$",40,11,0.2750
"^([a-z]){10,10}$",11,11,1.0000
"^([a-z]){11,11}$",5,0,0.0000
"^([a-z]){12,1000}$",9896,18,0.0018
"^[0-9]{1,10}$",99,98,0.9899
"^[0-9]{10,10}$",7,7,1.0000
"^[0-9]{11,11}$",8,0,0.0000
"^[0-9]{12,1000}$",9904,0,0.0000
"^[a-zA-Z]{1,10}$",380,376,0.9895
"^[a-zA-Z]{11,11}$",24,0,0.0000
"^[a-zA-Z]{12,1000}$",29702,23,0.0008
"^[a-z0-9]{1,10}$",298,296,0.9933
"^[a-z0-9]{11,11}$",17,0,0.0000
"^[a-z0-9]{12,100}$",2741,2,0.0007
"^[A-Z0-9]{1,10}$",304,301,0.9901
"^[A-Z0-9]{11,11}$",26,0,0.0000
"^[A-Z0-9]{12,1000}$",29686,0,0.0000
"^[a-zA-Z0-9]{1,10}$",668,663,0.9925
"^[a-zA-Z0-9]{11,11}$",45,0,0.0000
"^[a-zA-Z0-9]{12,1000}$",69289,31,0.0004
"^[\0-\255]{1,10}$",775,749,0.9665
"^[\0-\255]{11,11}$",58,0,0.0000
"^[\0-\255]{12,1000}$",79167,32,0.0004
```
The [result](https://gist.githubusercontent.com/xiaokangwang/92b5bc4699573182de340e4c7ef95f18/raw/3653d73630fd3d609600a1e46ba988f3db5347c7/manypacket3.csv) from packet receiver.
The [packets](https://gist.githubusercontent.com/xiaokangwang/92b5bc4699573182de340e4c7ef95f18/raw/d66534d97a02c0f83bcd2c0bbabd1ffefc4ca95f/random_shuffled.tsv) sent.
Conclusion from the test:
1. In the given test environment, a random packet will more than 10 bytes of content is likely to be dropped. If it is less than 10 bytes, it is very likely to be let through.
2. The block seems to to let through some packets longer than 10 bytes, but more research is necessary.
#### Protocol Specific censorship analysis
Type of protocol tested:
1. DNS
2. STUN
3. DTLS
Conclusion from the test:
1. In the given test environment, Some DNS packets are censored.
2. In the given test environment, STUN packets are not affected by this censorship.
3. In the given test environment, DTLS packets are blocked.shelikhooshelikhoohttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40220Close stale connections in standalone proxy2022-11-29T14:20:34ZCecylia BocovichClose stale connections in standalone proxyWe've received several reports (#40211) of standalone proxies that have long-lived connections with clients but zero bytes transferred. The browser-based snowflake proxies (i.e., the web extension and badge) have a [timeout in place to c...We've received several reports (#40211) of standalone proxies that have long-lived connections with clients but zero bytes transferred. The browser-based snowflake proxies (i.e., the web extension and badge) have a [timeout in place to close stale connections](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake-webext/-/blob/29a4cc6e0970f2e10ed610b8ae8449eafe75472c/proxypair.js#L163) after [30 seconds](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake-webext/-/blob/29a4cc6e0970f2e10ed610b8ae8449eafe75472c/config.js#L38) of inactivity. This aligns with a [client-side timeout](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/blob/ac8562803ab9621d037bd1b3710c59799c7aa6d5/client/lib/snowflake.go#L49) that closes stale connections to proxies after 20s of inactivity.
It's possible that the long-lived connections these standalone proxies are seeing are from clients not using our snowflake client code. Or that the client-side closures are not being received by the proxies. In any case, we should add an inactivity timeout to the standalone proxies to try and clean up these connections and free up resources in a similar way that the browser-based proxies do.https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40218Can we include the pieces IPtProxy needs into the client library?2024-02-01T12:07:48Zmeskiomeskio@torproject.orgCan we include the pieces IPtProxy needs into the client library?IPtProxy does patch snowflake to use it, to avoid rewriting what we already have in the cli client side:
https://github.com/tladesignz/IPtProxy/blob/master/snowflake.patch
Would be nice if we find a way for the client library to acomoda...IPtProxy does patch snowflake to use it, to avoid rewriting what we already have in the cli client side:
https://github.com/tladesignz/IPtProxy/blob/master/snowflake.patch
Would be nice if we find a way for the client library to acomodate IPtPRoxy needs and don't need to patch it.https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/131Make easier to develop rdsys2023-09-20T15:33:37Zmeskiomeskio@torproject.orgMake easier to develop rdsysThings that can be improved
* [ ] generate dummy bridge descriptors (#171)
* [ ] make conf/config.json work out of the box
* [ ] review README instructions to make them easier to followThings that can be improved
* [ ] generate dummy bridge descriptors (#171)
* [ ] make conf/config.json work out of the box
* [ ] review README instructions to make them easier to followmeskiomeskio@torproject.orgmeskiomeskio@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/130Upgrade telebot library to version 32022-11-03T16:39:33Zmeskiomeskio@torproject.orgUpgrade telebot library to version 3We use [telebot](https://github.com/tucnak/telebot) in our [bridges bot](https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/blob/main/doc/telegram.md). But we are using the version 2 of the library, let's update it to version 3.We use [telebot](https://github.com/tucnak/telebot) in our [bridges bot](https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/blob/main/doc/telegram.md). But we are using the version 2 of the library, let's update it to version 3.https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40217Upgrade utls dependency to v1.1.3 or later2023-10-11T05:28:38ZDavid Fifielddcf@torproject.orgUpgrade utls dependency to v1.1.3 or laterOur [current version](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/blob/v2.3.1/go.mod#L15) is [v1.0.0](https://github.com/refraction-networking/utls/releases/tag/v1.0.0) from 2021-11-02. Newer releas...Our [current version](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/blob/v2.3.1/go.mod#L15) is [v1.0.0](https://github.com/refraction-networking/utls/releases/tag/v1.0.0) from 2021-11-02. Newer releases have important enhancements, notably new and corrected fingerprints:
* [Implement certificate compression #95](https://github.com/refraction-networking/utls/pull/95)
* [new ClientHellos and Extensions #116](https://github.com/refraction-networking/utls/pull/116)
* Chrome_87
* Chrome_96
* Chrome_100
* Chrome_102
* Firefox_99
* Firefox_102
* iOS_13
* iOS_14
* Android_11
* ApplicationSettingsExtension
* SignatureAlgorithmsCertExtension
* DelegatedCredentialsExtension
* StatusRequestExtension
* [Add new ClientHellos #122](https://github.com/refraction-networking/utls/pull/122)
* Firefox 105
* Chrome 106
* Edge 106
* Safari 16.0
* 360 Secure Browser 11.0
* QQ Browser 11.1
* [Fix Google Parrots #125](https://github.com/refraction-networking/utls/pull/125)
You may not want to automatically include every possible new supported fingerprint. For example, see [this caveat](https://github.com/refraction-networking/utls/pull/122#issue-1401840671):
> Unfortunately, the specs based on Edge 106 and 360 11.0 seem to incompatible with this library.shelikhooshelikhoohttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40216Need documentation for utls-imitate and utls-nosni2023-03-10T15:28:13ZDavid Fifielddcf@torproject.orgNeed documentation for utls-imitate and utls-nosni!76 added support for uTLS in the client for broker rendezvous, using the SOCKS parameters `utls-imitate` and `utls-nosni`.
But I could not find documentation of these options.
They should be described in [client/README.md](client/README...!76 added support for uTLS in the client for broker rendezvous, using the SOCKS parameters `utls-imitate` and `utls-nosni`.
But I could not find documentation of these options.
They should be described in [client/README.md](client/README.md)
and the example client torrc, at least.
There also needs to be a listing somewhere of what values may be passed to `utls-imitate`.
I found the list of understood values in [common/utls/client_hello_id.go](common/utls/client_hello_id.go).
This list should also appear in client/README.md (manually maintained),
the `-help` output (automatically updated), or both.
This is the code in dnstt-client that lists the known fingerprints in `-help` output:
https://repo.or.cz/dnstt.git/blob/14a29048e4b659cb3113a7af37fbdb3349f13d37:/dnstt-client/main.go#l258
Its output looks like this:
```
Known TLS fingerprints for -utls are:
none Firefox Firefox_55 Firefox_56 Firefox_63 Firefox_65 Chrome
Chrome_58 Chrome_62 Chrome_70 Chrome_72 Chrome_83 iOS iOS_11_1
iOS_12_1
```https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40215Bad range port format2022-10-17T11:55:14ZVortBad range port formatsnowflake proxy built from latest commit (8b1970a3) produces such error after startup:
`Bad range port format: 0xc0001d40b0`
[Spotted](https://forum.torproject.net/t/standalone-proxy-traffic-relayed-almost-zero-with-restricted-nat-ty...snowflake proxy built from latest commit (8b1970a3) produces such error after startup:
`Bad range port format: 0xc0001d40b0`
[Spotted](https://forum.torproject.net/t/standalone-proxy-traffic-relayed-almost-zero-with-restricted-nat-type/5122/17?u=vort) by forum user mjacobs-de.https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/101use full snowflake bridge lines2022-11-04T16:44:06Zmeskiomeskio@torproject.orguse full snowflake bridge linesThe builtin snowflake bridgeline in tor browser is:
```
snowflake 192.0.2.3:80 2B280B23E1107BB62ABFC40DDCC8824814F80A72
```
This line works in Tor Browser as snowflake launched with a [bunch of default parameters](https://gitlab.torproje...The builtin snowflake bridgeline in tor browser is:
```
snowflake 192.0.2.3:80 2B280B23E1107BB62ABFC40DDCC8824814F80A72
```
This line works in Tor Browser as snowflake launched with a [bunch of default parameters](https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/blob/main/projects/browser/Bundle-Data/PTConfigs/linux/torrc-defaults-appendix#L5). But in other clients that don't have the right default parameters this line doesn't work.
Circumvention settings should provide the full bridgeline:
```
snowflake 192.0.2.3:80 2B280B23E1107BB62ABFC40DDCC8824814F80A72 fingerprint=2B280B23E1107BB62ABFC40DDCC8824814F80A72 url=https://snowflake-broker.torproject.net.global.prod.fastly.net/ front=cdn.sstatic.net ice=stun:stun.l.google.com:19302,stun:stun.voip.blackberry.com:3478,stun:stun.altar.com.pl: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.stunprotocol.org:3478,stun:stun.uls.co.za:3478,stun:stun.voipgate.com:3478,stun:stun.voys.nl:3478
```
* [x] Update the [bridge line in TB](https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/blob/main/projects/common/bridges_list.snowflake.txt)
* [ ] Update the circumvention map to include the missing paramsSponsor 96: Rapid Expansion of Access to the Uncensored Internet through Tor in China, Hong Kong, & Tibetmeskiomeskio@torproject.orgmeskiomeskio@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40214standalone proxy: no connections since 2022/10/032022-10-15T14:33:26ZBeckersstandalone proxy: no connections since 2022/10/03I am running snowflake as an standalone proxy. It worked quite well until 2022/10/03 (according to the log file). Since then I get zero connections. Part of my logfile around a daily system restart:
```
2022/10/14 01:07:20 In the last 3...I am running snowflake as an standalone proxy. It worked quite well until 2022/10/03 (according to the log file). Since then I get zero connections. Part of my logfile around a daily system restart:
```
2022/10/14 01:07:20 In the last 30m0s, there were 0 connections. Traffic Relayed ↑ 0 B, ↓ 0 B.
2022/10/14 01:37:20 In the last 30m0s, there were 0 connections. Traffic Relayed ↑ 0 B, ↓ 0 B.
2022/10/14 01:49:27 error polling broker: read tcp [scrubbed]->[scrubbed]: read: connection reset by peer
2022/10/14 01:49:27 Error reading broker response: unexpected end of JSON input
2022/10/14 01:49:27 body:
2022/10/14 01:49:27 bad offer from broker
2022/10/14 02:00:18 In the last 30m0s, there were 0 connections. Traffic Relayed ↑ 0 B, ↓ 0 B.
2022/10/14 02:00:18 starting
2022/10/14 02:00:18 WebRTC: Created offer
2022/10/14 02:00:18 WebRTC: Set local description
2022/10/14 02:00:18 Offer: {"type":"offer","sdp":"v=0\r\no=- 6893084309929587048 1665712818 IN IP4 [scrubbed]\r\ns=-\r\nt=0 0\r\na=fingerprint:sha-256 BF:6A:76:02:37:8A:96:A4:6C:16:12:16:F5:40:86:65:F7:06:85:92:9D:3E:D7:8C:85:60:85:85:54:5C:37:ED\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:nhTnpZRAsoeUmxTh\r\na=ice-pwd:RLJbOGidLOUkKOLjDPXTUpWDbrRmWIgn\r\na=candidate:4056006514 1 udp 2130706431 [scrubbed] 43420 typ host\r\na=candidate:4056006514 2 udp 2130706431 [scrubbed] 43420 typ host\r\na=candidate:1367571592 1 udp 1694498815 [scrubbed] 43757 typ srflx raddr [scrubbed] rport 43757\r\na=candidate:1367571592 2 udp 1694498815 [scrubbed] 43757 typ srflx raddr [scrubbed] rport 43757\r\na=candidate:1309294897 1 udp 2130706431 [scrubbed] 43290 typ host\r\na=candidate:1309294897 2 udp 2130706431 [scrubbed] 43290 typ host\r\na=end-of-candidates\r\n"}
2022/10/14 02:00:44 NAT Type measurement: unknown -> restricted = restricted
2022/10/14 02:00:44 NAT type: restricted
2022/10/14 02:00:44 WebRTC: Created offer
2022/10/14 02:00:44 WebRTC: Set local description
2022/10/14 02:00:44 Offer: {"type":"offer","sdp":"v=0\r\no=- 1174260446418312236 1665712844 IN IP4 [scrubbed]\r\ns=-\r\nt=0 0\r\na=fingerprint:sha-256 71:98:09:F4:C4:3F:FB:78:58:26:0E:A8:E3:25:4F:E7:36:F4:E1:96:55:40:9E:8A:F2:8C:EC:53:04:7D:5F:E1\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:YQHqUMIrLPzrDWPO\r\na=ice-pwd:KVyewBeBGOZfJJXmHKTJBNxwjVadqxkj\r\na=candidate:4056006514 1 udp 2130706431 [scrubbed] 40071 typ host\r\na=candidate:4056006514 2 udp 2130706431 [scrubbed] 40071 typ host\r\na=candidate:1367571592 1 udp 1694498815 [scrubbed] 50127 typ srflx raddr [scrubbed] rport 50127\r\na=candidate:1367571592 2 udp 1694498815 [scrubbed] 50127 typ srflx raddr [scrubbed] rport 50127\r\na=candidate:1309294897 1 udp 2130706431 [scrubbed] 55970 typ host\r\na=candidate:1309294897 2 udp 2130706431 [scrubbed] 55970 typ host\r\na=end-of-candidates\r\n"}
2022/10/14 02:01:41 NAT Type measurement: restricted -> restricted = restricted
2022/10/14 02:30:50 In the last 30m0s, there were 0 connections. Traffic Relayed ↑ 0 B, ↓ 0 B.
2022/10/14 03:00:50 In the last 30m0s, there were 0 connections. Traffic Relayed ↑ 0 B, ↓ 0 B.
```
The planned restart takes place at 02:00 GMT. I don't know whether the error at 01:49 has any meaning. Broker seems to be 37.218.245.111 (greenhost.nl).