Anti-censorship issueshttps://gitlab.torproject.org/groups/tpo/anti-censorship/-/issues2022-06-27T19:16:28Zhttps://gitlab.torproject.org/tpo/anti-censorship/bridgestrap/-/issues/28Control the number of bridges included in each test2022-06-27T19:16:28ZCecylia BocovichControl the number of bridges included in each testWe have the following line to limit the number of bridges requested for each test:
```
// The maximum amount of bridges per batch.
MaxBridgesPerReq = 100
```
but, each test batches together all of the bridges in a request. This...We have the following line to limit the number of bridges requested for each test:
```
// The maximum amount of bridges per batch.
MaxBridgesPerReq = 100
```
but, each test batches together all of the bridges in a request. This means that if a user actually requests to test 50 or 100 bridges, we include 50-100 bridges in the `SETCONF` line sent to tor.
It would be nice to be able to queue up bridges and control how many are sent to tor at a time. This might help with the issues we're seeing in #27 and the issues previously reported in #7.https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40071Increase of "unknown" NAT assignments by probetest since 2021-10-252023-06-20T18:24:54ZDavid Fifielddcf@torproject.orgIncrease of "unknown" NAT assignments by probetest since 2021-10-25https://lists.torproject.org/pipermail/anti-censorship-team/2021-October/000197.html
> ...looking into the broker graphs there is something weird since 2 days. The number of proxies with 'unknown' type of nat has rised heavily at the sam...https://lists.torproject.org/pipermail/anti-censorship-team/2021-October/000197.html
> ...looking into the broker graphs there is something weird since 2 days. The number of proxies with 'unknown' type of nat has rised heavily at the same time the 'restricted' nat has gone down. There are long periods without idle proxies and many requests being denied of nat type uknown. It doesn't look like the proxy capacity has gone down, can it be something broken on the way we test the nat type?
It seems that something is going wrong with probetest. A past problem we had with probetest not functioning properly was #40039. Currently the probetest process is again using 100% CPU.
It is possible this is some kind of slow resource exhaustion, or it's possible that probetest is simply overloaded with the number of proxies we have currently. At the [2021-10-28 anti-censorship team meeting](http://meetbot.debian.net/tor-meeting/2021/tor-meeting.2021-10-28-16.00.log.html#l-51) we decided to restart probetest and watch it to see how quickly it returns to its failure state, in order to distinguish these two possibilities.shelikhooshelikhoohttps://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/65Design a State Persistence Framework2024-02-27T19:01:28ZshelikhooDesign a State Persistence FrameworkCurrently, there are two modes of data persistence implemented in rdsys. Gob based persistence, and JSON based persistence. In either case, a full dump of a certain type will be generated and a file on the system will be truncated and wr...Currently, there are two modes of data persistence implemented in rdsys. Gob based persistence, and JSON based persistence. In either case, a full dump of a certain type will be generated and a file on the system will be truncated and written in place whenever a resource is modified.
The current design of this system has the following issues:
* If there are concurrent connections, a file may be corrupted by being written by competing writes.
* If the process is killed after a truncated and before the write is complete, the save may be corrupted.
* If there is a significant amount of resources, the dumping process can be slow and result in a bottleneck. Additionally, a significant amount of write instructions may reduce SSD lifespan.
* There is no way to detect if a corrupted file is loaded. A human-readable format like JSON can load the corrupted file when there is an insertion, replacement, or deletion in the data field. A non-human-readable format may also load a file if there is a replacement in the data field.
Possible Ways of Improvements
* File system based
* Creating a Multiversion concurrency control: Writing to a different file each time by generating the filename based on the timestamp
* ```[+]``` Reduce overwrite in place
* ```[+]``` Do not require changes to the current file-based approach for state persistence
* ```[-]``` Additional complexity: requires clean up
* Adding Checksum to file/filename
* ```[+]``` Detects corrupted files
* ```[-]``` Additional complexity
* ```[-]``` Additional computation cost
* Database based(Tree-based Key-Value database)
* ```[+]``` Outsources database design complexity
* ```[+]``` Allows live migration/scaling of application
* ```[-]``` Require changes to the design of application: resources should ideally be stored and retrieved from the database individually, instead of a dump of all states as a binary.
* ```[-]``` Some indexing may need to be completed manually
* ```[-]``` Additionally external dependency: deployment will become more complexhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40077Add three NAT type buckets to the snowflake broker2024-03-21T20:25:26ZCecylia BocovichAdd three NAT type buckets to the snowflake brokerAt the moment we use two buckets for NATs, labelled "restricted" and "unrestricted". See the wiki for more information on this: https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/wikis/NAT-matching
There'...At the moment we use two buckets for NATs, labelled "restricted" and "unrestricted". See the wiki for more information on this: https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/wikis/NAT-matching
There's an edge case that clients with a port-restricted NAT pull proxies from the "restricted NAT" bucket, but aren't compatible with symmetric NATs (see the table in the documentation). We allowed this edge case to exist after testing snowflake with port-restriced NATs and having good performance and compatibility with > 80% of proxies. However, the increase of mobile phone proxies and the exhaustion of IPv4 might change that.
Let's add a third NAT bucket (and also redo our naming scheme because it's confusing at the moment). How about the following:
We can define the following three NAT types (inspiration taken from the Xbox naming scheme):
- `open`: no NAT, full cone NAT, restricted cone NAT
- `moderate`: port-restricted cone NAT
- `strict`: symmetric NAT
Then, clients will report their NAT type, and the matching algorithm/pseudocode will be as follows:
```go
switch NATType {
case NATOpen:
// can be matched with any NAT type, try to match with proxies with the most aggressive NATs first
var snowflakeHeap *SnowflakeHeap
if len(strictHeap) > 0 {
snowflakeHeap = strictHeap
else if len(moderateHeap) > 0 {
snowflakeHeap = moderateHeap
} else if len(openHeap) > 0 {
snowflakeHeap = openHeap
} else {
// there are no snowflake available
}
snowflake := heap.Pop(snowflakeHeap)
case NATModerate:
// can be matched with open or moderate NATs, try to match with proxies with the most aggressive NATs first
var snowflakeHeap *SnowflakeHeap
if len(moderateHeap) > 0 {
snowflakeHeap = moderateHeap
} else if len(openHeap) > 0 {
snowflakeHeap = openHeap
} else {
// there are no snowflake available
return
}
snowflake := heap.Pop(snowflakeHeap)
case NATStrict:
// can only be matched with open NATs
if len(openHeap) > 0 {
snowflakeHeap = openHeap
} else {
// there are no snowflake available
return
}
snowflake := heap.Pop(snowflakeHeap)
}
```
We'll have to update our metrics (CollecTor and prometheus) as well.https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/72Some bridges don't have a valid status page2024-03-06T16:41:13ZCecylia BocovichSome bridges don't have a valid status page@gk found a bridge that doesn't have a valid status page, but it does show up in the extra info files that rdsys is using.
Relay search page: https://metrics.torproject.org/rs.html#details/47D7B70C2E411A941348AF2132D41BC4554FDD25
bridg...@gk found a bridge that doesn't have a valid status page, but it does show up in the extra info files that rdsys is using.
Relay search page: https://metrics.torproject.org/rs.html#details/47D7B70C2E411A941348AF2132D41BC4554FDD25
bridgestrap status page: https://bridges.torproject.org/status?id=47D7B70C2E411A941348AF2132D41BC4554FDD25
I've verified the bridge is in the extrainfo file. So rdsys seems to be throwing it out for some reason? If the bridge doesn't work, it should show up as dysfunctional but still be saved as a valid resource.meskiomeskio@torproject.orgmeskiomeskio@torproject.org2024-07-31https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/40IPv6 for obfs4 bridges2023-11-16T20:18:10Zmeskiomeskio@torproject.orgIPv6 for obfs4 bridgesIn the [last weekly meeting](http://meetbot.debian.net/tor-meeting/2021/tor-meeting.2021-11-18-15.59.html) there was a conversation on how many censors bloc only IPv4 traffic and using IPv6 might be useful for circumvention. But currentl...In the [last weekly meeting](http://meetbot.debian.net/tor-meeting/2021/tor-meeting.2021-11-18-15.59.html) there was a conversation on how many censors bloc only IPv4 traffic and using IPv6 might be useful for circumvention. But currently we only have IPv6 for vanilla bridges and not for obfs4 ones.
The bridge authority `cached-extrainfo` files contain the IPv4 address of the obfs4 transport but no IPv6, while `bridge-descriptors` and `networkstatus-bridges` does include both IPv4 and IPv6 addresses for the vanilla bridge. The problem comes from tor not allowing to have multiple lines in the TransportListenAddr (https://gitlab.torproject.org/tpo/core/tor/-/issues/11211) so only the IPv4 is specified. But in practice binding to 0.0.0.0 implies also binding into IPv6 (https://gitlab.torproject.org/tpo/core/tor/-/issues/12138#note_2762221), so we could assume any bridge that has an IPv6 address in bridge-descriptors might have a working obfs4 on the IPv6 and same port that is published for IPv4.
How do want to move forward to use IPv6 obfs4 bridges?https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/73use the vanilla IPv6 address for the obfs42023-11-16T20:18:10Zmeskiomeskio@torproject.orguse the vanilla IPv6 address for the obfs4Use the IPv6 *or-address* of bridges in the transport after testing that it works with bridgestrap.Use the IPv6 *or-address* of bridges in the transport after testing that it works with bridgestrap.https://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/40033The repo gets out of sync between gitlab and git-rw2022-03-01T17:35:41Zmeskiomeskio@torproject.orgThe repo gets out of sync between gitlab and git-rwThis repo lives in two places git-rw.tpo and gitlab.tpo. But unlike other projects there is no automatic push, so if you push into git-rw.tpo it doesn't get automatically pushed into gitlab.tpo, so every contributor has to manually push ...This repo lives in two places git-rw.tpo and gitlab.tpo. But unlike other projects there is no automatic push, so if you push into git-rw.tpo it doesn't get automatically pushed into gitlab.tpo, so every contributor has to manually push to two places and to remember to do that. If someone forget about it pushing only to one of the copies and someone else comes and pushes something else to another copy we get out of sync and requires a force push into main that might break the setup on many people.
This has happen a couple of times already in the past few months. Let's see if we can improve our workflow here.
I see two options:
* declare git-rw.tpo to be the source of truth and configure automatic pushes from it to gitlab.tpo. We learn that we should never push code from gitlab.tpo.
* give up on git-rw.tpo and use only gitlab.tpo. We modify the readme in git-rw.tpo indicating the move of the project or directly delete the copy of the code.
Any ideas?meskiomeskio@torproject.orgmeskiomeskio@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/42Proposal: Support for Dynamic IP obfs4 bridges with unattended proxy informat...2024-02-27T19:00:35ZshelikhooProposal: Support for Dynamic IP obfs4 bridges with unattended proxy information update(aka "Subscription")
### Context
Currently, Tor [encourages](https://blog.torproject.org/run-a-bridge-campaign/) obfs4 bridges with a static address. This reduces the interruption to the users as users won't need to request new bridges frequently, which nee...
### Context
Currently, Tor [encourages](https://blog.torproject.org/run-a-bridge-campaign/) obfs4 bridges with a static address. This reduces the interruption to the users as users won't need to request new bridges frequently, which need to be done manually. However, this also allows censors to block bridges by IP, thus resulting in bridges consistently in an inaccessible state for some users.
### Proposal
Support obfs4 bridges with a dynamic IP address by allowing users to perform an unattended update of the bridge IP address. When the user retrieves an obfs4 bridge with a dynamic IP, the user will also receive a ticket. This ticket will then allow the user to receive an updated IP address of that bridge without completing a captcha or any manual interaction. The tor browser will do that on behalf of the user during connecting process. So, the user experience will not be impacted when the bridge operator rotates the IP address.
The operator of the obfs4 bridge can then switch to a new IP when the bridge is blocked. This process can be automated if we have an API to detect blocks.
### Additional Backgrounds
The concept of subscription(unattended proxy information update) is a feature supported by almost all Chinese anti-censorship tools. Here are some relevant discussions & screenshots.
An example of this will be [Shadowsockets SIP008](https://github.com/shadowsocks/shadowsocks-org/issues/89), which is currently supported by [Outline](https://github.com/Jigsaw-Code/outline-client/issues/891) and many other clients like [SagerNet](https://sagernet.org/). (Conflict of Interest Declared)
Here is a screenshot of the configuration screen for a "subscription" in SagerNet.
![unnamed](/uploads/34aa938764f18abff98b6133a46fe8a4/unnamed.jpg)https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake-webext/-/issues/35Add a consent prompt to the snowflake webextension2024-03-28T04:37:35ZCecylia BocovichAdd a consent prompt to the snowflake webextensionThe update to [Mozilla's addon policy](https://blog.mozilla.org/addons/2021/11/03/add-on-policy-changes-2021/) requires that users **opt-in** to the collection of personal information. Since IP addresses are considered personal informati...The update to [Mozilla's addon policy](https://blog.mozilla.org/addons/2021/11/03/add-on-policy-changes-2021/) requires that users **opt-in** to the collection of personal information. Since IP addresses are considered personal information, and the IP address of snowflake proxies are sent to the broker and then to the connecting client, we should reflect this in our privacy policy (#34) and also make sure the user consents to this before enabling the Snowflake addon.https://gitlab.torproject.org/tpo/anti-censorship/docker-obfs4-bridge/-/issues/7Cannot assign IPv6 Address2022-03-18T16:05:46ZEngel TorCannot assign IPv6 AddressAfter hours of troubleshooting trying to get IPv6 to work, I'm here asking for help:
I currently host 1 native installation on a VPS with a 2nd Docker instance. The native installation has IPv6 connectivity, the docker instance doesn't....After hours of troubleshooting trying to get IPv6 to work, I'm here asking for help:
I currently host 1 native installation on a VPS with a 2nd Docker instance. The native installation has IPv6 connectivity, the docker instance doesn't. I didn't even have to set the IPv6 Address manually for the native install.
I've enabled IPv6 on my Docker host with the following guide: https://docs.docker.com/config/daemon/ipv6/
I also tried your guide on how to set a static IPv6 Address: https://community.torproject.org/relay/setup/post-install/
Sadly, no matter what port i choose (The same as for IPv4 or a different one) i get the following output when starting the container:
```obfs4-bridge_1 | Using OR_PORT=11112, PT_PORT=11113 and EMAIL=dummyemail.
obfs4-bridge_1 | Starting tor.
obfs4-bridge_1 | Nov 25 21:01:41.767 [notice] Tor 0.4.6.8 running on Linux with Libevent 2.1.12-stable, OpenSSL 1.1.1k, Zlib 1.2.11, Liblzma 5.2.5, Libzstd 1.4.8 and Glibc 2.31 as libc.
obfs4-bridge_1 | Nov 25 21:01:41.768 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
obfs4-bridge_1 | Nov 25 21:01:41.769 [notice] Read configuration file "/etc/tor/torrc".
obfs4-bridge_1 | Nov 25 21:01:41.770 [notice] Based on detected system memory, MaxMemInQueues is set to 1438 MB. You can override this by setting MaxMemInQueues by hand.
obfs4-bridge_1 | Nov 25 21:01:41.772 [notice] Opening OR listener on 0.0.0.0:11112
obfs4-bridge_1 | Nov 25 21:01:41.773 [notice] Opened OR listener connection (ready) on 0.0.0.0:11112
obfs4-bridge_1 | Nov 25 21:01:41.773 [notice] Opening OR listener on [myIPv6Adress]:11114
obfs4-bridge_1 | Nov 25 21:01:41.774 [warn] Could not bind to myIPv6Adress:11114: Cannot assign requested address
obfs4-bridge_1 | Nov 25 21:01:41.774 [notice] Opening OR listener on [::]:11112
obfs4-bridge_1 | Nov 25 21:01:41.775 [notice] Opened OR listener connection (ready) on [::]:11112
obfs4-bridge_1 | Nov 25 21:01:41.775 [notice] Opening Extended OR listener on 127.0.0.1:0
obfs4-bridge_1 | Nov 25 21:01:41.775 [notice] Extended OR listener listening on port 36383.
obfs4-bridge_1 | Nov 25 21:01:41.776 [notice] Opened Extended OR listener connection (ready) on 127.0.0.1:36383
obfs4-bridge_1 | Nov 25 21:01:41.776 [notice] Closing partially-constructed OR listener connection (ready) on 0.0.0.0:11112
obfs4-bridge_1 | Nov 25 21:01:41.777 [notice] Closing partially-constructed OR listener connection (ready) on [::]:11112
obfs4-bridge_1 | Nov 25 21:01:41.777 [notice] Closing partially-constructed Extended OR listener connection (ready) on 127.0.0.1:36383
obfs4-bridge_1 | Nov 25 21:01:41.778 [warn] Failed to parse/validate config: Failed to bind one of the listener ports.
obfs4-bridge_1 | Nov 25 21:01:41.778 [err] Reading config failed--see warnings above.
```
Any ideas would be appreciated :)https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake-webext/-/issues/36Lockscreen, screensaver disabled while a proxy session is active2022-09-28T21:30:47ZpromeneurLockscreen, screensaver disabled while a proxy session is activeopenSUSE 15.3
Chrome 96
snowflake 0.5.4
When someone uses snowflake and uses webrtc protocol
then
my PC lokscreen and screensaver are disabled.
It's normal if I use webrtc but not if someone uses webrtc via snowflake.openSUSE 15.3
Chrome 96
snowflake 0.5.4
When someone uses snowflake and uses webrtc protocol
then
my PC lokscreen and screensaver are disabled.
It's normal if I use webrtc but not if someone uses webrtc via snowflake.https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/45Proposal: Push Notification Based Signaling Channel2022-01-10T18:54:43ZshelikhooProposal: Push Notification Based Signaling ChannelProposal: Push Notification Based Signaling Channel
Modern [Operating Systems](https://developer.apple.com/library/archive/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/APNSOverview.html#//apple_ref/doc/uid/TP40008194...Proposal: Push Notification Based Signaling Channel
Modern [Operating Systems](https://developer.apple.com/library/archive/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/APNSOverview.html#//apple_ref/doc/uid/TP40008194-CH8-SW1) and [Browsers](https://caniuse.com/push-api) support push notifications that can include data in their payload. This provides a uni-directional communication channel from the client to the server if the client does not have a push receiver running, or a bidirectional communication channel if the client has a push receiver running.
As we have seen in recent block [happened](https://gitlab.torproject.org/tpo/community/support/-/issues/40050) in Russia, even with domain fronting, adversaries are able to block fronting domains without significant consequence as in the case of [meek-azure](https://ntc.party/t/ooni-reports-of-tor-blocking-in-certain-isps-since-2021-12-01/1477/3). We might want to diversify our signalling channels to prevent blocking
## Advantages
### Collateral Damage Maximization
These pushing channels have no substitutions and offer a functionality that is observable to users. Once the pushing service is blocked, all apps(with servers hosted in the region) and websites will be influenced.
### Asymmetrical
When WebPush is used, a single codebase that interacts with a browser in a standardized way can be used on all browsers. The adversary will need to block a significant amount of service while we don't need to do anything vendor-specific.
### Plausible Fingerprint
For a push notification sender, it is expected to interact with applications that send requests from a non-browser environment. For push receivers, the proxy software won't interact with push service directly, thus no chance of being recognized for fingerprint.
## Disadvantages
### Special Environment for Receiver
Push notification receiver requires a running operating system or browser. This means it would be difficult to ship it with the client. The message from server to client may need an alternative channel such as to reply with source address forging.
### Special Setup Requirement
iOS-based push notification requires an Apple Developer account. This is not required by Web Push in most cases.https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/46Review UX and suggest improvements for telegram bridge bot2023-03-31T18:51:53ZdonutsReview UX and suggest improvements for telegram bridge botWe have a telegram bridge bot, and it's awesome! However at some point (i.e. when we revisit the bot and potentially integrate it with rdsys in future) UX should review and input into the following:
- The General UX/Design of the bot
- ...We have a telegram bridge bot, and it's awesome! However at some point (i.e. when we revisit the bot and potentially integrate it with rdsys in future) UX should review and input into the following:
- The General UX/Design of the bot
- How to collect user feedback about its use
- How to include (or link to) basic instructions on how to add bridges
- Improving user communication when (re)distributing cached bridges
- Integrating basic help functions/links to support articles
- If we want to localize it, and how this will work from a UI point of viewhttps://gitlab.torproject.org/tpo/anti-censorship/docker-obfs4-bridge/-/issues/9Add Docker health check2022-03-01T17:54:36ZMelroy van den BergAdd Docker health checkYou could add a [HEALTHCHECK](https://docs.docker.com/engine/reference/builder/#healthcheck) to the Docker image.
So it's easy to see if the Bridge is working or not. You can execute any command you want within this HEALTHCHECK stateme...You could add a [HEALTHCHECK](https://docs.docker.com/engine/reference/builder/#healthcheck) to the Docker image.
So it's easy to see if the Bridge is working or not. You can execute any command you want within this HEALTHCHECK statement.
I leave it up to you what exact command you want to run to validate the healthy of the bridge.
Regards,
Melroyhttps://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/78tests for kraken2022-03-01T15:46:33Zmeskiomeskio@torproject.orgtests for krakenLet's migrate the tests from bridgedb with fake bridge descriptors to test kraken.Let's migrate the tests from bridgedb with fake bridge descriptors to test kraken.https://gitlab.torproject.org/tpo/anti-censorship/censorship-analysis/-/issues/40024Blocking of Snowflake in Turkmenistan, 2021-10-242024-02-26T15:39:12ZDavid Fifielddcf@torproject.orgBlocking of Snowflake in Turkmenistan, 2021-10-24On 2021-10-24, the number of Snowflake users in Turkmenistan dropped from 20–30 to almost zero:
[![userstats-bridge-combined-tm-2021-08-01-2021-12-16](/uploads/72fa4c798ac397813e2865642b90a7a6/userstats-bridge-combined-tm-2021-08-01-202...On 2021-10-24, the number of Snowflake users in Turkmenistan dropped from 20–30 to almost zero:
[![userstats-bridge-combined-tm-2021-08-01-2021-12-16](/uploads/72fa4c798ac397813e2865642b90a7a6/userstats-bridge-combined-tm-2021-08-01-2021-12-16.png)](https://metrics.torproject.org/userstats-bridge-combined.html?start=2021-08-01&end=2021-12-16&country=tm)
Previously discussed at:
* https://gitlab.torproject.org/tpo/community/support/-/issues/40030#note_2759213
* http://meetbot.debian.net/tor-meeting/2021/tor-meeting.2021-11-04-15.59.log.html#l-55
```
16:19:56 <anadahz> Confused about the meek client metrics in Turkmenistan -- https://metrics.torproject.org/userstats-bridge-combined.png?start=2021-08-02&end=2021-11-04&country=tm
16:20:39 <anadahz> How come and there are so many meek clients in Turkmenistan?
16:20:54 <dcf1> Here is a graph with some more context
16:20:56 <dcf1> https://people.torproject.org/~dcf/metrics-country.html?start=2021-08-01&end=2021-11-05&country=tm
16:21:00 <meskio> does it look like related to snowflake going down?
16:21:13 <dcf1> however zoom out a bit to get even *more* context (esp. wrt relay users)
16:21:15 <dcf1> https://people.torproject.org/~dcf/metrics-country.html?start=2021-07-01&end=2021-11-05&country=tm
16:21:23 <cohosh> related info on tor blocking in TM: https://gitlab.torproject.org/tpo/community/support/-/issues/40030
16:22:10 <dcf1> to me it looks like OR and meek were rising simultaneously, then snowflake and OR got blocked.
16:22:33 <cohosh> wow
16:22:49 <meskio> blocked? or our failure with probetest?
16:23:45 <dcf1> but snowflake users globally did not go to zero in the same way https://metrics.torproject.org/userstats-bridge-transport.html?start=2021-08-06&end=2021-11-04&transport=snowflake
16:24:05 <anadahz> On 2021-10-31 the amount of meek clients count were almost spike to 1,5 times than before.
16:24:05 <meskio> I see what you mean :(
16:24:09 <cohosh> yeah this looks suspiciously close to zero
```shelikhooshelikhoohttps://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/81have a url for saying the timestamp of the bridge data files2022-03-01T15:46:32ZRoger Dingledinehave a url for saying the timestamp of the bridge data filesgman (operator of Serge) has been asking us to make sure that Serge is properly scp'ing the bridge descriptors and bridge network status files to bridgedb, after various hardware moves.
We thought of setting up some other .ssh "authoriz...gman (operator of Serge) has been asking us to make sure that Serge is properly scp'ing the bridge descriptors and bridge network status files to bridgedb, after various hardware moves.
We thought of setting up some other .ssh "authorized command" approach so he can log in to the bridgedb server and ls that directory. But then I realized a better option would be: let's have bridgedb offer a url for saying when its input files were from.
Then we could use that url for easy prometheus / nagios freshness checking too.
Maybe we want to build this into rdsys because rdsys is the future, or maybe we want the feature in both bridgedb and rdsys. (I'm not sure how the rdsys roadmap timing looks.)https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40092Improve docs on network_mode: host (and network in general)2023-01-18T16:18:15ZchmacImprove docs on network_mode: host (and network in general)When I found this repo, the example line `network_mode: host` jumped out at me as suspicious. I looked up the docs and figured that it's probably because snowflake requires lots of ports or so. I figured that my trust in the tor project ...When I found this repo, the example line `network_mode: host` jumped out at me as suspicious. I looked up the docs and figured that it's probably because snowflake requires lots of ports or so. I figured that my trust in the tor project is pretty high, and so I'm running a snowflake node.
But, I'm not really sure what network conditions it needs. Does it expect that `network_mode: host` means it's running on a host which has a publicly accessible IP? Does it needs ports on that host's firewall open?
The idea behind this issue is to improve the docs in this area so that snowflake hosts like myself can figure out what network conditions are required for snowflake to work. For example, I have no idea if my node is actually functional right now, I also have no idea how to test it.
Some example questions we could aim to answer:
- What ports does snowflake run on?
- Does snowflake need to be run on a machine with a public IP?
- Does snowflake run properly if behind a NAT?
- Does snowflake require specific ports to be opened in the system firewall?
- How can a server admin test if snowflake is properly configured and working?
As an add on, it would be great to see answers to questions like these:
- How much bandwidth can one expect snowflake to use?
- Does it make sense to add any kind of limits?
- If so, how would that be done?
- Are there any security considerations to running a snowflake server?
- What sort of system resources (CPU, memory) does snowflake use?
- Does it make sense to check on this periodically for memory leaks, etc?
- How can one be notified when updates are published to the docker image?
- Is there a security mailing list where one could be notified of any security issues that require urgent update of the snowflake server?
Finally, thanks for making the tor network more resilient, snowflake looks to be an awesome improvement for people in locations with internet censorship, and thanks for working on tor in general, it's a phenomenal resource supporting the human experience.https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/80Limit access to Moat's /meek endpoint to a trusted CDN2023-09-11T15:33:37ZDavid Fifielddcf@torproject.orgLimit access to Moat's /meek endpoint to a trusted CDNThe [Moat setup](https://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/wikis/Moat?version_id=e2fd842546cce953143962e73c5efbefbb90e4b0) has both a /meek and a /moat endpoint. External requests are supposed to arrive at /meek, which...The [Moat setup](https://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/wikis/Moat?version_id=e2fd842546cce953143962e73c5efbefbb90e4b0) has both a /meek and a /moat endpoint. External requests are supposed to arrive at /meek, which adds an X-Forwarded-For header via [moat-shim](https://gitlab.torproject.org/cohosh/moat-shim) (#69), and is then forwarded to /moat. /moat can trust the X-Forwarded-For header because it was last updated by moat-shim from /meek.
But anonymous11 points out that because /meek is [exposed externally](https://bridges.torproject.org/meek/), an adversary can simulate control over many IP addresses by writing its own X-Forwarded-For header and thereby get access to more of the pool.
https://ntc.party/t/moat/1604/4
> Но Moat (в отличии от HTTPS) делает сбор совсем простым. Можно подключаться напрямую к Meek серверу (/meek), Moat дистрибьютеру (/moat) с ложными заголовками Meek-IP (изображая CDN), X-Forwarded-For (изображая moat-shim).
> *But Moat (as opposed to HTTPS) makes gathering quite simple. You can connect directly to a Meek server (/meek), a Moat distributor (/moat) with false headers Meek-IP (impersonating CDN), X-Forwarded-For (impersonating moat-shim).*
So
1. We can block direct access to /moat (allowing only localhost access from moat-shim), prohibiting X-Forwarded-For spoofing from outside.
2. We can try to ensure that access to /meek comes only from a CDN we trust to add X-Forwarded-For correctly.meskiomeskio@torproject.orgmeskiomeskio@torproject.org