Anti-censorship issueshttps://gitlab.torproject.org/groups/tpo/anti-censorship/-/issues2024-03-19T12:34:48Zhttps://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/rdsys/-/issues/88bridgestrap still scans bridges but won't admit that any of them exist2022-02-21T17:00:32ZRoger Dingledinebridgestrap still scans bridges but won't admit that any of them existI see in bridgestrap's logs that it is still scanning bridges, e.g.
```
2022/02/08 19:56:46 Tested 25 bridges: 24 (96.0%) functional; 1 (4.0%) dysfunctional.
```
and meskio says that "the graphana dashboard for bridgestrap looks good, m...I see in bridgestrap's logs that it is still scanning bridges, e.g.
```
2022/02/08 19:56:46 Tested 25 bridges: 24 (96.0%) functional; 1 (4.0%) dysfunctional.
```
and meskio says that "the graphana dashboard for bridgestrap looks good, most bridges being functional"
but whenever I try to test any bridge via the web interface with its fingerprint, including fingerprints that I just watched bridgestrap successfully reach in its logs, it tells me
```
no resources for the given id
```
That is, it looks like the backend testing is going fine, but somehow the frontend has become disconnected from it.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/bridgestrap/-/issues/31bridgestrap still scans bridges but won't admit that any of them exist2022-02-11T16:54:24ZRoger Dingledinebridgestrap still scans bridges but won't admit that any of them existI see in bridgestrap's logs that it is still scanning bridges, e.g.
```
2022/02/08 19:56:46 Tested 25 bridges: 24 (96.0%) functional; 1 (4.0%) dysfunctional.
```
and meskio says that "the graphana dashboard for bridgestrap looks good, m...I see in bridgestrap's logs that it is still scanning bridges, e.g.
```
2022/02/08 19:56:46 Tested 25 bridges: 24 (96.0%) functional; 1 (4.0%) dysfunctional.
```
and meskio says that "the graphana dashboard for bridgestrap looks good, most bridges being functional"
but whenever I try to test any bridge via the web interface with its fingerprint, including fingerprints that I just watched bridgestrap successfully reach in its logs, it tells me
```
no resources for the given id
```
That is, it looks like the backend testing is going fine, but somehow the frontend has become disconnected from it.meskiomeskio@torproject.orgmeskiomeskio@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/bridgestrap/-/issues/22Bridgestrap stopped producing metrics for CollecTor2021-11-02T08:28:29ZCecylia BocovichBridgestrap stopped producing metrics for CollecTor@irl just mentioned that bridgestrap has stopped producing metrics. Sure enough, the last time bridgestrap wrote to the metrics log file was July 20th (9 days ago).@irl just mentioned that bridgestrap has stopped producing metrics. Sure enough, the last time bridgestrap wrote to the metrics log file was July 20th (9 days ago).meskiomeskio@torproject.orgmeskiomeskio@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/censorship-analysis/-/issues/40022bridgetest: make output format more robust2022-03-01T15:57:24ZRoger Dingledinebridgetest: make output format more robustHere's the preliminary data format for the logs that come out of the bridgetest docker image: <br>
https://gitlab.torproject.org/cohosh/probetest#data-format
and there are some scripts like <br>
https://gitlab.torproject.org/cohosh/prob...Here's the preliminary data format for the logs that come out of the bridgetest docker image: <br>
https://gitlab.torproject.org/cohosh/probetest#data-format
and there are some scripts like <br>
https://gitlab.torproject.org/cohosh/probetest/-/blob/main/analysis/makecsv <br>
that help to generate the csv format.
We should look through peer formats, like OONI's data format and censored planet, and get ideas for what else we'll wish we'd included.
For examples:
* timestamp of when the test happened (perhaps rounded to something granular)
* which version of the test generated this entry
* more detail about the test target, e.g. the hashed fingerprint of the bridge that we tested.
* time spent from start of test until result (I realized this one after looking at the various aborted tests from China, where if we knew how long the successful tests took, and found that they were already bumping up against our timeout, that would be useful to know.)
* (maybe, I'm not sure, we should ask others for advice) All of the stuff that's implicit in the filename and directory structure, so it's in the file too -- which country we're testing from, AS we map to, the name of the test, etc.shelikhooshelikhoohttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/trac/-/issues/15593Bring sanity to the tor side of the PT shutdown process.2021-11-15T18:55:15ZYawning AngelBring sanity to the tor side of the PT shutdown process.This is the final phase of my great PT shutdown process cleanup as a follow up to legacy/trac#15545.
Now that there's a portable mechanism to signal termination to PTs (close the stdin), we should change the PT shutdown process to allow...This is the final phase of my great PT shutdown process cleanup as a follow up to legacy/trac#15545.
Now that there's a portable mechanism to signal termination to PTs (close the stdin), we should change the PT shutdown process to allow graceful termination to look like this:
1. Close stdin (and on U*IX, send a SIGTERM, PT behavior here is equivalent).
2. Wait for a grace period (~1 sec?)
3. If the child still is not dead, send a SIGKILL/TerminateProcess(). (Failsafe)
This fixes legacy/trac#9330 in that, PTs that wish to trap a graceful shutdown on Windows have a way to do so, despite the final stage of the process killing the PT in the most violent way possible as a failsafe (realistically, PTs should exit shortly after step 1).Tor: unspecifiedYawning AngelYawning Angelhttps://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/189Broken links and very old builds on GitHub TheTorProject/gettorbrowser2023-12-19T00:03:34ZchaoticowlBroken links and very old builds on GitHub TheTorProject/gettorbrowserThe gettorbrowser repository on github is providing very old builds, the latest version there is 12.5.1 while it should be 13.0.5 by now.
The links for getting TBB from google drive and gitlab are also broken:
https://github.com/TheTorP...The gettorbrowser repository on github is providing very old builds, the latest version there is 12.5.1 while it should be 13.0.5 by now.
The links for getting TBB from google drive and gitlab are also broken:
https://github.com/TheTorProject/gettorbrowser
Is there any way I can help with this?meskiomeskio@torproject.orgmeskiomeskio@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40351broker is not publishing metrics to collector2024-03-21T15:06:48Zmeskiomeskio@torproject.orgbroker is not publishing metrics to collectorYesterday (2024-03-20) the snowflake broker didn't publish any metrics for collector. I have checked /home/snowflake-broker/metrics.log in the broker server and the last published metric is:
```
snowflake-stats-end 2024-03-19 23:21:24 (8...Yesterday (2024-03-20) the snowflake broker didn't publish any metrics for collector. I have checked /home/snowflake-broker/metrics.log in the broker server and the last published metric is:
```
snowflake-stats-end 2024-03-19 23:21:24 (86400 s)
```
Looking at grafana everything seems to be working normally.https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/25593Broker needs better resilience against DoS2024-02-14T14:59:35ZArlo BreaultBroker needs better resilience against DoSMigrated from https://github.com/keroserene/snowflake/issues/25Migrated from https://github.com/keroserene/snowflake/issues/25Roger DingledineRoger Dingledinehttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/29734Broker should receive country stats information from Proxy and Client2021-05-20T19:40:10ZCecylia BocovichBroker should receive country stats information from Proxy and ClientWe can use existing geoip data to collect statistics about where clients are connecting from in order to detect possible blocking events. These should be gathered both from the initial domain-fronted client connection and from the proxie...We can use existing geoip data to collect statistics about where clients are connecting from in order to detect possible blocking events. These should be gathered both from the initial domain-fronted client connection and from the proxies (to be passed to the broker) in order to detect the blocking of individual proxies or the blocking of the WebRTC connections.Sponsor 28: Reliable Anonymous Communication Evading Censors and Repressors (RACECAR)Cecylia BocovichCecylia Bocovichhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40250Broker side channel fallback mechanism2023-10-03T18:22:22Zmeskiomeskio@torproject.orgBroker side channel fallback mechanismCurrently we are using domain fronting as our main side channel to connect to the broker, but amp cache is also supported. When the domain fronting is blocked (like in https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/115) ...Currently we are using domain fronting as our main side channel to connect to the broker, but amp cache is also supported. When the domain fronting is blocked (like in https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/115) it will be useful to automatically fall back to amp cache.
This would be really nice to be encoded in the bridge line, but we are already near the limit on size for the bridge line.
The snowflake client could use the bridgeline provided side channel configuration and if that fails try to use the one provided by the flags passed to the binary on launch (by `ClientTransportPlugin`). This has the problem that those flags will not be distributed by Circumvention Settings and needs some coordination with the different tor applications to have the same defaults everywhere. We might need to think how snowflake library users will use this fallback (or if they need to implement it themselves).https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40206Broker status 500 when client requests fingerprint of snowflake-022023-03-14T16:42:43ZDavid Fifielddcf@torproject.orgBroker status 500 when client requests fingerprint of snowflake-02I was not sure whether distributed bridge support
(#40129, #28651) was supposed to be working yet, so I tried it.
I am using the client from commit 9ce1de4eee4e23c918c7c5e96666ff5c6ddc654e.
When I tried rendezvousing with the fingerprint...I was not sure whether distributed bridge support
(#40129, #28651) was supposed to be working yet, so I tried it.
I am using the client from commit 9ce1de4eee4e23c918c7c5e96666ff5c6ddc654e.
When I tried rendezvousing with the fingerprint of the
[snowflake-02 bridge](tpo/anti-censorship/pluggable-transports/snowflake#40122),
I got a 500 Internal Server Error, which was unexpected.
It makes me wonder if the broker is encountering an internal error and panicking,
or if 500 is the intended response code.
This torrc file works:
```
UseBridges 1
SocksPort auto
DataDirectory datadir
ClientTransportPlugin snowflake exec ./client -log snowflake.log
Bridge snowflake 192.0.2.3:80 2B280B23E1107BB62ABFC40DDCC8824814F80A72 fingerprint=2B280B23E1107BB62ABFC40DDCC8824814F80A72 url=https://snowflake-broker.torproject.net/ ice=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
```
This torrc file does not work. The only difference is changing the fingerprint
`2B280B23E1107BB62ABFC40DDCC8824814F80A72` to `8838024498816A039FCBBAB14E6F40A0843051FA`
in both places.
```
UseBridges 1
SocksPort auto
DataDirectory datadir
ClientTransportPlugin snowflake exec ./client -log snowflake.log
Bridge snowflake 192.0.2.3:80 8838024498816A039FCBBAB14E6F40A0843051FA fingerprint=8838024498816A039FCBBAB14E6F40A0843051FA url=https://snowflake-broker.torproject.net/ ice=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
```
The broker's HTTP response is:
```
500 Internal Server Error
Access-Control-Allow-Headers: Origin, X-Session-ID
Access-Control-Allow-Origin: *
Content-Length: 0
Date: Tue, 04 Oct 2022 16:33:06 GMT
```https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/25594Broker: investigate non-domain-fronting secure client / proxy registrations2024-02-27T18:55:26ZArlo BreaultBroker: investigate non-domain-fronting secure client / proxy registrations> Pasting discussion from email,
>
>> in the Flashproxy case, registration wasn't
>> bidi, and I think they imagined using insecure
>> channels to register like OSSes. In Snowflake,
>> the client is making TLS connections with the
>> bro...> Pasting discussion from email,
>
>> in the Flashproxy case, registration wasn't
>> bidi, and I think they imagined using insecure
>> channels to register like OSSes. In Snowflake,
>> the client is making TLS connections with the
>> broker, which amounts to the same thing as
>> encrypting the payload with the facilitator's
>> public key.
>
> Also,
>
>> There's also the case where an adversary DOSes the facilitator with a
>> bunch of fake client or proxy registrations and things like that.
>
> This is now legacy/trac#25593
>
>> Also, there is the potential that in the future we might need some
>> sort of non-domain-fronting rendezvous. It seems that right now we
>> have an ecosystem of tools growing that assumes domain-fronting will
>> always be available & effective. May be worth considering how to
>> prepare for regions where this might not work as well in the future.
>
> So this ticket should probably be for that.
\\ Migrated from https://github.com/keroserene/snowflake/issues/13
Ideas that have been proposed or done:
* #25985 AMP cache
* #25874 DNS
* #26151 Amazon SQSDavid Fifielddcf@torproject.orgDavid Fifielddcf@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/31285Browsers accumulate permanently open UDP sockets over time2020-06-27T13:40:23ZcypherpunksBrowsers accumulate permanently open UDP sockets over timeAfter running tests with both Firefox and Chrome for a couple of days (see ticket:31278), my Windows process status utility shows that both browsers have accumulated a bunch of open UDP sockets, proportional to the number of clients they...After running tests with both Firefox and Chrome for a couple of days (see ticket:31278), my Windows process status utility shows that both browsers have accumulated a bunch of open UDP sockets, proportional to the number of clients they've served so far. Once opened, the UDP sockets stay allocated by the browser's process until I close the corresponding static page tab or turn off the addon. So far, Firefox has created 64 sockets (32 each IPv4 & v6) while Chrome has only 14 (9 v4 & 5 v6) due to the Chrome client hanging bug reported earlier. Each time a new client is served, more sockets are created and never closed.
Not a problem normally, they're not a scarce resource, but if you leave a browser open for weeks or months at a time they'll really add up, especially once Snowflake gets more popular and the number of clients served per day increases.Cecylia BocovichCecylia Bocovichhttps://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/12781Buckets don't work if Stability code is disabled2020-06-27T13:43:09ZMatthew FinkelBuckets don't work if Stability code is disabledWhoops. We can create them but we don't get any bridges when they're dumped to file.Whoops. We can create them but we don't get any bridges when they're dumped to file.Isis LovecruftIsis Lovecrufthttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/33405Bug in interaction between uMatrix and Snowflake (snowflake-webextension)2020-06-27T13:40:14ZcypherpunksBug in interaction between uMatrix and Snowflake (snowflake-webextension)Error in Snowflake debug console, caused by a line in vapi-background.js in uMatrix:
`Unchecked lastError value: Error: First-Party Isolation is enabled, but the required 'firstPartyDomain' attribute was not set.`
The uMatrix setting c...Error in Snowflake debug console, caused by a line in vapi-background.js in uMatrix:
`Unchecked lastError value: Error: First-Party Isolation is enabled, but the required 'firstPartyDomain' attribute was not set.`
The uMatrix setting causing this error is:
`Spoof HTTP referrer string of third-party requests`, when set to true.
This is a bug either in Snowflake, or uMatrix.https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/36Build a bridge censorship measurement system for Salmon2023-03-24T16:02:19ZPhilipp Winterphw@torproject.orgBuild a bridge censorship measurement system for SalmonSalmon needs to know if and when a bridge is blocked, so it can update client reputation scores. Let's use this issue to build that censorship measurement mechanism. There are several ways to go about this:
1. We could set up [bridgestr...Salmon needs to know if and when a bridge is blocked, so it can update client reputation scores. Let's use this issue to build that censorship measurement mechanism. There are several ways to go about this:
1. We could set up [bridgestrap](https://gitlab.torproject.org/tpo/anti-censorship/bridgestrap) instances in censored networks and design a control channel between our central rdsys instance and the various bridgestrap instances. [wolpertinger](https://gitlab.torproject.org/tpo/anti-censorship/wolpertinger) was originally designed for that and we may be able to reuse some ideas and code. See tpo/anti-censorship/censorship-analysis#34258 for more details.
1. We can outsource the problem to OONI. That was the original plan but OONI probes are run by untrusted strangers, some of which could be censors that try to find and block bridges. OONI, at least in its current form, is therefore not a good choice.
1. We could incorporate passively-gathered data like the countries from which bridges have recently seen clients.
Option 1) strikes me as a good way forward because we already have a lot of the necessary code in place. Essentially, we still need a low-bandwidth, low-latency, censorship-resistant communication channel between bridgestrap instances in various countries and rdsys. If we go down that route, a few more questions emerge:
* Should the bridgestrap instances periodically poll for new bridges to test? Or should rdsys push these bridges to bridgestrap?
* What should the censorship-resistant communication channel look like? A domain-fronted API like moat may be good enough.
* How should rdsys communicate with these bridgestrap instances? Should it implement a new distributor like wolpertinger? Or should this functionality live in the backend? For what it's worth, rdsys's [bridge testing mechanism](https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/blob/master/doc/resource-testing.md) lives in the backend.Sponsor 96: Rapid Expansion of Access to the Uncensored Internet through Tor in China, Hong Kong, & Tibethttps://gitlab.torproject.org/tpo/anti-censorship/censorship-analysis/-/issues/7137Build a tool that a censored developer can run to discover why their Tor is f...2020-06-27T13:43:43ZKarsten LoesingBuild a tool that a censored developer can run to discover why their Tor is failing to connectWe should develop an automated censorship diagnostics toolkit for Tor. It gets deployed when someone says something like "tor doesn't work in my country anymore". The goal is to have them download this toolkit, which will automatically...We should develop an automated censorship diagnostics toolkit for Tor. It gets deployed when someone says something like "tor doesn't work in my country anymore". The goal is to have them download this toolkit, which will automatically figure out if tor is blocked, how it might be blocked, and if any of the known ways to bypass tor censorship works, and if so, tell the client "you need X." Where X is bridges, private bridges, obfsproxy, private obfsproxy. If nothing works, it collects lots of data, and sends it back to tor.
Tor then analyzes the data and learns a new way of blocking tor as feedback into our anti-censorship work. Maybe there is a quick solution for the user in blocked country, maybe there isn't.https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/trac/-/issues/10006Build an obfs-flash PT bundle2020-06-27T13:44:02ZDavid Fifielddcf@torproject.orgBuild an obfs-flash PT bundleCreate a test pluggable transports bundle with the obfs3_flashproxy transport in place of the flashproxy transport.Create a test pluggable transports bundle with the obfs3_flashproxy transport in place of the flashproxy transport.David Fifielddcf@torproject.orgDavid Fifielddcf@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/docker-snowflake-proxy/-/issues/12build and upload docker-hub image for 2.6.02023-06-26T09:11:45Ztrinity-1686abuild and upload docker-hub image for 2.6.0`thetorproject/snowflake-proxy:latest` is currently 2.5.1, and there is no 2.6.0 tag available.`thetorproject/snowflake-proxy:latest` is currently 2.5.1, and there is no 2.6.0 tag available.meskiomeskio@torproject.orgmeskiomeskio@torproject.org