Anti-censorship issueshttps://gitlab.torproject.org/groups/tpo/anti-censorship/-/issues2022-04-06T05:00:23Zhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40091Set up a Snowflake bridge staging server2022-04-06T05:00:23ZDavid Fifielddcf@torproject.orgSet up a Snowflake bridge staging serverThe goals of this issue are:
1. Share practical experience setting up a snowflake bridge.
2. Write a [Snowflake Bridge Installation Guide](https://gitlab.torproject.org/tpo/anti-censorship/team/-/wikis/Survival-Guides/Snowflake-Bridge-I...The goals of this issue are:
1. Share practical experience setting up a snowflake bridge.
2. Write a [Snowflake Bridge Installation Guide](https://gitlab.torproject.org/tpo/anti-censorship/team/-/wikis/Survival-Guides/Snowflake-Bridge-Installation-Guide), like the existing [Snowflake Broker Installation Guide](https://gitlab.torproject.org/tpo/anti-censorship/team/-/wikis/Survival-Guides/Snowflake-Broker-Installation-Guide).
3. Install an [experimental load balancing configuration](https://lists.torproject.org/pipermail/tor-relays/2022-January/020183.html) in an attempt to increase the capacity of the bridge.
If the load balancing configuration works, we can then apply it to the production bridge. (Or change DNS so as to swap production and staging.)
We talked about scaling the snowflake bridge and load balancing ideas at the [2022-01-06 team meeting](http://meetbot.debian.net/tor-meeting/2022/tor-meeting.2022-01-06-15.59.html).
<details>
<summary>Meeting notes</summary>
* Scaling Snowflake bridge
* Already increased from 4 to 8 CPUs
* https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40085
* We should profile snowflake-server to reduce its CPU use
* https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40086
* But dcf feels that the bottleneck is not the snowflake-server process (which is multithreaded and can use multiple CPU cores), but the tor process (which can only use 1 CPU core and is already constantly at 100%). See https://lists.torproject.org/pipermail/tor-relays/2021-December/020156.html
* It turns out that it is possible to run multiple instances of tor with the same identity keys (hence the same fingerprint), either on the same host or on different hosts: https://lists.torproject.org/pipermail/tor-relays/2021-December/020157.html. Multiple instances of tor is a way of scaling tor beyond 1 CPU core, with snowflake-server distributing traffic over the available instances: https://lists.torproject.org/pipermail/tor-relays/2021-December/020182.html
* With another shim (similar to moat-shim) you can keep ExtORPort metrics reporting in the load-balanced configuration:
* https://gitlab.torproject.org/dcf/extor-static-cookie
* https://lists.torproject.org/pipermail/tor-relays/2022-January/020183.html
* Though I'm not sure, if Metrics gets multiple descriptors per day with the same fingerprint, whether it will sum all of them, or only keep one of them
* dcf has a bridge running now (with obfs4proxy, not snowflake-server) with this extor-static-cookie + load balancing configuration
* https://metrics.torproject.org/rs.html#details/07B9C6D7BE9685E83FA8C7A4FEB34CAD6CB77503
* Though I have not tested Roger's caveat about DEFAULT_ONION_KEY_LIFETIME_DAYS yet https://lists.torproject.org/pipermail/tor-relays/2022-January/020196.html
* We could apply this same thing to the snowflake bridge. But it is kind of a big configuration change: we need to stop snowflake-server being managed by tor, and instead run it independently (i.e., using runit or systemd) and have it talk to the tor instances' static ExtORPorts through a load balancer. It would be best to do this on a staging server separate from production first.
* we tentatively plan to do this next tuesday, 2022-01-11. dcf will be in touch and have a host ready for installation.
* Once the tor bottleneck is removed, though, we are not too far from the next likely bottleneck, which is total CPU of the host, shared between tor and snowflake-server. It might be time to think about migrating to different hosting for the snowflake bridge. Or we can experiment with running snowflake-server on one host, and N instances of tor on another (preferably nearby) host.
</details>Sponsor 96: Rapid Expansion of Access to the Uncensored Internet through Tor in China, Hong Kong, & TibetDavid Fifielddcf@torproject.orgDavid Fifielddcf@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40089Possibly malicious snowflake polls?2022-02-21T14:35:42ZCecylia BocovichPossibly malicious snowflake polls?I just took a look at the exported prometheus metrics: https://snowflake-broker.torproject.net/prometheus
and saw a bunch of very unusual snowflake proxy types:
```
snowflake_rounded_proxy_poll_total{nat="restricted'\"\\(",status="idle"...I just took a look at the exported prometheus metrics: https://snowflake-broker.torproject.net/prometheus
and saw a bunch of very unusual snowflake proxy types:
```
snowflake_rounded_proxy_poll_total{nat="restricted'\"\\(",status="idle"} 8
snowflake_rounded_proxy_poll_total{nat="restricted'/**/and(select'1'from/**/pg_sleep(0))>'0",status="matched"} 8
snowflake_rounded_proxy_poll_total{nat="restricted'/**/and(select'1'from/**/pg_sleep(18))>'0",status="idle"} 8
snowflake_rounded_proxy_poll_total{nat="restricted'/**/and/**/DBMS_PIPE.RECEIVE_MESSAGE('p',18)='p",status="idle"} 8
snowflake_rounded_proxy_poll_total{nat="restricted'/**/and/**/DBMS_PIPE.RECEIVE_MESSAGE('q',0)='q",status="idle"} 8
snowflake_rounded_proxy_poll_total{nat="restricted'and(select'1'from/**/cast(md5(1634804485)as/**/int))>'0",status="idle"} 8
snowflake_rounded_proxy_poll_total{nat="restricted'and(select*from(select+sleep(0))a/**/union/**/select+1)='",status="matched"} 8
snowflake_rounded_proxy_poll_total{nat="restricted'and(select*from(select+sleep(18))a/**/union/**/select+1)='",status="matched"} 8
snowflake_rounded_proxy_poll_total{nat="restricted'and(select+1)>0waitfor/**/delay'0:0:0",status="idle"} 8
snowflake_rounded_proxy_poll_total{nat="restricted'and(select+1)>0waitfor/**/delay'0:0:18",status="idle"} 8
snowflake_rounded_proxy_poll_total{nat="restricted'and/**/convert(int,sys.fn_sqlvarbasetostr(HashBytes('MD5','1720393988')))>'0",status="idle"} 8
snowflake_rounded_proxy_poll_total{nat="restricted'and/**/extractvalue(1,concat(char(126),md5(1199007671)))and'",status="matched"} 8
snowflake_rounded_proxy_poll_total{nat="restricted/**/and/**/cast(md5('1204196037')as/**/int)>0",status="idle"} 8
snowflake_rounded_proxy_poll_total{nat="restricted|expr 809667990 + 908363838 ",status="matched"} 8
snowflake_rounded_proxy_poll_total{nat="restricted鎈'\"\\(",status="matched"} 8
snowflake_rounded_proxy_poll_total{nat="unknown",status="idle"} 2.9086904e+07
snowflake_rounded_proxy_poll_total{nat="unknown",status="matched"} 2.757224e+06
snowflake_rounded_proxy_poll_total{nat="unknown\nexpr 965825977 + 974216935\n",status="idle"} 8
snowflake_rounded_proxy_poll_total{nat="unknown\"and(select*from(select+sleep(0))a/**/union/**/select+1)=\"",status="idle"} 8
snowflake_rounded_proxy_poll_total{nat="unknown\"and(select*from(select+sleep(14))a/**/union/**/select+1)=\"",status="matched"} 8
snowflake_rounded_proxy_poll_total{nat="unknown\"and/**/extractvalue(1,concat(char(126),md5(1145896139)))and\"",status="idle"} 8
snowflake_rounded_proxy_poll_total{nat="unknown$(expr 898219840 + 955106000)",status="matched"} 8
snowflake_rounded_proxy_poll_total{nat="unknown&set /A 859877269+929132787",status="idle"} 8
snowflake_rounded_proxy_poll_total{nat="unknown'\"\\(",status="matched"} 8
snowflake_rounded_proxy_poll_total{nat="unknown'/**/and(select'1'from/**/pg_sleep(0))>'0",status="matched"} 8
snowflake_rounded_proxy_poll_total{nat="unknown'/**/and(select'1'from/**/pg_sleep(14))>'0",status="matched"} 8
snowflake_rounded_proxy_poll_total{nat="unknown'/**/and/**/DBMS_PIPE.RECEIVE_MESSAGE('f',0)='f",status="matched"} 8
snowflake_rounded_proxy_poll_total{nat="unknown'/**/and/**/DBMS_PIPE.RECEIVE_MESSAGE('u',14)='u",status="matched"} 8
snowflake_rounded_proxy_poll_total{nat="unknown'and(select'1'from/**/cast(md5(1946869959)as/**/int))>'0",status="matched"} 8
snowflake_rounded_proxy_poll_total{nat="unknown'and(select*from(select+sleep(0))a/**/union/**/select+1)='",status="idle"} 8
snowflake_rounded_proxy_poll_total{nat="unknown'and(select*from(select+sleep(14))a/**/union/**/select+1)='",status="matched"} 8
snowflake_rounded_proxy_poll_total{nat="unknown'and(select+1)>0waitfor/**/delay'0:0:0",status="matched"} 8
snowflake_rounded_proxy_poll_total{nat="unknown'and(select+1)>0waitfor/**/delay'0:0:14",status="matched"} 8
snowflake_rounded_proxy_poll_total{nat="unknown'and/**/convert(int,sys.fn_sqlvarbasetostr(HashBytes('MD5','1587856848')))>'0",status="matched"} 8
snowflake_rounded_proxy_poll_total{nat="unknown'and/**/extractvalue(1,concat(char(126),md5(1875029567)))and'",status="idle"} 8
snowflake_rounded_proxy_poll_total{nat="unknown/**/and/**/cast(md5('1500206875')as/**/int)>0",status="matched"} 8
snowflake_rounded_proxy_poll_total{nat="unknown|expr 881080391 + 963149055 ",status="matched"} 8
snowflake_rounded_proxy_poll_total{nat="unknown鎈'\"\\(",status="matched"} 8
snowflake_rounded_proxy_poll_total{nat="unrestricted",status="idle"} 1.801232e+06
snowflake_rounded_proxy_poll_total{nat="unrestricted",status="matched"} 7.7092e+06
```
I'm keeping this confidential for now in case this is a security vulnerability being actively exploited.Sponsor 96: Rapid Expansion of Access to the Uncensored Internet through Tor in China, Hong Kong, & TibetCecylia BocovichCecylia Bocovichhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40088Snowflake server keeps failing unexpectedly2022-07-09T04:20:46ZCecylia BocovichSnowflake server keeps failing unexpectedlyThe snowflake server has failed twice now in the last two weeks.
[After the first failure](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40060#note_2767868), we upgraded the capacity of the Sn...The snowflake server has failed twice now in the last two weeks.
[After the first failure](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40060#note_2767868), we upgraded the capacity of the Snowflake bridge (#40085).
Today when it failed we received an alert from monit: https://lists.torproject.org/pipermail/anti-censorship-alerts/2021-December/000786.html
Unfortunately, in my rush to fix it I didn't check the CPU usage :/ let's use this ticket to track the issue and note what we notice the next time it occurs.Sponsor 96: Rapid Expansion of Access to the Uncensored Internet through Tor in China, Hong Kong, & Tibetshelikhooshelikhoohttps://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/79Use rotating time periods for when each bridge is available for distribution2022-03-24T10:30:02Zmeskiomeskio@torproject.orgUse rotating time periods for when each bridge is available for distributionFrom https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/12#note_2738534:
> I think the original idea was different in that *no matter how many email addresses or subnets you have*, you still can't learn the bridges we gave...From https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/12#note_2738534:
> I think the original idea was different in that *no matter how many email addresses or subnets you have*, you still can't learn the bridges we gave out yesterday. That is, the idea was to release a small subset of the total bridge population, and then divide that subset according to the resource-you're-proving constraint.
>
> It could be that this design only works well with a large enough bridge population. For example, let's say we take only 5% of our bridges to give out at a time, and we give them out for a 6 hour interval before moving to the next subset. Then it's 5 days before we get around to offering them again. Those numbers prove the concept ("when you show up and decide to start blocking, people still get several days of use out of the bridges they already have") but they aren't as exciting as an example with an even larger period. If we rotate each 24 hours, then we get a much bigger period of 20 days. And if there's some level of churn in that period, then we're also giving out our fresh bridges in a way that's spread-out into the future, forcing the attacker to sustain the attack (this aspect would work better if the rotation period was more like every hour, so you really do have to hit us every hour or you miss a whole batch).
>
> This general principle is part of what makes Salmon appealing too: "give out bridges to a group of people and then stop giving them out \[for a long while\] after that".
>
> If we want to mess around with variations on our bridge distribution strategies in order to get more intuition, that sounds great. If we want to wait and "do it right" with Salmon, so long as we know that the first few iterations won't actually be right and we'll be doing that to gain more intuition ;), that sounds great too.
We might want to use that for the telegram bot #77.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/bridgedb/-/issues/40036get back the country blocking mechanims2022-05-12T16:38:59Zmeskiomeskio@torproject.orgget back the country blocking mechanimsIt was remove by the move to rdsys and is useful to block bridges by country:
https://gitlab.torproject.org/meskio/bridgedb/-/commit/6eac9c00b0809a3277ce6abe019514be17b0cf13It was remove by the move to rdsys and is useful to block bridges by country:
https://gitlab.torproject.org/meskio/bridgedb/-/commit/6eac9c00b0809a3277ce6abe019514be17b0cf13Sponsor 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/team/-/issues/43distribute bridges over telegram2021-12-10T21:25:53Zmeskiomeskio@torproject.orgdistribute bridges over telegramCreate a telegram bot to distribute bridges, as this mechanism might work for rusia or china for now.Create a telegram bot to distribute bridges, as this mechanism might work for rusia or china for now.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/rdsys/-/issues/76ignore bridges with non-public IP addresses2021-12-15T19:14:17Zmeskiomeskio@torproject.orgignore bridges with non-public IP addressesrdsys is accepting and propagating to the distributors bridges with local IP addresses, it should discard them.rdsys is accepting and propagating to the distributors bridges with local IP addresses, it should discard them.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/bridgedb/-/issues/40035no bridges showing up after rdsys change2021-12-02T14:30:33Zmeskiomeskio@torproject.orgno bridges showing up after rdsys changeAfter we merged the rdsys support (!23), no bridges are provided by any distributor. It looks like the code I was testing is not actually the one we merged it.
I see the bridges are included into the hashring of each distributor, but wh...After we merged the rdsys support (!23), no bridges are provided by any distributor. It looks like the code I was testing is not actually the one we merged it.
I see the bridges are included into the hashring of each distributor, but when I ask for a bridge I get a response saying that there are no bridges.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/docker-snowflake-proxy/-/issues/4docker image uses ancient snowflake git tag2021-11-29T19:00:59Zguest42069docker image uses ancient snowflake git tagHi.
I was creating a Containerfile for podman (basically exactly the same as a Dockerfile) and managed to walk into a bit of an issue, the default version in the Dockerfile itself is `v1.1.0`.
This resulted in my attempt to use a seemi...Hi.
I was creating a Containerfile for podman (basically exactly the same as a Dockerfile) and managed to walk into a bit of an issue, the default version in the Dockerfile itself is `v1.1.0`.
This resulted in my attempt to use a seemingly now defunct broker.
Would it be worthwhile keeping the `ARG VERSION=v1.1.0` up to date with the latest version, or as `main` to pull the up-to-date development branch to avoid confused people like me? At the moment the default built image seems to fail.
Thanks.Sponsor 96: Rapid Expansion of Access to the Uncensored Internet through Tor in China, Hong Kong, & Tibethttps://gitlab.torproject.org/tpo/anti-censorship/docker-obfs4-bridge/-/issues/6Unable to find IPv42021-12-09T22:02:07ZMelroy van den BergUnable to find IPv4Sorry it's me again ... So everything starts fine now. The service listing on my Tor port and obfs4 service also started succesfully.
But I see the following notice in my log output:
```
[notice] Unable to find IPv4 address for ORPort ...Sorry it's me again ... So everything starts fine now. The service listing on my Tor port and obfs4 service also started succesfully.
But I see the following notice in my log output:
```
[notice] Unable to find IPv4 address for ORPort 9001. You might want to specify IPv6Only to it or set an explicit address or set Address.
```
Should I ignore this message? Docker is using `0.0.0.0` anyway as the local IP address. Or is obfs4 complaining about my external IP address?
Full log:
```
Nov 22 15:42:21.146 [notice] Opening OR listener on 0.0.0.0:9001
Nov 22 15:42:21.146 [notice] Opened OR listener connection (ready) on 0.0.0.0:9001
Nov 22 15:42:21.146 [notice] Opening OR listener on [::]:9001
Nov 22 15:42:21.146 [notice] Opened OR listener connection (ready) on [::]:9001
Nov 22 15:42:21.146 [notice] Opening Extended OR listener on 127.0.0.1:0
Nov 22 15:42:21.146 [notice] Extended OR listener listening on port 43765.
Nov 22 15:42:21.146 [notice] Opened Extended OR listener connection (ready) on 127.0.0.1:43765
Nov 22 15:42:21.000 [notice] Parsing GEOIP IPv4 file /usr/share/tor/geoip.
Nov 22 15:42:21.000 [notice] Parsing GEOIP IPv6 file /usr/share/tor/geoip6.
Nov 22 15:42:21.000 [notice] Configured to measure statistics. Look for the *-stats files that will first be written to the data directory in 24 hours from now.
Nov 22 15:42:21.000 [notice] You are running a new relay. Thanks for helping the Tor network! If you wish to know what will happen in the upcoming weeks regarding its usage, have a look at https://blog.torproject.org/blog/lifecycle-of-a-new-relay
Nov 22 15:42:21.000 [notice] It looks like I need to generate and sign a new medium-term signing key, because I don't have one. To do that, I need to load (or create) the permanent master identity key. If the master identity key was not moved or encrypted with a passphrase, this will be done automatically and no further action is required. Otherwise, provide the necessary data using 'tor --keygen' to do it manually.
Nov 22 15:42:21.000 [notice] Your Tor server's identity key fingerprint is 'DockerObfs4Bridge secret1'
Nov 22 15:42:21.000 [notice] Your Tor bridge's hashed identity key fingerprint is 'DockerObfs4Bridge secret2'
Nov 22 15:42:21.000 [notice] Your Tor server's identity key ed25519 fingerprint is 'DockerObfs4Bridge secret3'
Nov 22 15:42:21.000 [notice] Bootstrapped 0% (starting): Starting
Nov 22 15:42:21.000 [notice] Starting with guard context "default"
Nov 22 15:42:21.000 [notice] Registered server transport 'obfs4' at '[::]:9010'
Nov 22 15:42:22.000 [notice] Unable to find IPv4 address for ORPort 9001. You might want to specify IPv6Only to it or set an explicit address or set Address.
Nov 22 15:42:22.000 [notice] Bootstrapped 5% (conn): Connecting to a relay
Nov 22 15:42:22.000 [notice] Bootstrapped 10% (conn_done): Connected to a relay
Nov 22 15:42:22.000 [notice] Bootstrapped 14% (handshake): Handshaking with a relay
Nov 22 15:42:22.000 [notice] Bootstrapped 15% (handshake_done): Handshake with a relay done
Nov 22 15:42:22.000 [notice] Bootstrapped 20% (onehop_create): Establishing an encrypted directory connection
Nov 22 15:42:22.000 [notice] Bootstrapped 25% (requesting_status): Asking for networkstatus consensus
Nov 22 15:42:22.000 [notice] Bootstrapped 30% (loading_status): Loading networkstatus consensus
Nov 22 15:42:22.000 [notice] I learned some more directory information, but not enough to build a circuit: We have no usable consensus.
Nov 22 15:42:22.000 [notice] Bootstrapped 40% (loading_keys): Loading authority key certs
Nov 22 15:42:22.000 [notice] The current consensus has no exit nodes. Tor can only build internal paths, such as paths to onion services.
Nov 22 15:42:22.000 [notice] Bootstrapped 45% (requesting_descriptors): Asking for relay descriptors
Nov 22 15:42:22.000 [notice] I learned some more directory information, but not enough to build a circuit: We need more microdescriptors: we have 0/6278, and can only build 0% of likely paths. (We have 0% of guards bw, 0% of midpoint bw, and 0% of end bw (no exits in consensus, using mid) = 0% of path bw.)
Nov 22 15:42:22.000 [notice] Bootstrapped 50% (loading_descriptors): Loading relay descriptors
Nov 22 15:42:23.000 [notice] The current consensus contains exit nodes. Tor can build exit and internal paths.
Nov 22 15:42:23.000 [notice] I learned some more directory information, but not enough to build a circuit: We need more microdescriptors: we have 1000/6278, and can only build 0% of likely paths. (We have 13% of guards bw, 14% of midpoint bw, and 15% of exit bw = 0% of path bw.)
Nov 22 15:42:25.000 [notice] Bootstrapped 56% (loading_descriptors): Loading relay descriptors
Nov 22 15:42:25.000 [notice] Bootstrapped 64% (loading_descriptors): Loading relay descriptors
Nov 22 15:42:25.000 [notice] Bootstrapped 69% (loading_descriptors): Loading relay descriptors
Nov 22 15:42:25.000 [notice] Bootstrapped 75% (enough_dirinfo): Loaded enough directory info to build circuits
Nov 22 15:42:26.000 [notice] Bootstrapped 80% (ap_conn): Connecting to a relay to build circuits
Nov 22 15:42:26.000 [notice] Bootstrapped 85% (ap_conn_done): Connected to a relay to build circuits
Nov 22 15:42:26.000 [notice] Bootstrapped 89% (ap_handshake): Finishing handshake with a relay to build circuits
Nov 22 15:42:27.000 [notice] Bootstrapped 90% (ap_handshake_done): Handshake finished with a relay to build circuits
Nov 22 15:42:27.000 [notice] Bootstrapped 95% (circuit_create): Establishing a Tor circuit
Nov 22 15:42:29.000 [notice] Bootstrapped 100% (done): Done
```Sponsor 96: Rapid Expansion of Access to the Uncensored Internet through Tor in China, Hong Kong, & Tibethttps://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/69Do we want to take into account the requester IP address?2022-06-21T09:56:13Zmeskiomeskio@torproject.orgDo we want to take into account the requester IP address?AFAIK the existing BridgeDB https and moat distributors do take into account the requester IP address, it does have bridgerings for different IP ranges so we only provide bridges from that bridgering to that IP range.
While bridgedb is ...AFAIK the existing BridgeDB https and moat distributors do take into account the requester IP address, it does have bridgerings for different IP ranges so we only provide bridges from that bridgering to that IP range.
While bridgedb is being used as distributor of rdsys (#12) this mechanism is going to be still working for the existing https and moat distributors. But our new moat circumvention settings (https://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/40025) will need rdsys to implement this mechanism if we care about it.
It looks like in the real world this protection hasn't stopped big attackers from listing all the bridges, and the effort might not be worth it. So I will say we should just close this issue and forget about distributing bridges by IP.
But I'll like to hear from others with more experience what they think. @cohosh @arma any opinions here?Sponsor 96: Rapid Expansion of Access to the Uncensored Internet through Tor in China, Hong Kong, & Tibethttps://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/67metrics of bridges per distributor and assignments2022-01-21T11:03:25Zmeskiomeskio@torproject.orgmetrics of bridges per distributor and assignmentsAs part of https://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/40031 bridgedb is not having anymore the complete information of distributors and bridges. rdsys is the one having the full picture of assignments and bridged...As part of https://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/40031 bridgedb is not having anymore the complete information of distributors and bridges. rdsys is the one having the full picture of assignments and bridgedb only sees the bridges that are assigned to it.
That means that bridgedb will not be able anymore to produce the [bridgedb-pool-assignments](https://metrics.torproject.org/collector.html#bridge-pool-assignments) and we should produce it from rdsys. Also the [bridgedb-metrics](https://metrics.torproject.org/collector.html#type-bridgedb-metrics) `internal.*.byipv*-bysubring*` metrics will only include the distrubtors run by bridge (moat, email and https) and not the new ones (moat settings or telegram), but I guess this is a bit less important.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/rdsys/-/issues/66expose the stable flag of the bridges2021-11-29T18:47:59Zmeskiomeskio@torproject.orgexpose the stable flag of the bridgesRight now it looks like there is something wrong with the bridge authority and there is no stable flag (https://gitlab.torproject.org/tpo/core/tor/-/issues/40449), but once this work we want the flag available. BridgeDB uses it to priori...Right now it looks like there is something wrong with the bridge authority and there is no stable flag (https://gitlab.torproject.org/tpo/core/tor/-/issues/40449), but once this work we want the flag available. BridgeDB uses it to prioritize the ones with the flag on them.
I guess it will make sense to expose a generic *flags* field in the bridge resource so we can add other flags in the future.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/pluggable-transports/snowflake/-/issues/40066O1.1: Prepare Snowflake to handle a surge of operators and users.2022-09-27T18:43:09ZGabagaba@torproject.orgO1.1: Prepare Snowflake to handle a surge of operators and users.Although we already deployed Snowflake in Tor Browser, we want to be sure that Snowflake can handle all new users from China by preparing it with:
- [x] add many additional Snowflake operators (coordinate with @ggus on campaign),
- [ ]...Although we already deployed Snowflake in Tor Browser, we want to be sure that Snowflake can handle all new users from China by preparing it with:
- [x] add many additional Snowflake operators (coordinate with @ggus on campaign),
- [ ] monitor bottlenecks & blocking events (ongoing task for @tpo/anti-censorship),
- [x] set up at least one more snowflake bridge (1. prepare snowflake to give more than 2 bridge, 2. coordinate with @ggus for when partnering to have more bridges)
- [ ] respond to blocking events and prevent users from getting Snowflakes that have been blocked (ongoing task for @tpo/anti-censorship).Sponsor 96: Rapid Expansion of Access to the Uncensored Internet through Tor in China, Hong Kong, & Tibetshelikhooshelikhoohttps://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/64Create a circumvention map json2022-02-25T16:58:38Zmeskiomeskio@torproject.orgCreate a circumvention map jsonOn a fast look into OONI and the [state-of-censorship.json](https://gitlab.torproject.org/tpo/anti-censorship/state-of-censorship/-/blob/main/state-of-censorship.json) this is what I can come up with:
```json
{
"by": {
"setti...On a fast look into OONI and the [state-of-censorship.json](https://gitlab.torproject.org/tpo/anti-censorship/state-of-censorship/-/blob/main/state-of-censorship.json) this is what I can come up with:
```json
{
"by": {
"settings": [
{"bridges": {"type": "obfs4", "source": "builtin"}},
{"bridges": {"type": "vanilla", "source": "bridgedb"}},
{"bridges": {"type": "obfs4", "source": "bridgedb"}},
{"bridges": {"type": "snowflake", "source": "builtin"}}
]
},
"cn": {
"settings": [
{"bridges": {"type": "snowflake", "source": "builtin"}}
]
},
"tm": {
"settings": [
{"bridges": {"type": "obfs4", "source": "bridgedb"}},
{"bridges": {"type": "snowflake", "source": "builtin"}}
]
},
"ru": {
"settings": [
{"bridges": {"type": "snowflake", "source": "builtin"}},
{"bridges": {"type": "obfs4", "source": "bridgedb"}}
]
}
}
```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/rdsys/-/issues/61Moat deployment for testing2021-10-20T12:13:04Zmeskiomeskio@torproject.orgMoat deployment for testingLets deploy the moat version on development and check that everything works as expected.Lets deploy the moat version on development and check that everything works as expected.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/bridgedb/-/issues/40028Email instructions are unclear to people who type their bridges2022-02-10T15:55:12ZsajolidaEmail instructions are unclear to people who type their bridgesIn August, I did some usability tests of Tails 4.22, which includes our new [Tor Connection](https://tails.boum.org/doc/anonymous_internet/tor/).
Currently, the "simplest" (though really tedious) way of getting custom bridges in Tails i...In August, I did some usability tests of Tails 4.22, which includes our new [Tor Connection](https://tails.boum.org/doc/anonymous_internet/tor/).
Currently, the "simplest" (though really tedious) way of getting custom bridges in Tails is to request bridges over email through their phone and type them in Tails, because we don't have neither [Moat](https://gitlab.tails.boum.org/tails/tails/-/issues/15331) nor [Snowflake](https://gitlab.tails.boum.org/tails/tails/-/issues/5494) yet.
It's really tedious but better than nothing. Some test participants were determined enough to gave it a try but failed nonetheless.
Here is how the email displayed on their phone:
![bridges](/uploads/6beccb2ef2701afd511d193d0aa5ef61/bridges.png)
Some of their pain points could be solved by improving the content of the email:
- It was unclear where to type line breaks, because the long bridge line wrapped many times on their small display and there was no clear separation between the 2 bridges.
I think that it would help to separate both bridges more clearly, with some colored background and headings. Unless I'm mistaken, both Tor Browser and Tails only try to use the 1st bridge in the list, so encouraging people to type or copy only 1 line would not lead to less connectivity.
- Some characters were hard to interpret: I? 1? |?
Using a fixed width font, for example inside a `<pre>` tag, might help people distinguish ambiguous characters.
- A test participant wondered whether the bridges should be typed in Tor Browser in Tails instead of in our Tor Connection assistant, because that's what the email instructed.
We could have different instructions for Tor Browser and Tails.
I understand that making bridges easier to type or improve the email for Tails users might not be a priority for the Tor team. We're also conscious at Tails that providing better alternatives, like scanning the QR code, would be much better for our users. So I'd like you to tell me which of these improvements you would be interested in working on until then.
I could work on the phrasing of the email myself and ask our coders to submit a patch if needed.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/rdsys/-/issues/60create a bridge pool for the cicunvention settings2022-02-21T17:05:31Zmeskiomeskio@torproject.orgcreate a bridge pool for the cicunvention settingsThe circunvention settings will provide bridges without captacha. We need a separated pool of bridges to see how fast are those being blocked.The circunvention settings will provide bridges without captacha. We need a separated pool of bridges to see how fast are those being blocked.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/rdsys/-/issues/59Dummy moat distributor2022-02-28T17:03:47Zmeskiomeskio@torproject.orgDummy moat distributorImplement a dummy moat distributor to distribute the censorship map (bridgedb#40025).
It requires three API endpoints:
* Get Circunvention Map. Provide the static json file with the list of countries.
* Get circunvention settings. Use t...Implement a dummy moat distributor to distribute the censorship map (bridgedb#40025).
It requires three API endpoints:
* Get Circunvention Map. Provide the static json file with the list of countries.
* Get circunvention settings. Use the IP of the client (or a provided param) to return the right settings for the country.
* Get BuiltIn bridges.
As long as #12 is not ready we'll provide dummy bridges in the circunvention map to test that everything works properly.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/pluggable-transports/snowflake/-/issues/40062Snowflake should self-diagnose where it fails in the connection process, and ...2022-04-08T10:56:52ZRoger DingledineSnowflake should self-diagnose where it fails in the connection process, and inform TorWe have periodic reports (e.g. #40044) of people in China saying that Tor Browser + Snowflake gets to 10% bootstrapped and can't get past it. We got another one on irc just now. Our own internal tests show that Snowflake bootstraps succe...We have periodic reports (e.g. #40044) of people in China saying that Tor Browser + Snowflake gets to 10% bootstrapped and can't get past it. We got another one on irc just now. Our own internal tests show that Snowflake bootstraps successfully on the VPS we're trying it from, but clearly that's not the end of the story. For example, I bet the mobile carriers have different constraints.
I was first thinking to suggest some standalone Snowflake debugging tool that would try a bunch of things and see how they go and summarize it for the user.
But then I realized: Snowflake itself should do this, because it *does* try things, and it learns how they go, and our users already have it. So all that remains is (a) figuring out which conclusions are worth escalating to the user, possibly including some refactoring inside Snowflake to do the steps in a way where we're confident in our results, and then (b) deciding what the right pathway is for escalating the information.
For 'b', we should be careful to avoid getting bogged down picking between options, since there are plenty of approaches that will do adequately. Maybe the PT log command is useful here, and (if I understand it correctly) in that case the way users can see the output is by preferences->tor->view logs.
And then I imagine the bulk of the work will be in step 'a'.
To get us started: what is the taxonomy of ways that Snowflake can fail to make its connection? And for each of those ways, is there an obvious point where Snowflake can self-assess that it has failed?Sponsor 96: Rapid Expansion of Access to the Uncensored Internet through Tor in China, Hong Kong, & Tibet