Anti-censorship issueshttps://gitlab.torproject.org/groups/tpo/anti-censorship/-/issues2022-03-08T13:26:56Zhttps://gitlab.torproject.org/tpo/anti-censorship/gettor-project/OnionSproutsBot/-/issues/2How should locales be dealt with?2022-03-08T13:26:56Zn0tooseHow should locales be dealt with?I finally got the bot to work using the new library that I had to use. It allows me to use callbacks, which help me with asking for the user's platform, then generating a list of locales that are available to that specific platform, with...I finally got the bot to work using the new library that I had to use. It allows me to use callbacks, which help me with asking for the user's platform, then generating a list of locales that are available to that specific platform, without the user having to send a text message that looks like "`English (USA), Linux (32-bit)`.
Here's a screenshot:
![image](/uploads/39a668707bddd16828b63f3785beb292/image.png)
I used the `InlineKeyboardButton`s to add the locales, however, they don't all fit in one row.
## Scenarios
Do I:
- Split the locales in different rows?
Problem: In order to be user friendly, you'd have to use the names of the locales that are readable by human beings. In the previous screenshot, more than 5 locales fit in one row, because each locale consisted of 2 characters. I doubt that this is going to work when you have locales that range from "Dutch (Netherlands) a
- Replace locale names with flags?
Problem: Stateless populations, niche locales, countries with more than two official languages or countries with large foreign-speaking populations (e.g. Malta, Canada, etc.).
- Use the user's preferred language on Telegram and just ask for their preferred operating system?
This seems by far the simplest solution to me and simplifies UX, although I haven't sought after implementing it. It simplifies deciding for the language that the bot will communicate in with the user.
Problem: Although it's a bit easier to maintain, it limits available options and forces the user to disclose that information to Telegram, which technically already has access to this information anyways. However, Telegram can be used as a means of establishing a data transfer with encryption (because of "Secret Chats", which are now possible but haven't been explored yet). Also, there may be a locale that could be available on Telegram but not to the bot/the requested program, and vice versa.
- Have the user choose an operating system, and then using a "ReplyKeyboardMarkup" to provide a scrollable menu of options with locales.
Here's how a ReplyKeyboardMarkup would look like:
![image](/uploads/d779d25bc9efd4b2d8696e9e1654a6c5/image.png)
Problem: Increases complexity, may require dealing with a database that will store metadata about the end user, makes hosting more difficult to other people. When the user clicks on a button in a "ReplyKeyboardMarkup", they have to send a text message, which the bot will have to process. That will break things if the user sends a message with just the locale, without having issued their preferred operating system, unless if the bot generates a menu consisting of keys that looks like `English (USA), Linux (32-bit)`.
## Goal
The goal is to:
- **not** store user information and data.
- **accommodate** as many people as possible regardless of their locale
If a `ReplyKeyboardMarkup` (the series of buttons on top of the keyboard) is to be used, it can only be used once and in the beginning. When the user makes a decision, the bot dynamically generates a new prompt with a new set of buttons, which also stores the previous decision of the user with the help of `InlineKeyboardMarkup`'s (the buttons under text messages from the bot).https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/trac/-/issues/29285Improve the PT spec and how PTs interface with Tor2021-12-27T20:58:44ZCecylia BocovichImprove the PT spec and how PTs interface with TorWe want to make it easier for developers (and academics) to design and implement new pluggable transports and get them easily integrated with Tor so that we can have a well-functioning PT integration pipeline.
This is a large project th...We want to make it easier for developers (and academics) to design and implement new pluggable transports and get them easily integrated with Tor so that we can have a well-functioning PT integration pipeline.
This is a large project that will consist of several things:
- We need to assess pain points with the current PT spec and desired features from a variety of PT developers.
- We might want to take a look at the PTv2 specification to see where features differ from our v1 and also which features seem to be liked or used by PT developers.
- We should think about how bridge distribution should factor into the PT specification. For example, some transports such as meek and snowflake handle "bridge" information differently than transports whose bridges are distributed through BridgeDB. This results in a different interaction with Tor, and we might consider modifying the spec with the snowflake/broker model in mind (ticket legacy/trac#29296).
In general, we should improve our communication with the pluggable transports community to see what they need and figure out how to get more PTs integrated with Tor.https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/webtunnel/-/issues/6Add Turbo Tunnel to HTTPT2022-08-30T18:25:59ZPhilipp Winterphw@torproject.orgAdd Turbo Tunnel to HTTPTThis is a child issue of httpt#1. Let's add Turbo Tunnel to HTTPT so that HTTP connection interruptions don't interrupt the end-to-end TCP flow.This is a child issue of httpt#1. Let's add Turbo Tunnel to HTTPT so that HTTP connection interruptions don't interrupt the end-to-end TCP flow.https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/18Improve the PT spec and how PTs interface with Tor2022-02-10T19:59:17ZCecylia BocovichImprove the PT spec and how PTs interface with TorWe want to make it easier for developers (and academics) to design and implement new pluggable transports and get them easily integrated with Tor so that we can have a well-functioning PT integration pipeline.
This is a large project th...We want to make it easier for developers (and academics) to design and implement new pluggable transports and get them easily integrated with Tor so that we can have a well-functioning PT integration pipeline.
This is a large project that will consist of several things:
- We need to assess pain points with the current PT spec and desired features from a variety of PT developers.
- We might want to take a look at the PTv2 specification to see where features differ from our v1 and also which features seem to be liked or used by PT developers.
- We should think about how bridge distribution should factor into the PT specification. For example, some transports such as meek and snowflake handle "bridge" information differently than transports whose bridges are distributed through BridgeDB. This results in a different interaction with Tor, and we might consider modifying the spec with the snowflake/broker model in mind (ticket legacy/trac#29296).
In general, we should improve our communication with the pluggable transports community to see what they need and figure out how to get more PTs integrated with Tor.https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/webtunnel/-/issues/5Add HTTPT client implementation to obfs4proxy2022-08-30T18:25:51ZPhilipp Winterphw@torproject.orgAdd HTTPT client implementation to obfs4proxyThis is a child issue of httpt#1. Once we added Turbo Tunnel to HTTPT (see httpt#2), we can turn it into a new transport of obfs4proxy, so HTTPT will be available as a pluggable transport in Tor Browser.This is a child issue of httpt#1. Once we added Turbo Tunnel to HTTPT (see httpt#2), we can turn it into a new transport of obfs4proxy, so HTTPT will be available as a pluggable transport in Tor Browser.https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/lyrebird/-/issues/32550Static tor in docker container2020-10-29T20:26:58ZTracStatic tor in docker containerI was wondering about how to improve the docker image. The current version of provided image, in such case for bridges, uses debian. This ends up in a "big" image that, in my honest opinion waste a lot of space.
In order to improve the ...I was wondering about how to improve the docker image. The current version of provided image, in such case for bridges, uses debian. This ends up in a "big" image that, in my honest opinion waste a lot of space.
In order to improve the deployment and the space required by such container, which can be even extended for all relay, I wrote a Makefile for statically build tor. Once there is a statically build of tor, it should be enough provide just it inside the container.
```
PREFIX=$(shell pwd)/dist
RELEASE=$(shell pwd)/release
TOR=https://dist.torproject.org
TOR_VER=0.4.1.6
LIBEVENT=https://github.com/libevent/libevent/releases/download
LIBEVENT_VER=2.1.11-stable
OPENSSL=https://github.com/openssl/openssl/archive
OPENSSL_VER=1_0_2t
ZLIB=https://zlib.net
ZLIB_VER=1.2.11
CLEAN_DIRS=$(dir .)
all: tor
tor: tor-${TOR_VER} libevent libseccomp zlib openssl
cd $< && \
./configure \
--prefix=${RELEASE} \
--enable-static-tor \
--with-openssl-dir=${PREFIX} \
--with-libevent-dir=${PREFIX} \
--with-zlib-dir=${PREFIX} \
--disable-asciidoc \
--disable-system-torrc \
--disable-seccomp \
&& $(MAKE) $(MAKEFLAGS) && $(MAKE) install
libevent: libevent-${LIBEVENT_VER}
cd $< && \
./configure --prefix=${PREFIX} --enable-shared=no && \
$(MAKE) $(MAKEFLAGS) && $(MAKE) install
openssl: OpenSSL_${OPENSSL_VER}
cd $< && \
./config no-shared no-dso no-zlib --prefix=${PREFIX} && \
$(MAKE) depend && $(MAKE) $(MAKEFLAGS) && $(MAKE) install_sw
zlib: zlib-${ZLIB_VER}
cd $< && \
./configure --prefix=${PREFIX} --static && \
$(MAKE) $(MAKEFLAGS) && $(MAKE) install
## Download and extract source if required
tor-${TOR_VER}:
wget -qO- ${TOR}$@.tar.gz | \
bsdtar xzf -
libevent-${LIBEVENT_VER}:
wget -qO- ${LIBEVENT}/release-${LIBEVENT_VER}/$@.tar.gz | \
bsdtar xzf -
OpenSSL_${OPENSSL_VER}:
wget -qO- ${OPENSSL}/$@.tar.gz | \
bsdtar xzf -
mv openssl-$@ $@
zlib-${ZLIB_VER}:
wget -qO- ${ZLIB}/$@.tar.gz | \
bsdtar xzf -
```
**Trac**:
**Username**: thymbahutymbahttps://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/36Build a bridge censorship measurement system for Salmon2023-03-24T16:02:19ZPhilipp Winterphw@torproject.orgBuild a bridge censorship measurement system for SalmonSalmon needs to know if and when a bridge is blocked, so it can update client reputation scores. Let's use this issue to build that censorship measurement mechanism. There are several ways to go about this:
1. We could set up [bridgestr...Salmon needs to know if and when a bridge is blocked, so it can update client reputation scores. Let's use this issue to build that censorship measurement mechanism. There are several ways to go about this:
1. We could set up [bridgestrap](https://gitlab.torproject.org/tpo/anti-censorship/bridgestrap) instances in censored networks and design a control channel between our central rdsys instance and the various bridgestrap instances. [wolpertinger](https://gitlab.torproject.org/tpo/anti-censorship/wolpertinger) was originally designed for that and we may be able to reuse some ideas and code. See tpo/anti-censorship/censorship-analysis#34258 for more details.
1. We can outsource the problem to OONI. That was the original plan but OONI probes are run by untrusted strangers, some of which could be censors that try to find and block bridges. OONI, at least in its current form, is therefore not a good choice.
1. We could incorporate passively-gathered data like the countries from which bridges have recently seen clients.
Option 1) strikes me as a good way forward because we already have a lot of the necessary code in place. Essentially, we still need a low-bandwidth, low-latency, censorship-resistant communication channel between bridgestrap instances in various countries and rdsys. If we go down that route, a few more questions emerge:
* Should the bridgestrap instances periodically poll for new bridges to test? Or should rdsys push these bridges to bridgestrap?
* What should the censorship-resistant communication channel look like? A domain-fronted API like moat may be good enough.
* How should rdsys communicate with these bridgestrap instances? Should it implement a new distributor like wolpertinger? Or should this functionality live in the backend? For what it's worth, rdsys's [bridge testing mechanism](https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/blob/master/doc/resource-testing.md) lives in the backend.Sponsor 96: Rapid Expansion of Access to the Uncensored Internet through Tor in China, Hong Kong, & Tibethttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/18653Copy-paste not working in snowflake client (global webrtcRemote is uninitiali...2021-07-09T18:26:26ZDavid Fifielddcf@torproject.orgCopy-paste not working in snowflake client (global webrtcRemote is uninitialized)The copy-paste rendezvous doesn't work in [6efb5cb8](https://gitweb.torproject.org/pluggable-transports/snowflake.git/log/?id=6efb5cb8ef56bc84a56a8244f81a0817d7202912). The `readSignalingMessages` goroutine panics because the global `web...The copy-paste rendezvous doesn't work in [6efb5cb8](https://gitweb.torproject.org/pluggable-transports/snowflake.git/log/?id=6efb5cb8ef56bc84a56a8244f81a0817d7202912). The `readSignalingMessages` goroutine panics because the global `webrtcRemote` is `nil` at [client/snowflake.go:142](https://gitweb.torproject.org/pluggable-transports/snowflake.git/tree/client/snowflake.go?id=6efb5cb8ef56bc84a56a8244f81a0817d7202912#n142):
```
webrtcRemote.answerChannel <- sdp
```
`git bisect` says [b8815627](https://gitweb.torproject.org/pluggable-transports/snowflake.git/commit/?id=b8815627bd189c3ee0829ce09152684726c6933c) "defer conn.Close for simplicity and remove unnecessary goroutines, improve error handling (close !legacy/trac#12)" is the first bad commit.
I'm using the copy-paste rendezvous because I want to test a server locally for legacy/trac#18627.https://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/1607Add code that will make it possible to request bridges for a certain country2020-06-27T13:43:36ZAndrew LewmanAdd code that will make it possible to request bridges for a certain countryAdd code that will make it possible to request bridges for a certain country like so: By mail: bridges+zh@torproject.org By http: https://bridges.torproject.org/zhAdd code that will make it possible to request bridges for a certain country like so: By mail: bridges+zh@torproject.org By http: https://bridges.torproject.org/zhChristian FrommeChristian Frommehttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/trac/-/issues/2759Proof of concept transport plugin: http headers2020-06-27T13:44:09ZRoger DingledineProof of concept transport plugin: http headersSteven has been working on a socks proxy that will stick the Tor transport in http headers. It isn't designed to fool a human looking at the traffic, but it seems to fool wireshark.
Its main goal is to act as a proof of concept for our ...Steven has been working on a socks proxy that will stick the Tor transport in http headers. It isn't designed to fool a human looking at the traffic, but it seems to fool wireshark.
Its main goal is to act as a proof of concept for our modular transport proposal (legacy/trac#2758) so we don't have to generalize from zero data points.Deliverable-May2011Steven MurdochSteven Murdochhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake-mobile/-/issues/5Allow users to add custom Relay, STUN, Broker servers using a settings UI.2020-07-10T17:20:02ZHashikDAllow users to add custom Relay, STUN, Broker servers using a settings UI.A settings UI needs to be designed for the user to add the server addresses.A settings UI needs to be designed for the user to add the server addresses.HashikDHashikDhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake-webext/-/issues/5Allow webextension users to specify how many resources it uses2023-03-31T07:58:03ZCecylia BocovichAllow webextension users to specify how many resources it usesI'm not sure what the default behaviour for webrtc connections is, but we should allow users to throttle or set a bandwidth cap on their connections to avoid over-using their resources.I'm not sure what the default behaviour for webrtc connections is, but we should allow users to throttle or set a bandwidth cap on their connections to avoid over-using their resources.https://gitlab.torproject.org/tpo/anti-censorship/emma/-/issues/5Incorporate emma into OONI2024-02-29T15:21:09ZPhilipp Winterphw@torproject.orgIncorporate emma into OONIMaria once suggested adding emma to OONI. Both are written in Go, so it may not be a terribly complex endeavour. I'll have a chat with Simone to get a better sense of what this would entail.
The big benefit of having emma in OONI is th...Maria once suggested adding emma to OONI. Both are written in Go, so it may not be a terribly complex endeavour. I'll have a chat with Simone to get a better sense of what this would entail.
The big benefit of having emma in OONI is that we would get significantly more measurements and we no longer need to expect users to be able to compile programs.https://gitlab.torproject.org/tpo/anti-censorship/censorship-analysis/-/issues/40007Task 1.1 Get some manual vantage points in key regions, and generate automate...2022-02-11T16:40:07ZGabagaba@torproject.orgTask 1.1 Get some manual vantage points in key regions, and generate automated baseline measurements in each of themGet some manual vantage points in key regions, and automate scans of vanilla Tor, default Tor Browser bridges, vanilla and obfs4 bridges (both from bridgedb and unpublished), and meek.
- [ ] Pick key regions (possible China and Turkey, ...Get some manual vantage points in key regions, and automate scans of vanilla Tor, default Tor Browser bridges, vanilla and obfs4 bridges (both from bridgedb and unpublished), and meek.
- [ ] Pick key regions (possible China and Turkey, Belarus, Thailand, Uganda, Russia, India)
- [ ] Tools to start with
- [ ] Snowflake tests and STUN server tests
- [ ] Emma
- [ ] Marco
- [ ] OONI
- [ ] Bridgestrap
- [ ] Tor itself in various configsSponsor 28: Reliable Anonymous Communication Evading Censors and Repressors (RACECAR)shelikhooshelikhoohttps://gitlab.torproject.org/tpo/anti-censorship/censorship-analysis/-/issues/40018Clean up and document automated snowflake and obfs4 measurement scripts2021-07-28T14:43:12ZCecylia BocovichClean up and document automated snowflake and obfs4 measurement scriptsWe've been using [these test scripts](https://github.com/cohosh/bridgetest/) for measuring [the blocking of obfs4](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/obfs4/-/issues/31701) and [snowflake blocking](http...We've been using [these test scripts](https://github.com/cohosh/bridgetest/) for measuring [the blocking of obfs4](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/obfs4/-/issues/31701) and [snowflake blocking](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/32657) on a VPS in China.
Now that we're getting more manual vantage points (#40007), we should get these scripts up-to-date and well-documented.Cecylia BocovichCecylia Bocovichhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/32938Have a way to test throughput of snowflake proxy2020-11-20T18:33:24ZCecylia BocovichHave a way to test throughput of snowflake proxyA common question from snowflake proxy volunteers is whether or not their proxy is working (see comment 11 on legacy/trac#31109). It would be great to have some kind of bandwidth test for proxy owners to see whether or not their proxy is...A common question from snowflake proxy volunteers is whether or not their proxy is working (see comment 11 on legacy/trac#31109). It would be great to have some kind of bandwidth test for proxy owners to see whether or not their proxy is reachable from a remote probe point. This might also help us find and diagnose problems with existing proxies.
Some notes:
- we can't ask the broker to assign us a specific proxy at the moment so this test would likely be separate from the broker (unless we add an entirely new feature which I'm hesitant to do)
- we'll have to protect this service from abuse somehow, probably by rate-limiting. See some discussion on legacy/trac#31874. It would be best to engineer a way so that only a proxy owner can run the test on their proxy.https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/18654Use TLS WebSockets (wss://) for proxy-to-server communication2024-01-08T07:32:48ZDavid Fifielddcf@torproject.orgUse TLS WebSockets (wss://) for proxy-to-server communicationWe might as well use secure WebSockets (wss://) instead of plain WebSockets (ws://).
For this, the server plugin needs TLS support. It can probably be cribbed from meek-server, which defaults to TLS.
[I started a thread](https://lists....We might as well use secure WebSockets (wss://) instead of plain WebSockets (ws://).
For this, the server plugin needs TLS support. It can probably be cribbed from meek-server, which defaults to TLS.
[I started a thread](https://lists.torproject.org/pipermail/tor-dev/2016-March/010645.html) asking for brainstorming on how to easily used Let's Encrypt with a specialized HTTP server like out server plugins.https://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/1608If we know a certain bridge is blocked in a certain country, don’t give out t...2020-06-27T13:43:36ZAndrew LewmanIf we know a certain bridge is blocked in a certain country, don’t give out that bridge to that countryIf we know a certain bridge is blocked in a certain country, don’t give out that bridge to that country
Child Tickets:
[[TicketQuery(parent=legacy/trac#1608)]]If we know a certain bridge is blocked in a certain country, don’t give out that bridge to that country
Child Tickets:
[[TicketQuery(parent=legacy/trac#1608)]]https://gitlab.torproject.org/tpo/anti-censorship/censorship-analysis/-/issues/6140Kazakhstan uses DPI to block Tor2020-06-27T13:43:43ZRuna SandvikKazakhstan uses DPI to block TorTwo blog posts published in the beginning of March talks about Kazakhstan using DPI to block Tor. The posts say that Kazakhstan is identifying and blocking the SSL client key exchange during the setup of an SSL connection. It seems the K...Two blog posts published in the beginning of March talks about Kazakhstan using DPI to block Tor. The posts say that Kazakhstan is identifying and blocking the SSL client key exchange during the setup of an SSL connection. It seems the Kazakhstan firewall finds something unique in the TLS "Server Hello" message as sent by the Tor relay or bridge and therefore blocks subsequent communications. IP address and TCP port are irrelevant to the censorship.
From legacy/trac#6045 (where we discuss Ethiopia blocking Tor based on ServerHello), we know that:
* The normal Tor Browser Bundle with a special bridge works; the bridge with the patch that causes the final hello done TLS record to be sent in a separate packet.
* The three bridges in https://blog.torproject.org/blog/update-censorship-ethiopia are also working in Kazakhstan. These are bridges with a patch that removes 0x0039 from SERVER_CIPHER_LIST.https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/meek/-/issues/11183Make an HTTP requestor Firefox extension for meek-client2020-06-27T13:44:22ZDavid Fifielddcf@torproject.orgMake an HTTP requestor Firefox extension for meek-clientFollowing the discussion at https://lists.torproject.org/pipermail/tor-dev/2014-February/006266.html and the summary at [[doc/meek#HowtolooklikebrowserHTTPS]], I think our best option for having TLS that looks like a browser is to make a...Following the discussion at https://lists.torproject.org/pipermail/tor-dev/2014-February/006266.html and the summary at [[doc/meek#HowtolooklikebrowserHTTPS]], I think our best option for having TLS that looks like a browser is to make a browser extension that meek-client uses as a tool to make HTTPS requests.
To summarize: meek-client needs to make HTTPS requests, but needs to do so with a TLS signature that isn't trivially blockable. A browser doesn't have a blockable TLS signature, so we can have meek-client drive a browser to make requests on its behalf. Rather than ship an entire separate browser to users, we can use an extension in Tor Browser itself, one whose only purpose is to make HTTPS requests using the browser's networking code, bypassing the browser's proxy settings that would otherwise send all requests through Tor.
The communication goes:
browser ↔ tor ↔ meek-client ↔ extension ↔ www.google.com
There will need to be some kind of IPC between meek-client and the extension. I haven't figured out how that will work. Maybe the extension can be an HTTP proxy--that would be super easy to integrate with meek-client. But maybe you don't want an HTTP proxy running in your browser bundle, even if it's only intended for a specific purpose. Maybe the IPC needs to be authenticated somehow, and the extension needs to somehow inform the other process of how to contact it.David Fifielddcf@torproject.orgDavid Fifielddcf@torproject.org