Anti-censorship issueshttps://gitlab.torproject.org/groups/tpo/anti-censorship/-/issues2021-04-26T15:26:36Zhttps://gitlab.torproject.org/tpo/anti-censorship/censorship-analysis/-/issues/31998Linked Tor Relays To Bypass Probing?2021-04-26T15:26:36ZTracLinked Tor Relays To Bypass Probing?As tor bridges are obtainable, one idea would be for a tor bridge to "link" with another tor bridge. Here, the bridges are obtained in pairs. What linking does is that the client has to send the exact message with sync(using different ke...As tor bridges are obtainable, one idea would be for a tor bridge to "link" with another tor bridge. Here, the bridges are obtained in pairs. What linking does is that the client has to send the exact message with sync(using different keys of course) to both bridges, after the bridges receive the message, one server claims the connection and then sees whether the other receives the message as well. This way, there are a lot more combinations to check for the censor.
**Trac**:
**Username**: Aphrodites1995https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/31971Snowflake is *consistently* extremely slow when using the Windows build2020-06-27T13:40:19ZcypherpunksSnowflake is *consistently* extremely slow when using the Windows buildSnowflake is *consistently* extremely slow when using the Windows build, I tried 5 times by restarting the browser and I always get 20kb/s max. In my Linux machine it works normally.Snowflake is *consistently* extremely slow when using the Windows build, I tried 5 times by restarting the browser and I always get 20kb/s max. In my Linux machine it works normally.Cecylia BocovichCecylia Bocovichhttps://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/31967BridgeDB Server uses insecure pseudorandom generator for selecting cached cap...2020-06-27T13:42:46ZTracBridgeDB Server uses insecure pseudorandom generator for selecting cached captchahttps://gitweb.torproject.org/bridgedb.git/tree/bridgedb/captcha.py#n389
From python documentation: The pseudo-random generators of this module (random) should not be used for security purposes.
It should use the secrets module `secret...https://gitweb.torproject.org/bridgedb.git/tree/bridgedb/captcha.py#n389
From python documentation: The pseudo-random generators of this module (random) should not be used for security purposes.
It should use the secrets module `secrets.choice()` or if you plan to keep python2 compatibility `random.SystemRandom.choice()`.
**Trac**:
**Username**: willbarrhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/31960Hello, currently, in China, Tor Browser 9.0a7 version can't establish a Tor n...2023-08-01T23:59:57ZTracHello, currently, in China, Tor Browser 9.0a7 version can't establish a Tor network connection through snowflake bridgeHello, currently, in China, Tor Browser 9.0a7 version can't establish a Tor network connection through snowflake bridge
Below are the Tor log messages.
```
10/4/19, 04:44:38.869 [NOTICE] DisableNetwork is set. Tor will not make or acc...Hello, currently, in China, Tor Browser 9.0a7 version can't establish a Tor network connection through snowflake bridge
Below are the Tor log messages.
```
10/4/19, 04:44:38.869 [NOTICE] DisableNetwork is set. Tor will not make or accept non-control network connections. Shutting down all existing connections.
10/4/19, 04:44:44.387 [NOTICE] DisableNetwork is set. Tor will not make or accept non-control network connections. Shutting down all existing connections.
10/4/19, 04:44:44.387 [NOTICE] DisableNetwork is set. Tor will not make or accept non-control network connections. Shutting down all existing connections.
10/4/19, 04:44:44.387 [NOTICE] DisableNetwork is set. Tor will not make or accept non-control network connections. Shutting down all existing connections.
10/4/19, 04:44:44.387 [NOTICE] Opening Socks listener on 127.0.0.1:9150
10/4/19, 04:44:44.387 [NOTICE] Opened Socks listener on 127.0.0.1:9150
10/4/19, 04:44:45.248 [NOTICE] Bootstrapped 1% (conn_pt): Connecting to pluggable transport
10/4/19, 04:44:45.250 [NOTICE] Bootstrapped 2% (conn_done_pt): Connected to pluggable transport
10/4/19, 04:45:08.319 [NOTICE] Bootstrapped 10% (conn_done): Connected to a relay
10/4/19, 04:45:38.337 [WARN] Problem bootstrapping. Stuck at 10% (conn_done): Connected to a relay. (DONE; DONE; count 1; recommendation warn; host 2B280B23E1107BB62ABFC40DDCC8824814F80A72 at 0.0.3.0:1)
10/4/19, 04:45:38.338 [WARN] 1 connections have failed:
10/4/19, 04:45:38.338 [WARN] 1 connections died in state handshaking (TLS) with SSL state SSLv3/TLS write client hello in HANDSHAKE
10/4/19, 04:45:38.357 [NOTICE] Closing no-longer-configured Socks listener on 127.0.0.1:9150
10/4/19, 04:45:38.357 [NOTICE] DisableNetwork is set. Tor will not make or accept non-control network connections. Shutting down all existing connections.
10/4/19, 04:45:38.358 [WARN] Pluggable Transport process terminated with status code 0
```
snowflake-broker.azureedge.net are not blocked by China's firewall.
ajax.aspnetcdn.com are not blocked by China's firewall.
stun.ekiga.net are not blocked by China's firewall.
I will upload my state file.
Thank you very much for your help. I really appreciate it.
**Trac**:
**Username**: amiableclarity2011Cecylia BocovichCecylia Bocovichhttps://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/31936Write usage metrics to disk before terminating2020-06-27T13:42:46ZPhilipp Winterphw@torproject.orgWrite usage metrics to disk before terminatingBridgeDB writes its usage metrics to disk every 24 hours. It does not, however, write the metrics to disk when it's restarted, which means we are losing up to 24 hours worth of usage metrics after each restart. We should make BridgeDB wr...BridgeDB writes its usage metrics to disk every 24 hours. It does not, however, write the metrics to disk when it's restarted, which means we are losing up to 24 hours worth of usage metrics after each restart. We should make BridgeDB write its incomplete metrics to disk before it terminates.
Let's also make sure that this fix plays well with our logrotate cronjob on polyanthum.Sponsor 30 - Objective 2.1https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/31930Hello, Currently, Tor Browser 9.0a7 can't connect to Tor network through Snow...2023-08-02T00:00:14ZTracHello, Currently, Tor Browser 9.0a7 can't connect to Tor network through Snowflake bridge.Hello, Currently, Tor Browser 9.0a7 can't connect to Tor network through Snowflake bridge.
Below are Tor log messages.
```
10/2/19, 08:04:51.299 [NOTICE] DisableNetwork is set. Tor will not make or accept non-control network connection...Hello, Currently, Tor Browser 9.0a7 can't connect to Tor network through Snowflake bridge.
Below are Tor log messages.
```
10/2/19, 08:04:51.299 [NOTICE] DisableNetwork is set. Tor will not make or accept non-control network connections. Shutting down all existing connections.
10/2/19, 08:04:56.280 [NOTICE] DisableNetwork is set. Tor will not make or accept non-control network connections. Shutting down all existing connections.
10/2/19, 08:04:56.280 [NOTICE] DisableNetwork is set. Tor will not make or accept non-control network connections. Shutting down all existing connections.
10/2/19, 08:04:56.280 [NOTICE] DisableNetwork is set. Tor will not make or accept non-control network connections. Shutting down all existing connections.
10/2/19, 08:04:56.280 [NOTICE] Opening Socks listener on 127.0.0.1:9150
10/2/19, 08:04:56.280 [NOTICE] Opened Socks listener on 127.0.0.1:9150
10/2/19, 08:04:57.267 [NOTICE] Bootstrapped 1% (conn_pt): Connecting to pluggable transport
10/2/19, 08:04:57.269 [NOTICE] Bootstrapped 2% (conn_done_pt): Connected to pluggable transport
10/2/19, 08:05:22.368 [NOTICE] Bootstrapped 10% (conn_done): Connected to a relay
10/2/19, 08:05:52.390 [WARN] Problem bootstrapping. Stuck at 10% (conn_done): Connected to a relay. (DONE; DONE; count 1; recommendation warn; host 2B280B23E1107BB62ABFC40DDCC8824814F80A72 at 0.0.3.0:1)
10/2/19, 08:05:52.390 [WARN] 1 connections have failed:
10/2/19, 08:05:52.391 [WARN] 1 connections died in state handshaking (TLS) with SSL state SSLv3/TLS write client hello in HANDSHAKE
10/2/19, 08:05:52.405 [NOTICE] Closing no-longer-configured Socks listener on 127.0.0.1:9150
10/2/19, 08:05:52.405 [NOTICE] DisableNetwork is set. Tor will not make or accept non-control network connections. Shutting down all existing connections.
10/2/19, 08:05:52.405 [WARN] Pluggable Transport process terminated with status code 0
10/2/19, 08:06:00.472 [NOTICE] DisableNetwork is set. Tor will not make or accept non-control network connections. Shutting down all existing connections.
10/2/19, 08:06:00.473 [NOTICE] DisableNetwork is set. Tor will not make or accept non-control network connections. Shutting down all existing connections.
10/2/19, 08:06:00.473 [NOTICE] DisableNetwork is set. Tor will not make or accept non-control network connections. Shutting down all existing connections.
10/2/19, 08:06:00.473 [NOTICE] Opening Socks listener on 127.0.0.1:9150
10/2/19, 08:06:00.473 [NOTICE] Opened Socks listener on 127.0.0.1:9150
10/2/19, 08:06:51.913 [WARN] Problem bootstrapping. Stuck at 10% (conn_done): Connected to a relay. (DONE; DONE; count 2; recommendation warn; host 2B280B23E1107BB62ABFC40DDCC8824814F80A72 at 0.0.3.0:1)
10/2/19, 08:06:51.914 [WARN] 2 connections have failed:
10/2/19, 08:06:51.914 [WARN] 2 connections died in state handshaking (TLS) with SSL state SSLv3/TLS write client hello in HANDSHAKE
10/2/19, 08:06:51.925 [NOTICE] Closing no-longer-configured Socks listener on 127.0.0.1:9150
10/2/19, 08:06:51.925 [NOTICE] DisableNetwork is set. Tor will not make or accept non-control network connections. Shutting down all existing connections.
10/2/19, 08:06:51.925 [WARN] Pluggable Transport process terminated with status code 0
```
stun.ekiga.net is not blocked by China's firewall.
Below are the Ping results of stun.ekiga.net.
```
ping stun.ekiga.net
PING stun.ekiga.net (216.93.246.18) 56(84) bytes of data.
64 bytes from 216.93.246.18 (216.93.246.18): icmp_seq=1 ttl=48 time=268 ms
64 bytes from 216.93.246.18 (216.93.246.18): icmp_seq=2 ttl=48 time=257 ms
64 bytes from 216.93.246.18 (216.93.246.18): icmp_seq=3 ttl=48 time=240 ms
64 bytes from 216.93.246.18 (216.93.246.18): icmp_seq=4 ttl=48 time=287 ms
64 bytes from 216.93.246.18 (216.93.246.18): icmp_seq=5 ttl=48 time=278 ms
64 bytes from 216.93.246.18 (216.93.246.18): icmp_seq=6 ttl=48 time=282 ms
64 bytes from 216.93.246.18 (216.93.246.18): icmp_seq=7 ttl=48 time=258 ms
64 bytes from 216.93.246.18 (216.93.246.18): icmp_seq=8 ttl=48 time=284 ms
64 bytes from 216.93.246.18 (216.93.246.18): icmp_seq=9 ttl=48 time=283 ms
64 bytes from 216.93.246.18 (216.93.246.18): icmp_seq=10 ttl=48 time=276 ms
64 bytes from 216.93.246.18 (216.93.246.18): icmp_seq=11 ttl=48 time=278 ms
64 bytes from 216.93.246.18 (216.93.246.18): icmp_seq=12 ttl=48 time=252 ms
64 bytes from 216.93.246.18 (216.93.246.18): icmp_seq=13 ttl=48 time=279 ms
64 bytes from 216.93.246.18 (216.93.246.18): icmp_seq=14 ttl=48 time=266 ms
64 bytes from 216.93.246.18 (216.93.246.18): icmp_seq=15 ttl=48 time=273 ms
64 bytes from 216.93.246.18 (216.93.246.18): icmp_seq=16 ttl=48 time=238 ms
64 bytes from 216.93.246.18 (216.93.246.18): icmp_seq=17 ttl=48 time=281 ms
64 bytes from 216.93.246.18 (216.93.246.18): icmp_seq=18 ttl=48 time=266 ms
64 bytes from 216.93.246.18 (216.93.246.18): icmp_seq=19 ttl=48 time=270 ms
64 bytes from 216.93.246.18 (216.93.246.18): icmp_seq=20 ttl=48 time=267 ms
64 bytes from 216.93.246.18 (216.93.246.18): icmp_seq=21 ttl=48 time=248 ms
64 bytes from 216.93.246.18 (216.93.246.18): icmp_seq=22 ttl=48 time=267 ms
64 bytes from 216.93.246.18 (216.93.246.18): icmp_seq=23 ttl=48 time=261 ms
64 bytes from 216.93.246.18 (216.93.246.18): icmp_seq=24 ttl=48 time=272 ms
64 bytes from 216.93.246.18 (216.93.246.18): icmp_seq=25 ttl=48 time=231 ms
64 bytes from 216.93.246.18 (216.93.246.18): icmp_seq=26 ttl=48 time=261 ms
64 bytes from 216.93.246.18 (216.93.246.18): icmp_seq=27 ttl=48 time=283 ms
64 bytes from 216.93.246.18 (216.93.246.18): icmp_seq=28 ttl=48 time=282 ms
64 bytes from 216.93.246.18 (216.93.246.18): icmp_seq=29 ttl=48 time=274 ms
64 bytes from 216.93.246.18 (216.93.246.18): icmp_seq=30 ttl=48 time=270 ms
64 bytes from 216.93.246.18 (216.93.246.18): icmp_seq=31 ttl=48 time=254 ms
64 bytes from 216.93.246.18 (216.93.246.18): icmp_seq=32 ttl=48 time=269 ms
64 bytes from 216.93.246.18 (216.93.246.18): icmp_seq=33 ttl=48 time=251 ms
64 bytes from 216.93.246.18 (216.93.246.18): icmp_seq=34 ttl=48 time=223 ms
64 bytes from 216.93.246.18 (216.93.246.18): icmp_seq=35 ttl=48 time=258 ms
64 bytes from 216.93.246.18 (216.93.246.18): icmp_seq=36 ttl=48 time=279 ms
64 bytes from 216.93.246.18 (216.93.246.18): icmp_seq=37 ttl=48 time=269 ms
64 bytes from 216.93.246.18 (216.93.246.18): icmp_seq=38 ttl=48 time=272 ms
64 bytes from 216.93.246.18 (216.93.246.18): icmp_seq=40 ttl=48 time=262 ms
64 bytes from 216.93.246.18 (216.93.246.18): icmp_seq=41 ttl=48 time=252 ms
64 bytes from 216.93.246.18 (216.93.246.18): icmp_seq=42 ttl=48 time=252 ms
64 bytes from 216.93.246.18 (216.93.246.18): icmp_seq=43 ttl=48 time=256 ms
64 bytes from 216.93.246.18 (216.93.246.18): icmp_seq=44 ttl=48 time=269 ms
^C
--- stun.ekiga.net ping statistics ---
44 packets transmitted, 43 received, 2% packet loss, time 48162ms
rtt min/avg/max/mdev = 223.962/265.583/287.125/14.651 ms
```
I will upload my state file.
**Trac**:
**Username**: amiableclarity2011https://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/31903Update translations and push translation requests to Transifex2021-07-01T17:47:15ZPhilipp Winterphw@torproject.orgUpdate translations and push translation requests to TransifexIt's time to update BridgeDB's existing translations and to push new translation requests because some of BridgeDB's strings have changed in the meanwhile.It's time to update BridgeDB's existing translations and to push new translation requests because some of BridgeDB's strings have changed in the meanwhile.Philipp Winterphw@torproject.orgPhilipp Winterphw@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake-webext/-/issues/7Add a short FAQ to snowflake.tp.o2021-06-17T14:13:21ZArlo BreaultAdd a short FAQ to snowflake.tp.oThis should include explanations for the missing feature error messages. See comment:13:ticket:31391This should include explanations for the missing feature error messages. See comment:13:ticket:31391https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/31902Add a short FAQ to snowflake.tp.o2021-07-09T18:26:26ZArlo BreaultAdd a short FAQ to snowflake.tp.oThis should include explanations for the missing feature error messages. See comment:13:ticket:31391This should include explanations for the missing feature error messages. See comment:13:ticket:31391https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/meek/-/issues/31890Redeploy meek-server instances using Go 1.12.10+ / 1.13.1+2020-06-27T13:44:11ZDavid Fifielddcf@torproject.orgRedeploy meek-server instances using Go 1.12.10+ / 1.13.1+https://groups.google.com/d/msg/golang-announce/cszieYyuL9Q/g4Z7pKaqAgAJ
> We have just released Go 1.13.1 and Go 1.12.10 to address a recently reported security issue. We recommend that all affected users update to one of these releases...https://groups.google.com/d/msg/golang-announce/cszieYyuL9Q/g4Z7pKaqAgAJ
> We have just released Go 1.13.1 and Go 1.12.10 to address a recently reported security issue. We recommend that all affected users update to one of these releases (if you’re not sure which, choose Go 1.13.1).
>
> net/http (through net/textproto) used to accept and normalize invalid HTTP/1.1 headers with a space before the colon, in violation of RFC 7230. If a Go server is used behind an uncommon reverse proxy that accepts and forwards but doesn't normalize such invalid headers, the reverse proxy and the server can interpret the headers differently. This can lead to filter bypasses or [request smuggling](https://portswigger.net/blog/http-desync-attacks-request-smuggling-reborn), the latter if requests from separate clients are multiplexed onto the same upstream connection by the proxy. Such invalid headers are now rejected by Go servers, and passed without normalization to Go client applications.
>
> The issue is CVE-2019-16276 and Go issue https://golang.org/issue/34540.
We need to redeploy the following servers:
* ~~cymrubridge02 (backend for meek-azure, run by inf0)~~
* ~~BridgeDB Moat (run by phw)~~
* ~~starman (throttled meek.bamsoftware.com, run by dcf)~~
* ~~maenad (unthrottled meek.bamsoftware.com, run by dcf)~~
* ~~GAEuploader (gaeuploader.meek.bamsoftware.com, run by dcf)~~
The Moat configuration uses a reverse proxy, so this is perhaps relevant to us.Sina RabbaniSina Rabbanihttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/31889Rebuild and redeploy broker and bridge using Go 1.12.10+ / 1.13.1+2020-06-27T13:40:20ZDavid Fifielddcf@torproject.orgRebuild and redeploy broker and bridge using Go 1.12.10+ / 1.13.1+https://groups.google.com/d/msg/golang-announce/cszieYyuL9Q/g4Z7pKaqAgAJ
> We have just released Go 1.13.1 and Go 1.12.10 to address a recently reported security issue. We recommend that all affected users update to one of these releases...https://groups.google.com/d/msg/golang-announce/cszieYyuL9Q/g4Z7pKaqAgAJ
> We have just released Go 1.13.1 and Go 1.12.10 to address a recently reported security issue. We recommend that all affected users update to one of these releases (if you’re not sure which, choose Go 1.13.1).
>
> net/http (through net/textproto) used to accept and normalize invalid HTTP/1.1 headers with a space before the colon, in violation of RFC 7230. If a Go server is used behind an uncommon reverse proxy that accepts and forwards but doesn't normalize such invalid headers, the reverse proxy and the server can interpret the headers differently. This can lead to filter bypasses or [request smuggling](https://portswigger.net/blog/http-desync-attacks-request-smuggling-reborn), the latter if requests from separate clients are multiplexed onto the same upstream connection by the proxy. Such invalid headers are now rejected by Go servers, and passed without normalization to Go client applications.
>
> The issue is CVE-2019-16276 and Go issue https://golang.org/issue/34540.
It doesn't look like this is urgent for us, given the details of our deployment.Cecylia BocovichCecylia Bocovichhttps://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/31878Make BridgeDB and bridge authority more resilient2020-11-20T18:46:03ZPhilipp Winterphw@torproject.orgMake BridgeDB and bridge authority more resilientWe should explore options to decentralise BridgeDB and/or our bridge authority.We should explore options to decentralise BridgeDB and/or our bridge authority.Sponsor 30 - Objective 2.4https://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/31876Overhaul BridgeDB's documentation and specification2020-10-29T18:39:08ZPhilipp Winterphw@torproject.orgOverhaul BridgeDB's documentation and specificationBridgeDB's documentation is slightly outdated and its [specification](https://gitweb.torproject.org/torspec.git/tree/bridgedb-spec.txt) is severely outdated. It's time to update both.BridgeDB's documentation is slightly outdated and its [specification](https://gitweb.torproject.org/torspec.git/tree/bridgedb-spec.txt) is severely outdated. It's time to update both.Sponsor 30 - Objective 2.4https://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/31875BridgeDB should consider a user's location2021-09-09T14:18:39ZPhilipp Winterphw@torproject.orgBridgeDB should consider a user's locationbridges.torproject.org knows the user's physical location and should consider it when returning bridges. For example, if somebody in country X asks for an obfsN bridge but BridgeDB knows that only obfsN+1 works in X (e.g., by consulting ...bridges.torproject.org knows the user's physical location and should consider it when returning bridges. For example, if somebody in country X asks for an obfsN bridge but BridgeDB knows that only obfsN+1 works in X (e.g., by consulting the result of tpo/community/outreach#28531), it should return obfsN+1.
Ideally, we would do this for all of BridgeDB's distribution mechanisms. We could also do it for email – if the user emailed bridges+CC@bridges.torproject.org. As I understand it, we cannot do it for moat because BridgeDB doesn't get to see the user's IP address in this case.Sponsor 30 - Objective 3.3meskiomeskio@torproject.orgmeskiomeskio@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/1Implement the Salmon bridge distribution mechanism2020-10-29T18:08:40ZPhilipp Winterphw@torproject.orgImplement the Salmon bridge distribution mechanismBridgeDB currently has three bridge distribution mechanisms: Email, HTTPS, and moat. Email is problematic because its interaction mechanism is complicated, not everyone has a Gmail or Riseup address, and it's easy to crawl. HTTPS is prob...BridgeDB currently has three bridge distribution mechanisms: Email, HTTPS, and moat. Email is problematic because its interaction mechanism is complicated, not everyone has a Gmail or Riseup address, and it's easy to crawl. HTTPS is problematic because bridges.torproject.org is blocked in most places that matter and our CAPTCHA is good at keeping out users (legacy/trac#29695) but not so good at keeping out bots (legacy/trac#31252). Moat remains relatively useful because it uses domain fronting but it also relies on a CAPTCHA to fight off bots.
It's time to think about new and/or significantly improved bridge distribution methods. How can we get bridges into the hands of users while making it difficult for adversaries to get them all? How can we make BridgeDB's CAPTCHA more resistant against bots and easier for users?
The Salmon bridge distribution system (first presented in a [PETS'16 paper](https://censorbib.nymity.ch/#Douglas2016a)) is promising. Let's use this issue to build a prototype and fill in the missing pieces to get Salmon deployed.Sponsor 30 - Objective 2.3Philipp Winterphw@torproject.orgPhilipp Winterphw@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/31873Implement the Salmon bridge distribution mechanism2020-09-02T17:52:43ZPhilipp Winterphw@torproject.orgImplement the Salmon bridge distribution mechanismBridgeDB currently has three bridge distribution mechanisms: Email, HTTPS, and moat. Email is problematic because its interaction mechanism is complicated, not everyone has a Gmail or Riseup address, and it's easy to crawl. HTTPS is prob...BridgeDB currently has three bridge distribution mechanisms: Email, HTTPS, and moat. Email is problematic because its interaction mechanism is complicated, not everyone has a Gmail or Riseup address, and it's easy to crawl. HTTPS is problematic because bridges.torproject.org is blocked in most places that matter and our CAPTCHA is good at keeping out users (legacy/trac#29695) but not so good at keeping out bots (legacy/trac#31252). Moat remains relatively useful because it uses domain fronting but it also relies on a CAPTCHA to fight off bots.
It's time to think about new and/or significantly improved bridge distribution methods. How can we get bridges into the hands of users while making it difficult for adversaries to get them all? How can we make BridgeDB's CAPTCHA more resistant against bots and easier for users?
The Salmon bridge distribution system (first presented in a [PETS'16 paper](https://censorbib.nymity.ch/#Douglas2016a)) is promising. Let's use this issue to build a prototype and fill in the missing pieces to get Salmon deployed.Sponsor 30 - Objective 2.3Philipp Winterphw@torproject.orgPhilipp Winterphw@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/31871Identify what bridge selection and distribution methods are most used in tar...2020-10-16T22:24:45ZPhilipp Winterphw@torproject.orgIdentify what bridge selection and distribution methods are most used in targeted regionsAs part of a sponsor 30 deliverable, we need to understand what bridge distribution methods are most used in a given region. We should take several weeks worth of BridgeDB usage metrics, analyse them, and write up a report.As part of a sponsor 30 deliverable, we need to understand what bridge distribution methods are most used in a given region. We should take several weeks worth of BridgeDB usage metrics, analyse them, and write up a report.Sponsor 30 - Objective 2.1Philipp Winterphw@torproject.orgPhilipp Winterphw@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/31847Expand contribution guidelines for snowflake2022-03-01T15:55:52ZCecylia BocovichExpand contribution guidelines for snowflakeWe're getting more contributors to the project, we should expand CONTRIBUTING.md with some more basic guidelines like
- formatting of commit messages
- creating tickets for each pull request
- make sure the changes in the commit adhere t...We're getting more contributors to the project, we should expand CONTRIBUTING.md with some more basic guidelines like
- formatting of commit messages
- creating tickets for each pull request
- make sure the changes in the commit adhere to the commit message and the corresponding tickethttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/31843Make safelogger thread safe2020-06-27T13:40:20ZCecylia BocovichMake safelogger thread safeIt would be nice to pass the output of the safe logger to libraries so that we can log errors that occur in library functions. Right now the safelogger is not thread safe. Multiple calls to Write from different threads results in race co...It would be nice to pass the output of the safe logger to libraries so that we can log errors that occur in library functions. Right now the safelogger is not thread safe. Multiple calls to Write from different threads results in race conditions.Cecylia BocovichCecylia Bocovichhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/31818Hello, today after about two hours, I can't open any webpage in Tor browser t...2023-08-01T23:58:38ZTracHello, today after about two hours, I can't open any webpage in Tor browser through Snowflake bridge.Hello, today after about two hours, I can't open any webpage in Tor browser through Snowflake bridge. Today, at first, I can normally open webpages in Tor browser through Snowflake bridge. After about two hours, I can't open any webpage ...Hello, today after about two hours, I can't open any webpage in Tor browser through Snowflake bridge. Today, at first, I can normally open webpages in Tor browser through Snowflake bridge. After about two hours, I can't open any webpage in Tor browser through Snowflake bridge. I don't know whether China's firewall can detect the Snowflake bridge that I use. I upload my state file and my torrc file. Thank you very much for your help. I really appreciate it.
**Trac**:
**Username**: amiableclarity2011