Anti-censorship issueshttps://gitlab.torproject.org/groups/tpo/anti-censorship/-/issues2023-10-20T15:25:32Zhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40290standalone snowflake README still says go 1.15+ needed2023-10-20T15:25:32ZRoger Dingledinestandalone snowflake README still says go 1.15+ neededThe proxy/README.md file still says you need Go 1.15+, but it appears from e.g. https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/merge_requests/184 like the go version requirement is now 1.21.
So, two t...The proxy/README.md file still says you need Go 1.15+, but it appears from e.g. https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/merge_requests/184 like the go version requirement is now 1.21.
So, two things:
* We should update the README to reflect current requirements
and
* We should figure out what we want to tell people on Debian, who can no longer build snowflake, if they don't want to engage in installing and maintaining the whole toolchain manually. Do they stick with v2.6.1? Do they turn off their snowflake? Something even smarter? ...and then write that in the README too.https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/176run some experiments with CAPTCHAs2023-12-18T18:28:37Zmeskiomeskio@torproject.orgrun some experiments with CAPTCHAsAs we are planning to phase out CAPTCHAs (#173), can we run some experiments and see if they can be still effective?
We could either use the existing moat CAPTCHA API as we have some months until clients stop using it, or we could do it...As we are planning to phase out CAPTCHAs (#173), can we run some experiments and see if they can be still effective?
We could either use the existing moat CAPTCHA API as we have some months until clients stop using it, or we could do it in the HTTPS distributor as soon as we have migrated it to rdsys (#2).
There was a thread in the mailing list some years ago about this:
https://lists.torproject.org/pipermail/tor-dev/2021-July/014604.html
We should explore the space and see what better options for CAPTCHAs exist now a days.meskiomeskio@torproject.orgmeskiomeskio@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40289prometheus metrics: inbound traffic is a magnitude higher than outbound ?2023-10-20T15:24:55Ztoralfprometheus metrics: inbound traffic is a magnitude higher than outbound ?Me wonders about these numbers :
```
~/devel/tor-relays $ hcloud server list --output columns=name | grep -v NAME | sort | while read i; do echo; echo $i; ssh -n $i 'curl -s localhost:9999/internal/metrics | grep "^tor.*traffic"'; done
...Me wonders about these numbers :
```
~/devel/tor-relays $ hcloud server list --output columns=name | grep -v NAME | sort | while read i; do echo; echo $i; ssh -n $i 'curl -s localhost:9999/internal/metrics | grep "^tor.*traffic"'; done
buddelflink
tor_snowflake_proxy_traffic_inbound_bytes_total 1.5137087637e+10
tor_snowflake_proxy_traffic_outbound_bytes_total 1.842859221e+09
drehrumbum
tor_snowflake_proxy_traffic_inbound_bytes_total 2.616226932e+10
tor_snowflake_proxy_traffic_outbound_bytes_total 2.428826961e+09
elster2
tor_snowflake_proxy_traffic_inbound_bytes_total 2.4824487988e+10
tor_snowflake_proxy_traffic_outbound_bytes_total 2.756696966e+09
hoppel2
tor_snowflake_proxy_traffic_inbound_bytes_total 1.8561349297e+10
tor_snowflake_proxy_traffic_outbound_bytes_total 1.831598894e+09
igel
tor_snowflake_proxy_traffic_inbound_bytes_total 2.203970161e+10
tor_snowflake_proxy_traffic_outbound_bytes_total 2.038998589e+09
moppi3
tor_snowflake_proxy_traffic_inbound_bytes_total 2.1562580774e+10
tor_snowflake_proxy_traffic_outbound_bytes_total 2.572686488e+09
nickeneck
tor_snowflake_proxy_traffic_inbound_bytes_total 1.7488402935e+10
tor_snowflake_proxy_traffic_outbound_bytes_total 1.840865957e+09
pittiplatsch
tor_snowflake_proxy_traffic_inbound_bytes_total 2.0007601682e+10
tor_snowflake_proxy_traffic_outbound_bytes_total 1.980735179e+09
putzi
tor_snowflake_proxy_traffic_inbound_bytes_total 2.2191193167e+10
tor_snowflake_proxy_traffic_outbound_bytes_total 2.005800589e+09
schwarzrock
tor_snowflake_proxy_traffic_inbound_bytes_total 2.2477079962e+10
tor_snowflake_proxy_traffic_outbound_bytes_total 2.340506538e+09
```https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/172bridges.torproject.org's alternative ways to get bridges doesn't mention tele...2024-03-04T15:32:55ZRoger Dingledinebridges.torproject.org's alternative ways to get bridges doesn't mention telegramOn https://bridges.torproject.org/options/ we have "I need an alternative way of getting bridges!" which mentions email, but it doesn't mention any of our newer mechanisms, like telegram, circumvention settings, etc.
We should either:
...On https://bridges.torproject.org/options/ we have "I need an alternative way of getting bridges!" which mentions email, but it doesn't mention any of our newer mechanisms, like telegram, circumvention settings, etc.
We should either:
* flesh out this page to properly list the various ways you can get bridges
or
* identify that there is a better page that already does this up to date list, and change the text here to simply point there.https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40286On IPv6-only server, always "NAT type: unknown" even with firewall disabled2023-10-21T16:18:43Zcatharsis71On IPv6-only server, always "NAT type: unknown" even with firewall disabledI have an IPV6-only VPS server, using NAT64 DNS servers for outbound access to IPV4-only hostnames
hostnames with no AAAA records get synthetic AAAA records set by the DNS server so that traffic goes through the NAT64 service
hostnames w...I have an IPV6-only VPS server, using NAT64 DNS servers for outbound access to IPV4-only hostnames
hostnames with no AAAA records get synthetic AAAA records set by the DNS server so that traffic goes through the NAT64 service
hostnames with AAAA records resolve normally and go out directly
there is no access to raw IPv4 IP addresses
running snowflake-proxy, I always get "NAT type: unknown" even if my firewall is completely disabled... is this intended behavior?
I've tested both the Docker container and compiling/running locally but the results are the same
the proxy does seem to work but normally only gets 0-3 connections per hour per proxy (seemingly unaffected by whether the firewall is up or down)
perhaps this is due to the small pool of IPV6 clients wanting to connect, but I'm not sure
snowflake.torproject.net has an AAAA record so traffic to it does not go through NAT64
likewise stun.l.google.com has an AAAA record so traffic to it does not go through NAT64
I am unable to determine the cause of the "NAT type: unknown"https://gitlab.torproject.org/tpo/anti-censorship/lox/-/issues/28Set daily max bucket distribution and adjust other settings for production2024-02-15T16:52:09ZonyinyangSet daily max bucket distribution and adjust other settings for productionWe likely need to decide on an upper bound of buckets that can be distributed each day so that we don't run out of open invitation buckets. We currently have buckets being distributed to k users before a new bucket is used but if buckets...We likely need to decide on an upper bound of buckets that can be distributed each day so that we don't run out of open invitation buckets. We currently have buckets being distributed to k users before a new bucket is used but if buckets are continuously requested, we will eventually run out of buckets each day. These variables should be part of a configuration file for Lox.Lox Ready for Open Testing Callonyinyangonyinyanghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40284Publish container in our gitlab registry2023-10-01T15:24:43Zmicahmicah@torproject.orgPublish container in our gitlab registryNow that Tor [has enabled container registry support in Gitlab](https://gitlab.torproject.org/tpo/tpa/gitlab/-/issues/89), it is possible to build and publish a container that is hosted in the container registry [here in the snowflake pr...Now that Tor [has enabled container registry support in Gitlab](https://gitlab.torproject.org/tpo/tpa/gitlab/-/issues/89), it is possible to build and publish a container that is hosted in the container registry [here in the snowflake project](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/container_registry).
It would be ideal if we could host our own container, and point people to use that. We don't have to stop using the 3rd party registry.
This should be done automatically in the CI.https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/170Set up a staging server2023-12-07T17:35:38Zmeskiomeskio@torproject.orgSet up a staging serverTo be able to experiment with things we want a staging server of rdsys.
* [x] get a new VM for it (https://gitlab.torproject.org/tpo/tpa/team/-/issues/41297)
* [x] generate fake descriptors (#171)
* [ ] test accounts for gettor
* [ ] ...To be able to experiment with things we want a staging server of rdsys.
* [x] get a new VM for it (https://gitlab.torproject.org/tpo/tpa/team/-/issues/41297)
* [x] generate fake descriptors (#171)
* [ ] test accounts for gettor
* [ ] github
* [ ] gitlab
* [ ] archive.org
* [ ] google drive
* [ ] test account for telegram bot
* [x] write an script to automatize the cleanup and deploy
* [x] document the setup in the wikimeskiomeskio@torproject.orgmeskiomeskio@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/130HTTP based PT protocol2023-10-09T16:19:25Zmeskiomeskio@torproject.orgHTTP based PT protocolSOCKS has many problems:
* We have to do hacks to do things like passing arguments, and they come with many problems ( #104)
* There are not many SOCKS server implementations and many PTs end up needing to implement their own ([goptlib]...SOCKS has many problems:
* We have to do hacks to do things like passing arguments, and they come with many problems ( #104)
* There are not many SOCKS server implementations and many PTs end up needing to implement their own ([goptlib](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/goptlib/-/blob/v1.4.0/socks.go) and [proteus](https://github.com/unblockable/proteus/tree/99751539b78782d4477411786e4df03b68213e5d/src/net/proto/socks) have done it)
We could use [HTTP CONNECT](https://www.rfc-editor.org/rfc/rfc9110#CONNECT) or [MASQUE](https://datatracker.ietf.org/wg/masque/about/) as a base that will give use the option of having headers to encode arguments and hopefully they are easy to implement based on standard HTTP/QUIC libraries.https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/129Recommend not exposing OrPort for bridges2024-02-27T18:53:18Zmeskiomeskio@torproject.orgRecommend not exposing OrPort for bridgesEnabling `AssumeReachable 1` in torrc we can avoid publishing the OrPort in bridges. Are we ok recommending to do that to bridge operators?
If we decide to move forward with this those are the steps needed for it:
* [ ] Don't use the r...Enabling `AssumeReachable 1` in torrc we can avoid publishing the OrPort in bridges. Are we ok recommending to do that to bridge operators?
If we decide to move forward with this those are the steps needed for it:
* [ ] Don't use the running flag in metrics ( https://gitlab.torproject.org/tpo/network-health/team/-/issues/318)
* [ ] update Docker images to don't expose OrPort
* [ ] obfs4
* [ ] webtunnel
* [ ] update documentation https://community.torproject.org/relay/setup/bridge/
* [ ] write an email to tor-relays@lists.torproject.org about itmeskiomeskio@torproject.orgmeskiomeskio@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/lox/-/issues/24Implement Metrics Reporting for Lox2023-10-31T21:19:34ZonyinyangImplement Metrics Reporting for LoxFrom the [Lox Roadmap](https://gitlab.torproject.org/tpo/anti-censorship/lox-rs/-/wikis/Lox-Roadmap) we want to include strategic reporting of metrics in our Lox deployment so that we are able to determine the effectiveness of Lox. The m...From the [Lox Roadmap](https://gitlab.torproject.org/tpo/anti-censorship/lox-rs/-/wikis/Lox-Roadmap) we want to include strategic reporting of metrics in our Lox deployment so that we are able to determine the effectiveness of Lox. The minimum metrics to measure are the following:
- [x] Prometheus metrics for counts of how often each library function is called from distributor
- [ ] How many bridges are in each rank
- [ ] Blockages from deployed bridgestrap instance
- [x] Remaining capacity (or if/when we run out of bridges to hand out to open inv)
Discussion, development of these and additional metrics to include in the initial deployment will be tracked in this issue.onyinyangonyinyanghttps://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/169Gettor: distribute TB in bitbucket.org2024-02-27T18:23:51Zmeskiomeskio@torproject.orgGettor: distribute TB in bitbucket.orgIt looks like bitbucket is not blocked in some places where others are.It looks like bitbucket is not blocked in some places where others are.https://gitlab.torproject.org/tpo/anti-censorship/lox/-/issues/20Figure out how to serve the encrypted bridge table to users2023-08-01T17:07:20ZCecylia BocovichFigure out how to serve the encrypted bridge table to usersLox credentials only contain an index into an encrypted table of bridge lines. Users must download the entire encrypted bridge table periodically in order to find and decrypt their bridges to preserve their anonymity and prevent the Lox ...Lox credentials only contain an index into an encrypted table of bridge lines. Users must download the entire encrypted bridge table periodically in order to find and decrypt their bridges to preserve their anonymity and prevent the Lox distributor from learning which users were assigned which bridges.
This can be a rather large download, and for obvious reasons must be done automatically and in a censorship-resistant way.https://gitlab.torproject.org/tpo/anti-censorship/connectivity-measurement/logcollector/-/issues/5Add Conjoure Pluggable Transport Support2023-08-01T17:05:38ZshelikhooAdd Conjoure Pluggable Transport SupportConjure is a new pluggable transport based on refraction routing.
This issue track the support for conjure in WebTunnel.
(See also: https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/conjure/-/issues/33)Conjure is a new pluggable transport based on refraction routing.
This issue track the support for conjure in WebTunnel.
(See also: https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/conjure/-/issues/33)shelikhooshelikhoohttps://gitlab.torproject.org/tpo/anti-censorship/lox/-/issues/18Change lox-library functionality to replenish open-invitation bucket pool fro...2023-08-01T17:07:14ZonyinyangChange lox-library functionality to replenish open-invitation bucket pool from hot-spare poolHot spares could replenish open-invitation buckets but currently are only reallocated to be migrated to after a blocking event.
Perhaps the current functionality is the desired functionality, but if we're more likely to have open-invitat...Hot spares could replenish open-invitation buckets but currently are only reallocated to be migrated to after a blocking event.
Perhaps the current functionality is the desired functionality, but if we're more likely to have open-invitation bridges blocked than user migrate to trusted buckets when their bridges become blocked, this might be something to consider.
At the very least it could satisfy a condition in the case that there are no remaining open-invitation buckets. We should probably also flag that scenario so we can do something to get more bridges into the pool (hopefully).https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/conjure/-/issues/33Add Conjure to logcollector to test censorship resistance2024-02-14T17:00:13ZCecylia BocovichAdd Conjure to logcollector to test censorship resistanceWe're getting reports that conjure doesn't work in some places https://forum.torproject.net/t/call-for-testers-help-the-tor-project-to-test-conjure-on-tor-browser-alpha/7815/14
Let's run some tests from vantage points to figure out why ...We're getting reports that conjure doesn't work in some places https://forum.torproject.net/t/call-for-testers-help-the-tor-project-to-test-conjure-on-tor-browser-alpha/7815/14
Let's run some tests from vantage points to figure out why so we can prioritize improvements.https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/165Write an spec of the assignments.log file format2023-06-12T08:47:21Zmeskiomeskio@torproject.orgWrite an spec of the assignments.log file formathttps://gitlab.torproject.org/tpo/anti-censorship/lox/-/issues/5Rewrite Lox handling of new resources2024-02-15T17:38:19ZonyinyangRewrite Lox handling of new resourcesAt present, the Lox distributor handles `new` resources by parsing them into BridgeLines, grouping them into 3 (MAX_BRIDGES_PER_BUCKET) and then placing them into an open invitation bucket. Any additional bridges that don't group into 3 ...At present, the Lox distributor handles `new` resources by parsing them into BridgeLines, grouping them into 3 (MAX_BRIDGES_PER_BUCKET) and then placing them into an open invitation bucket. Any additional bridges that don't group into 3 are stored temporarily in the LoxServerContext until enough bridges to make up a bucket come along. Eventually, this needs to be improved to address several things:
* [ ] Smarter bridge groupings:
* What factors determine whether a set of bridges are grouped into a bucket?
* Should the distributor determine those factors or should rdsys pre-sort bridges into buckets?
* [ ] Decide on an appropriate open invitation to hot spare bucket ratio
* Some proportion of buckets *must* be hot spare buckets so that there are a pool of buckets for users to migrate to
* [ ] Ensure access to open-entry invitations
* Can we prevent sock-puppets from clogging the open-entry pathway?
* Can/should we limit which open-entry bridges are distributed to which users?
* [ ] Determine when a bridge is "blocked"?
* In reality, bridges are blocked by locale which Lox does not consider
* Issue being tracked [here](https://gitlab.torproject.org/tpo/anti-censorship/censorship-analysis/-/issues/40035)
* [ ] Improve Lox Parameters for Tor Usecase
* Lox's parameters such as the time to level up, number of invitations distributed, etc. are untested in the real world
* Are there better parameters for Tor's usecase?https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake-webext/-/issues/85Avast blocking connection to 02.snowflake.torproject.net on Chrome2023-06-27T18:50:48ZcypherpunksAvast blocking connection to 02.snowflake.torproject.net on ChromeHello, I've had the Snowflake browser extension on Google Chrome for at least a year now, maybe 2 years. I've never had any problems with it. Suddenly, starting yesterday, I've started receiving alerts from a security software I've had...Hello, I've had the Snowflake browser extension on Google Chrome for at least a year now, maybe 2 years. I've never had any problems with it. Suddenly, starting yesterday, I've started receiving alerts from a security software I've had installed for over a year now (Avast) about security threats from Tor Snowflake.
This has never happened before, so I just wanted to check if there are any new, known security vulnerabilities for Snowflake providers? I'm just curious as to why I'm suddenly receiving alerts from Avast.
This is the warning I've received twice now: "We've blocked a threat URL: Blacklist on https://
02.snowflake.torproject.net/ from being downloaded."
I've not put snowflake on a blacklist, and it always worked fine before, so either Avast recently put Snowflake on a blacklist, Snowflake is trying to download an update or something, or a malicious user (somehow, I'm not too knowledgeable about what's technically possible for users to do) is trying to download something on my computer via Snowflake.https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40271refactor: use Pion's `SetIPFilter` instead of our `StripLocalAddresses`2023-06-29T18:57:41ZWofWcawofwca@protonmail.comrefactor: use Pion's `SetIPFilter` instead of our `StripLocalAddresses`[`SetIPFilter`](https://pkg.go.dev/github.com/pion/webrtc/v3#SettingEngine.SetIPFilter) was [recently added](https://github.com/pion/webrtc/pull/2316) to Pion.
I'm not sure if this gives actual benefits, but to me it seems better if Pio...[`SetIPFilter`](https://pkg.go.dev/github.com/pion/webrtc/v3#SettingEngine.SetIPFilter) was [recently added](https://github.com/pion/webrtc/pull/2316) to Pion.
I'm not sure if this gives actual benefits, but to me it seems better if Pion would filter out addresses by itself, instead of us only stripping them off when sending the offer/answer (see 0fae4ee8ea487c3b4384217e193e5b9a9088e7de, 1867f89562fb25bf9a3c2172a7b6f0a198c81adb, https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/19026). It _might_ also solve [the problem (if it's a problem)](https://forum.torproject.net/t/ubuntu-snowflake-standalone-proxy-tries-to-access-private-lan/7485?u=wofwca) where if a client sends local addresses in its offer, the proxy will try to connect to these local addresses.
Also while we're at it, need to check whether it can be a proper way to solve https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40108.