Anti-censorship issueshttps://gitlab.torproject.org/groups/tpo/anti-censorship/-/issues2020-06-27T13:40:25Zhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/31124Make it more expensive (CPU wise, or other thing) to make the initial connect...2020-06-27T13:40:25ZcypherpunksMake it more expensive (CPU wise, or other thing) to make the initial connection to a snowflakeThat way it's harder for an adversary to cramp up a list of all the snowflakes
I don't know if this is a good idea (possible problems: each x seconds one has to reconnect to a snowflake if one makes a network request which will take eve...That way it's harder for an adversary to cramp up a list of all the snowflakes
I don't know if this is a good idea (possible problems: each x seconds one has to reconnect to a snowflake if one makes a network request which will take even more time)https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/meek/-/issues/12428Make it possible to have multiple requests and responses in flight2023-03-21T21:26:20ZDavid Fifielddcf@torproject.orgMake it possible to have multiple requests and responses in flightmeek segments a data stream into multiple HTTP request–response pairs. In order to keep the segments in order, meek-client strictly serializes requests: it won't issue a second request until after it receives the response to its first re...meek segments a data stream into multiple HTTP request–response pairs. In order to keep the segments in order, meek-client strictly serializes requests: it won't issue a second request until after it receives the response to its first request, even if there is buffered data waiting to be sent.
The limit of one latent request–response is restricting possible throughput. For instance, if a user is located 200 ms from App Engine, and receives up to 64 KB per request, then their downstream throughput can be no greater than 64 KB/200 ms = 320 KB/s, even if everything after App Engine were instantaneous. Longer delays lead to even lower throughput.
The problem is how to deal with out-of-order arrivals, and retransmissions when an HTTP transaction fails. My plan is to add sequence numbers and acknowledgements to upstream and downstream HTTP headers, similar to what we did in OSS (https://www.bamsoftware.com/papers/oss.pdf section 4). The seq number is the index of the first byte of a payload in the overall stream. The ack number is the index of the next byte we're expecting from the other side. We can implement this idea in a backward-compatible way, by having the server guess in seq and ack fields when they are missing; old clients that serialize will continue to work.
There's a complication related to the protocol's polling nature. During a big download, we want multiple downstream responses to be in flight. In order to get that, we need to speculatively send a bunch of requests and see if they get responses that have data. My thinking is to do something like [TCP congestion avoidance](https://en.wikipedia.org/wiki/TCP_congestion-avoidance_algorithm), where we increment the number of speculative probes we send by 1 every time we get a response back with data. Maybe only when we get a full-sized response. Reset the number to 1 when there is a loss event.David Fifielddcf@torproject.orgDavid Fifielddcf@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/meek/-/issues/12208Make it possible to use an IP address as a front (no DNS request and no SNI)2021-11-08T19:49:21ZDavid Fifielddcf@torproject.orgMake it possible to use an IP address as a front (no DNS request and no SNI)meek puts one domain name on the "outside" of your connection (the DNS request and SNI), and a different name on the "inside" (the HTTP Host header). It would be good for some uses if the outside could be just to an IP address rather tha...meek puts one domain name on the "outside" of your connection (the DNS request and SNI), and a different name on the "inside" (the HTTP Host header). It would be good for some uses if the outside could be just to an IP address rather than a domain name, so that there were no DNS request, and no server_name extension in the CLientHello. Kind of like if you were to browse to https://38.229.72.16/ instead of https://www.torproject.org/.
The motivating use case is using a CDN as a front instead of www.google.com. A CDN has many domains behind it, but if we choose just one of them as the front, that domain might get blocked (because the collateral damage would be limited to just one domain). Such blocking would break the transport and also incidentally get the innocent third-party domain, who has nothing to do with any of this, censored even for non-circumventors. What we want is to use one of the CDN's frontend IP addresses as a front, so that the censor has to block the whole IP and the thousands of domains behind it, not just a single domain.David Fifielddcf@torproject.orgDavid Fifielddcf@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/lox/-/issues/7Make Lox Bridge Table more robust2023-08-02T14:38:59ZonyinyangMake Lox Bridge Table more robustRelated to onyinyang/lox#2, the Lox bridge table currently relies on [bucket and key vectors that grow indefinitely and have a 1:1 mapping by vector index](https://gitlab.torproject.org/onyinyang/lox/-/blob/master/src/bridge_table.rs#L21...Related to onyinyang/lox#2, the Lox bridge table currently relies on [bucket and key vectors that grow indefinitely and have a 1:1 mapping by vector index](https://gitlab.torproject.org/onyinyang/lox/-/blob/master/src/bridge_table.rs#L217) and uses indices in these vectors to preserve the state of the bridge table. This is probably fine for a small number of resources that will not frequently change. However, for our use case, we expect the number of bridges available to fluctuate somewhat frequently--at least with new bridges being added/updated and existing bridges becoming blocked on a regular basis. Additionally, with possible failures at the point of either the distributor, or rdsys, it is possible that things could get out of sync which could create chaos for all Lox users. For our use case, it does not make sense to maintain several indefinitely growing vectors that must be kept in sync by the indices at which resources are stored. Instead, we could keep tables in a database for each different resource of the bridge table, that can be referenced by some unique identifier.onyinyangonyinyanghttps://gitlab.torproject.org/tpo/anti-censorship/lox/-/issues/39Make lox-distributor listening port configurable2024-01-22T15:15:35ZCecylia BocovichMake lox-distributor listening port configurableRight now we have the lox distributor [hard-coded to listen on port 8001](https://gitlab.torproject.org/tpo/anti-censorship/lox/-/blob/main/crates/lox-distributor/src/main.rs?ref_type=heads#L351). We should make this configurable.Right now we have the lox distributor [hard-coded to listen on port 8001](https://gitlab.torproject.org/tpo/anti-censorship/lox/-/blob/main/crates/lox-distributor/src/main.rs?ref_type=heads#L351). We should make this configurable.https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/meek/-/issues/11580Make meek man pages2020-06-27T13:44:21ZDavid Fifielddcf@torproject.orgMake meek man pagesFor:
* meek-client
* meek-server
Maybe also (only used in the bundle):
* meek-client-torbrowser
* terminateprocess-buffer
Join us for our next exciting episode, _Make `man meek` manifest meek manual_, or, _Three billy goats groff_.For:
* meek-client
* meek-server
Maybe also (only used in the bundle):
* meek-client-torbrowser
* terminateprocess-buffer
Join us for our next exciting episode, _Make `man meek` manifest meek manual_, or, _Three billy goats groff_.David Fifielddcf@torproject.orgDavid Fifielddcf@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/meek/-/issues/12716Make meek-client-torbrowser take the firefox command as a parameter2020-06-27T13:44:20ZDavid Fifielddcf@torproject.orgMake meek-client-torbrowser take the firefox command as a parametermeek-client-torbrowser hardcodes the firefox binary and profile paths: [linux](https://gitweb.torproject.org/pluggable-transports/meek.git/blob/2ef6e31de94eb10d40464a38909373114ff44132:/meek-client-torbrowser/linux.go) [mac](https://gitw...meek-client-torbrowser hardcodes the firefox binary and profile paths: [linux](https://gitweb.torproject.org/pluggable-transports/meek.git/blob/2ef6e31de94eb10d40464a38909373114ff44132:/meek-client-torbrowser/linux.go) [mac](https://gitweb.torproject.org/pluggable-transports/meek.git/blob/2ef6e31de94eb10d40464a38909373114ff44132:/meek-client-torbrowser/mac.go) [windows](https://gitweb.torproject.org/pluggable-transports/meek.git/blob/2ef6e31de94eb10d40464a38909373114ff44132:/meek-client-torbrowser/windows.go). The problem is that when Tor Browser is reorganized, as it was in legacy/trac#11641, you need to make the corresponding change in meek-client-torbrowser, for example [178572f5](https://gitweb.torproject.org/pluggable-transports/meek.git/commitdiff/178572f5f1bb52200fa4c45497298241a745d8af).
meek-client-torbrowser already takes the full meek-client command on the command line; it [looks like](https://gitweb.torproject.org/builders/tor-browser-bundle.git/blob/a2370de2b0b44a22f3f2591c2960cd6767940b8b:/Bundle-Data/PTConfigs/linux/torrc-defaults-appendix#l14):
```
ClientTransportPlugin meek exec ./TorBrowser/Tor/PluggableTransports/meek-client-torbrowser -- ./TorBrowser/Tor/PluggableTransports/meek-client --url=https://meek-reflect.appspot.com/ --front=www.google.com
```
I don't know of a good clear way to encode two separate command lines into the command line of another program, except maybe to do them both as long strings and then parse the strings before calling exec.David Fifielddcf@torproject.orgDavid Fifielddcf@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/meek/-/issues/18655Make meek-server easy to use with Let's Encrypt2020-06-27T13:44:16ZDavid Fifielddcf@torproject.orgMake meek-server easy to use with Let's EncryptCurrently it's not trivial to get certificates for meek-server using Let's Encrypt. The `--webroot` option, for example, wants to write a token to the filesystem so the web server can serve it, but meek-server doesn't serve files from th...Currently it's not trivial to get certificates for meek-server using Let's Encrypt. The `--webroot` option, for example, wants to write a token to the filesystem so the web server can serve it, but meek-server doesn't serve files from the filesystem.
Ideally this works in a way that certificates can be renewed (e.g. in a cron job) without restarting tor or meek-server.David Fifielddcf@torproject.orgDavid Fifielddcf@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40259Make nf_conntrack changes persistent2023-04-25T15:13:40ZDavid Fifielddcf@torproject.orgMake nf_conntrack changes persistentInvestigating the [loss of users from Iran](https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/115#note_2883298)
and the [increase of users from Russia that only affected snowflake-02](https://gitlab.torproject.org/tpo/anti-...Investigating the [loss of users from Iran](https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/115#note_2883298)
and the [increase of users from Russia that only affected snowflake-02](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/merge_requests/131#note_2883300)
that happened in the second half of February 2023,
I discovered that the [increased nf_conntrack table size](https://gitlab.torproject.org/tpo/anti-censorship/team/-/wikis/Survival-Guides/Snowflake-Bridge-Installation-Guide?version_id=a7bcf0502102bd8d820f590bc9856a0a738a2225#general-system-setup)
from #40239 had not taken effect since
the bridges were rebooted on 2023-02-16 for #40253.
```
root@snowflake-01:~# date -u --iso=sec
2023-03-04T07:13:32+00:00
root@snowflake-01:~# cat /proc/sys/net/netfilter/nf_conntrack_{count,max,buckets}
186671
262144
65536
```
```
root@snowflake-02:~# date -u --iso=sec
2023-03-04T07:36:45+00:00
root@snowflake-02:~# cat /proc/sys/net/netfilter/nf_conntrack_{count,max,buckets}
21155
262144
65536
```
The default settings were supposed to be overridden
by /etc/sysctl.d/nf_conntrack.conf, which is loaded during boot by sysctl:
```
root@snowflake-01:~# cat /etc/sysctl.d/nf_conntrack.conf
net.netfilter.nf_conntrack_max = 524288
net.netfilter.nf_conntrack_buckets = 524288
```
I think the problem is that the sysctl settings are made
before the nf_conntrack module is first loaded, so they have no effect,
as the [sysctl.d(5)](https://manpages.debian.org/bullseye/systemd/sysctl.d.5.en.html#CONFIGURATION_FORMAT)
man page cautions:
> Many sysctl parameters only become available when certain kernel modules are loaded. Modules are usually loaded on demand, e.g. when certain hardware is plugged in or network brought up. This means that [systemd-sysctl.service(8)](https://manpages.debian.org/bullseye/systemd/systemd-sysctl.service.8.en.html) which runs during early boot will not configure such parameters if they become available after it has run. To set such parameters, it is recommended to add an [udev(7)](https://manpages.debian.org/bullseye/udev/udev.7.en.html) rule to set those parameters when they become available. Alternatively, a slightly simpler and less efficient option is to add the module to [modules-load.d(5)](https://manpages.debian.org/bullseye/systemd/modules-load.d.5.en.html), causing it to be loaded statically before sysctl settings are applied (see example below).
The workaround, as the man page suggests,
is to add `nf_conntrack` to /etc/modules to make it be loaded earlier in the boot sequence,
or add a udev rule to re-load the `net.netfilter` sysctl settings
when nf_conntrack is loaded.
* https://github.com/systemd/systemd/issues/1113#issuecomment-138051408
* https://serverfault.com/a/676721
* https://github.com/coreos/bugs/issues/785
I've re-started the [conntrack.sh script](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40239#note_2864515)
to track `nf_conntrack_count` over time.
I will let it run for a couple of days to get a baseline,
then I will increase the nf_conntrack limits again
to see if it has an effect on usership.
Then, I will try one of the above workarounds to make the change actually persistent this time.
/cc @linusDavid Fifielddcf@torproject.orgDavid Fifielddcf@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/docker-obfs4-bridge/-/issues/3Make obfs4 Docker image support private bridges2021-10-25T18:55:11ZPhilipp Winterphw@torproject.orgMake obfs4 Docker image support private bridgesFor legacy/trac#28526 it would be helpful if one could configure an obfs4 Docker container to be private. We could simply add a new environment variable, say `PRIVATE_BRIDGE`, which controls whether the container sets `BridgeDistribution...For legacy/trac#28526 it would be helpful if one could configure an obfs4 Docker container to be private. We could simply add a new environment variable, say `PRIVATE_BRIDGE`, which controls whether the container sets `BridgeDistribution none` in its torrc or not.https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/lyrebird/-/issues/33153Make obfs4 Docker image support private bridges2021-10-25T18:55:33ZPhilipp Winterphw@torproject.orgMake obfs4 Docker image support private bridgesFor legacy/trac#28526 it would be helpful if one could configure an obfs4 Docker container to be private. We could simply add a new environment variable, say `PRIVATE_BRIDGE`, which controls whether the container sets `BridgeDistribution...For legacy/trac#28526 it would be helpful if one could configure an obfs4 Docker container to be private. We could simply add a new environment variable, say `PRIVATE_BRIDGE`, which controls whether the container sets `BridgeDistribution none` in its torrc or not.https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/31151Make pre-compiled binaries for proxy-go2021-05-20T19:40:42ZCecylia BocovichMake pre-compiled binaries for proxy-goIf we're doing a push for snowflakes, we should provide pre-compiled binaries for the proxy-go instances. The reason for this is that the go toolchain is non-trivial to set up and there may be people happy to run these instances if there...If we're doing a push for snowflakes, we should provide pre-compiled binaries for the proxy-go instances. The reason for this is that the go toolchain is non-trivial to set up and there may be people happy to run these instances if there is a lower barrier to set uphttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/trac/-/issues/29283Make PTs go dormant2020-07-06T23:49:52ZCecylia BocovichMake PTs go dormantThis is to make PTs more friendly in mobile environments. Right now the PT process(es) keep running in the background when they are not being used, possibly making network connections.
We need to first figure out how to do this, by poss...This is to make PTs more friendly in mobile environments. Right now the PT process(es) keep running in the background when they are not being used, possibly making network connections.
We need to first figure out how to do this, by possibly doing something creative with the PT protocolSponsor 28: Reliable Anonymous Communication Evading Censors and Repressors (RACECAR)https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/14Make rdsys's backend export metrics2020-12-09T18:55:21ZPhilipp Winterphw@torproject.orgMake rdsys's backend export metricsAt the very least, rdsys should export the metrics that BridgeDB currently exports. In addition to that, it would be useful to expose a simple Web page that provides key metrics at a glance, similar to how [Snowflake's broker does it](ht...At the very least, rdsys should export the metrics that BridgeDB currently exports. In addition to that, it would be useful to expose a simple Web page that provides key metrics at a glance, similar to how [Snowflake's broker does it](https://snowflake-broker.bamsoftware.com/metrics).https://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/40159Make Snowflake recognize FascistFirewall2022-10-28T19:15:17ZcypherpunksMake Snowflake recognize FascistFirewallSnowflake takes a long time to start a connection when a firewall is blocking outgoing ports. If the tor daemon or Tor Browser is configured to connect only to certain ports, then Snowflake could recognize that setting and not take so lo...Snowflake takes a long time to start a connection when a firewall is blocking outgoing ports. If the tor daemon or Tor Browser is configured to connect only to certain ports, then Snowflake could recognize that setting and not take so long to start a connection. Right now, Snowflake stalls when that setting is enabled, regardless of a firewall.
In the tor daemon, the settings are `FascistFirewall` and `ReachableAddresses`. In Tor Browser, the setting is located at `Settings --> Connection --> Advanced --> "Configure how Tor Browser connects to the internet" (Settings... button) --> "This computer goes through a firewall that only allows connections to certain ports" (80,443)`.
Going further, Snowflake could assume after certain conditions also that Tor Project's [ReducedExitPolicy](https://gitlab.torproject.org/legacy/trac/-/wikis/doc/ReducedExitPolicy) is enabled in the firewall.https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40014Make Snowflake's DTLS fingerprint more similar to popular WebRTC implementations2024-01-12T17:12:10ZCecylia BocovichMake Snowflake's DTLS fingerprint more similar to popular WebRTC implementationsSome recent work by researchers at Princeton shows that Snowflake's DTLS fingerprint differs from some other popular WebRTC implementations (Facebook, Google, and Discord): https://arxiv.org/pdf/2008.03254.pdf
I'm hesitant to rush chang...Some recent work by researchers at Princeton shows that Snowflake's DTLS fingerprint differs from some other popular WebRTC implementations (Facebook, Google, and Discord): https://arxiv.org/pdf/2008.03254.pdf
I'm hesitant to rush changes to the fingerprint without a more complete comparison to more WebRTC implementations popular in censored regions. But, we can get a start on figuring out how to change the fingerprint in pion and see whether we will need to submit upstream patches to provide us with this kind of agility. Something like uTLS would be great for us in the long run.Sponsor 96: Rapid Expansion of Access to the Uncensored Internet through Tor in China, Hong Kong, & Tibettheodorsmtheodorsmhttps://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/29Make supported resources configurable2020-11-30T18:17:42ZPhilipp Winterphw@torproject.orgMake supported resources configurableLike BridgeDB, we should be able to configure what resources rdsys supports. For example, some people somehow set up meek bridges and we don't want to distribute those.Like BridgeDB, we should be able to configure what resources rdsys supports. For example, some people somehow set up meek bridges and we don't want to distribute those.Sponsor 30 - Objective 2.3Philipp Winterphw@torproject.orgPhilipp Winterphw@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake-webext/-/issues/19Make sure browser proxies are terminating connections properly2023-02-04T09:41:52ZCecylia BocovichMake sure browser proxies are terminating connections properlyWe had a user in #tor mention that their snowflake icon is staying green for hours. If this really is a multi-hour browsing session, that's fine. But if it's due to a closed connection that keeps the snowflake out of commission then we s...We had a user in #tor mention that their snowflake icon is staying green for hours. If this really is a multi-hour browsing session, that's fine. But if it's due to a closed connection that keeps the snowflake out of commission then we should look into it.https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake-webext/-/issues/38Make sure the data channel and peer connection for the NAT test are always cl...2022-01-27T22:56:54ZCecylia BocovichMake sure the data channel and peer connection for the NAT test are always closedAs mentioned in https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40071#note_2770241 and https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40071#note_2770364...As mentioned in https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40071#note_2770241 and https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40071#note_2770364, the snowflake web proxy code is not properly closing WebRTC peer connections and data channels.
We should make sure we do this regardless of whether the NAT check succeeds.Cecylia BocovichCecylia Bocovich