Anti-censorship issueshttps://gitlab.torproject.org/groups/tpo/anti-censorship/-/issues2022-03-01T20:13:35Zhttps://gitlab.torproject.org/tpo/anti-censorship/censorship-analysis/-/issues/40013Task 4.3 Explore the parameter space in a Salmon reputation design2022-03-01T20:13:35ZGabagaba@torproject.orgTask 4.3 Explore the parameter space in a Salmon reputation designThis step happens after https://gitlab.torproject.org/tpo/anti-censorship/censorship-analysis/-/issues/40012
The question here is to understand better how broad or narrow is the range of workable parameters.
For example, what rates of ...This step happens after https://gitlab.torproject.org/tpo/anti-censorship/censorship-analysis/-/issues/40012
The question here is to understand better how broad or narrow is the range of workable parameters.
For example, what rates of discovery vs rates of fresh bridges should be workable and what rates should be unworkable?
(If we need more fresh bridges than we can get, that is an unworkable system.)https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40015Investigate high retransmission rate of Snowflake2022-03-01T19:17:35ZCecylia BocovichInvestigate high retransmission rate of SnowflakeThe recent report on Snowflake distinguishability caught the fact that Snowflake has a very high rate of retransmissions during the handshake: https://arxiv.org/pdf/2008.03254.pdf
This was reported to cause latency and it sounds like a ...The recent report on Snowflake distinguishability caught the fact that Snowflake has a very high rate of retransmissions during the handshake: https://arxiv.org/pdf/2008.03254.pdf
This was reported to cause latency and it sounds like a bug. It could also apply to the rest of the connection after the handshake. We should look into this.Sponsor 96: Rapid Expansion of Access to the Uncensored Internet through Tor in China, Hong Kong, & Tibethttps://gitlab.torproject.org/tpo/anti-censorship/monit-configuration/-/issues/6Add "end-to-end" test that talks to moat2022-03-01T17:56:58ZPhilipp Winterphw@torproject.orgAdd "end-to-end" test that talks to moatTo catch issues like the one in tpo/anti-censorship/pluggable-transports/meek#40001 early, we could add a new monit test that talks to moat over obfs4proxy. Basically, we would spawn a tor instance and let it bootstrap over meek. We then...To catch issues like the one in tpo/anti-censorship/pluggable-transports/meek#40001 early, we could add a new monit test that talks to moat over obfs4proxy. Basically, we would spawn a tor instance and let it bootstrap over meek. We then try to talk to moat and return with exit code 0 if this succeeded.
The challenge is that we should use the same tor and obfs4proxy version as Tor Browser does. And even then, there is no guarantee that we're catching all possible problems – for example, an issue may be limited to Windows. Still, having a test like this would probably go a long way.
(We discussed this topic in [today's anti-censorship meeting](http://meetbot.debian.net/tor-meeting/2020/tor-meeting.2020-12-17-15.57.html)).https://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/emma/-/issues/7Capture blocking by "TCP works but SSL gets mangled"2022-03-01T17:53:55ZCecylia BocovichCapture blocking by "TCP works but SSL gets mangled"We had a user run emma in Belarus, where they had no access to default bridges, and received results that showed no directory authorities, relays, or bridges were being blocked. This could be because emma only performs a TCP connection a...We had a user run emma in Belarus, where they had no access to default bridges, and received results that showed no directory authorities, relays, or bridges were being blocked. This could be because emma only performs a TCP connection and the blocking is happening at the TLS layer.
See https://gitlab.torproject.org/tpo/anti-censorship/censorship-analysis/-/issues/40002
Can we expand these tests to capture this behaviour while still keeping the lightweight design?https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake-webext/-/issues/32Add 'Number of users your Snowflake has helped so far' feature in the extension2022-03-01T17:47:16ZShakilAdd 'Number of users your Snowflake has helped so far' feature in the extensionCurrently, it has 'Number of users your Snowflake has helped circumvent censorship in the last 24 hours'. I really love watching the number grow from 0 to 10-15 every day. If it is possible to see all the people I have helped so far, tha...Currently, it has 'Number of users your Snowflake has helped circumvent censorship in the last 24 hours'. I really love watching the number grow from 0 to 10-15 every day. If it is possible to see all the people I have helped so far, that would be even more encouraging.https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake-webext/-/issues/31Update the screenshots at the extension stores2022-03-01T17:47:16ZcypherpunksUpdate the screenshots at the extension storesHey there, I recently installed the Snowflake extension, and the Chrome Web Store screenshots show something like this https://ibb.co/rwQNvjJ, while what I see is something like this:- https://ibb.co/sPNqjkQ
Is there anything that needs...Hey there, I recently installed the Snowflake extension, and the Chrome Web Store screenshots show something like this https://ibb.co/rwQNvjJ, while what I see is something like this:- https://ibb.co/sPNqjkQ
Is there anything that needs to be done?https://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/40021Some CollecTor bridge pool assignment files are empty2022-03-01T17:36:51ZCecylia BocovichSome CollecTor bridge pool assignment files are emptyI was helping a friend debug some weird bridge churn results for a research project, and noticed that some of CollecTor's bridge pool assignment data files are empty. See for example the file for the timestamp `2021-06-11-19-30-05` retri...I was helping a friend debug some weird bridge churn results for a research project, and noticed that some of CollecTor's bridge pool assignment data files are empty. See for example the file for the timestamp `2021-06-11-19-30-05` retrievable from https://collector.torproject.org/archive/bridge-pool-assignments/bridge-pool-assignments-2021-06.tar.xz.
I'm not sure if this is a bug on the BridgeDB side or the CollecTor side, but it appears to happen regularly (about once a month, near the middle of the month). So we should do an initial investigation on our end and then contact the metrics team if we think this is a CollecTor bug.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/bridgedb/-/issues/40041Add ability to request bridges run on a specific port for each of our distrib...2022-03-01T17:35:41ZCecylia BocovichAdd ability to request bridges run on a specific port for each of our distributors@dcf pointed out that bridges run on port 3785 are working in Kazakhstan: https://lists.torproject.org/pipermail/anti-censorship-team/2022-January/000211.html
We don't currently have a feature that lets users request bridges on specific...@dcf pointed out that bridges run on port 3785 are working in Kazakhstan: https://lists.torproject.org/pipermail/anti-censorship-team/2022-January/000211.html
We don't currently have a feature that lets users request bridges on specific ports, and since a censorship event has popped up where this feature might be useful, maybe we should consider implementing it. The closest we have is a feature that will attempt to return at least one bridge running on a common port (80 or 443). This feature could be an extension of that.
The trickier part will be the UX changes necessary for each of the distributors.https://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/40032allow Tor to parse bridge information copied and pasted verbatim from bridges...2022-03-01T17:35:41Zproperallow Tor to parse bridge information copied and pasted verbatim from bridges.torproject.orgCurrently bridges.torproject.org returns replies for copy and paste in the following form.
```
obfs4 ip:port fingerprint
```
This is easy for copied into tor-launcher. But one who wanted to copy this into its `/etc/tor/torrc` would hav...Currently bridges.torproject.org returns replies for copy and paste in the following form.
```
obfs4 ip:port fingerprint
```
This is easy for copied into tor-launcher. But one who wanted to copy this into its `/etc/tor/torrc` would have to modify it to.
```
Bridge obfs4 ip:port fingerprint
```
This is a usability issue. Therefore, could you make for example `/etc/tor/torrc` config option `obfs4` a shortcut to `Bridge obfs4` etc.?
Ideally, pluggable transports once they plugged into Tor using `ClientTransportPlugin` would be responsible for running the code for setting up these shortcuts themselves so you don't have to maintain a static/outdated list of shortcuts within the Tor core.https://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/12627canonicalFromSMTP is not what we think it should be2022-03-01T17:35:41ZMatthew FinkelcanonicalFromSMTP is not what we think it should be```
13:29:04 INFO L568:autoresponder.reply() Got an email; deciding whether to reply.
13:29:04 DEBUG L606:autoresponder.runCheck() Canonicalizing client email domain...
13:29:04 DEBUG L613:autoresponder.runCheck() Canonical ...```
13:29:04 INFO L568:autoresponder.reply() Got an email; deciding whether to reply.
13:29:04 DEBUG L606:autoresponder.runCheck() Canonicalizing client email domain...
13:29:04 DEBUG L613:autoresponder.runCheck() Canonical email domain: gmail.com
13:29:04 ERROR L620:autoresponder.runCheck() SMTP/Email canonical domain mismatch! ponticum vs gmail.com
```
The last line is generated by:
```
# The canonical domains from the SMTP ``MAIL FROM:`` and the email
# ``From:`` header should match:
if self.incoming.canonicalFromSMTP != canonicalFromEmail:
logging.error("SMTP/Email canonical domain mismatch!")
return False
```
and canonicalFromSMTP is provided by SMTPMessage().
I'm hotfixing it for now.meskiomeskio@torproject.orgmeskiomeskio@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/29448Provide a dir-spec implementation that serves sanitised descriptors2022-03-01T17:35:40ZirlProvide a dir-spec implementation that serves sanitised descriptorsThe Metrics Team currently performs sanitizing of bridge descriptors before publishing them on CollecTor (and subsequently feeding them into other software).
The published descriptors are detailed in:
https://metrics.torproject.org/col...The Metrics Team currently performs sanitizing of bridge descriptors before publishing them on CollecTor (and subsequently feeding them into other software).
The published descriptors are detailed in:
https://metrics.torproject.org/collector.html#bridge-descriptors
The sanitizing steps are detailed here:
https://metrics.torproject.org/bridge-descriptors.html
The descriptors are transferred to the CollecTor host unsanitized by means of rsyncing a tarball. This violates one of the Tor Metrics principles in that this is a private interface and we are handling sensitive data. While the data is then sanitized and published, it is not possible for others to operate their own CollecTor instance that fetches data directly from the BridgeDB instance. Additionally, this increases code complexity in CollecTor as now we must treat the fetching of relay and bridge descriptors differently.
Ideally the sanitizing steps would be performed by BridgeDB and then we would be able to reuse (at least large chunks of) CollecTor code that currently fetches relay descriptors.
This is a project that would need co-ordination with the Metrics Team on the best way forward.https://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/31426Update BridgeDB's specification2022-03-01T17:35:40ZPhilipp Winterphw@torproject.orgUpdate BridgeDB's specificationWe have [a BridgeDB spec](https://gitweb.torproject.org/torspec.git/tree/bridgedb-spec.txt) but it's outdated and was last modified in 2013. We should update the specification so it reflects BridgeDB's current implementation. We should a...We have [a BridgeDB spec](https://gitweb.torproject.org/torspec.git/tree/bridgedb-spec.txt) but it's outdated and was last modified in 2013. We should update the specification so it reflects BridgeDB's current implementation. We should also cover Moat, our new BridgeDB metrics (legacy/trac#9316), and maybe our anti-bot mechanism (legacy/trac#31252).
We should get the spec to a point where it can provide newcomers with a comprehensive understanding of BridgeDB's overall design.https://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/40016Write a spec for unsanitised bridge descriptor formats2022-03-01T17:35:40ZIsis LovecruftWrite a spec for unsanitised bridge descriptor formatsThe only places this is documented is [in BridgeDB's docs](https://pythonhosted.org/bridgedb/descriptors.html) and a bit [in Stem's docs](https://stem.torproject.org/api/descriptor/networkstatus.html#stem.descriptor.networkstatus.Bridg...The only places this is documented is [in BridgeDB's docs](https://pythonhosted.org/bridgedb/descriptors.html) and a bit [in Stem's docs](https://stem.torproject.org/api/descriptor/networkstatus.html#stem.descriptor.networkstatus.BridgeNetworkStatusDocument).https://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/25986Add AMP cache fronting option to Moat2022-03-01T17:35:40ZtwimAdd AMP cache fronting option to MoatThis is a followup of https://trac.torproject.org/projects/tor/ticket/25804#comment:25 (summary):
> It turns out that AppEngine is not the only option for domain fronting with Google.
> Google also provides a service called AMP cache f...This is a followup of https://trac.torproject.org/projects/tor/ticket/25804#comment:25 (summary):
> It turns out that AppEngine is not the only option for domain fronting with Google.
> Google also provides a service called AMP cache for AMP pages. What it basically does is proxying random pages on the Internet and making them load faster (e.g. on Google search results). It requires pages to comply with some format though and also strips invisible content, resizes images, etc.
> Despite it is being served via different domain names (one per real domain) it is still hosted at Google infrastructure which can be fronted.
Related tickets: legacy/trac#25807.https://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/23434Review bridgeauth glue/admin scripts and make as much public as possible2022-03-01T17:35:40ZIsis LovecruftReview bridgeauth glue/admin scripts and make as much public as possibleThese have never been public; I inherited them via Lucky Green. They are primarily ssh and rsync in shell scripts and cronjobs, but in order for others to understand how things get from one place to another in the network, they should be...These have never been public; I inherited them via Lucky Green. They are primarily ssh and rsync in shell scripts and cronjobs, but in order for others to understand how things get from one place to another in the network, they should be public where possible (I think this should be all of it, but I'll need to give it a careful once-over to be sure).
Putting in "Core Tor/Tor" since it's either that or "Obfuscation/BridgeDB" and neither really fits. (There maybe should be a component for DirAuth administration??)https://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/19997BridgeDB's get-tor-exits script doesn't account for IPv62022-03-01T17:35:40ZIsis LovecruftBridgeDB's get-tor-exits script doesn't account for IPv6As Arlo pointed out [on the tor-dev mailing list](https://lists.torproject.org/pipermail/tor-dev/2016-August/011318.html), the `exit-addresses` script running on check.torproject.org doesn't include IPv6 exit addresses, making anything t...As Arlo pointed out [on the tor-dev mailing list](https://lists.torproject.org/pipermail/tor-dev/2016-August/011318.html), the `exit-addresses` script running on check.torproject.org doesn't include IPv6 exit addresses, making anything that relies upon the list unreliable. BridgeDB's `scripts/get-tor-exits` downloads the output of `exit-addresses`, and uses it to treat clients using Tor to request bridges as coming from the same address. Not taking IPv6 addresses into account will allow an adversary to use IPv6-capable tor exits to get additional bridges during a time period.
Some new script should be written to generate a list of IPv6 (optionally also IPv4 addresses, so that everything is in one document) exit addresses to fix this issue.https://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/12507Automate BridgeDB documentation builds2022-03-01T17:35:40ZIsis LovecruftAutomate BridgeDB documentation buildsThe developer documentation for BridgeDB needs a place to live. Currently, Sphinx builds can be manually triggered to produce HTML documentation (as well as other types). I have been manually scp'ing it to https://para.noid.cat/bridgedb,...The developer documentation for BridgeDB needs a place to live. Currently, Sphinx builds can be manually triggered to produce HTML documentation (as well as other types). I have been manually scp'ing it to https://para.noid.cat/bridgedb, mostly because I had no idea where to put it, but wanted to put it somewhere.
So...
1. We should probably ask TPO's sysadmins to create something like https://docs.torproject.org/bridgedb, or wherever people want to use for keeping common developer documentation.
2. I think there was some sort of funding for this. I've just been doing this because I needed to understand how BridgeDB works and it was entirely undocumented when I started working on it. If someone knows who that funder is, please comment/tag this ticket as appropriate.
3. Documentation builds should probably be triggered automatically when a new signed tag is pushed to `git.torproject.org/bridgedb.git`.Developer portalhttps://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/12089BridgedDB can be forced to email arbitrary email addresses2022-03-01T17:35:40ZIsis LovecruftBridgedDB can be forced to email arbitrary email addressesSee legacy/trac#12086.
From [this commit message](https://gitweb.torproject.org/user/isis/bridgedb.git/commitdiff/4c18a4e2b89872c5731d4301665642065980086e) for [this unittest](https://gitweb.torproject.org/user/isis/bridgedb.git/blob/4c...See legacy/trac#12086.
From [this commit message](https://gitweb.torproject.org/user/isis/bridgedb.git/commitdiff/4c18a4e2b89872c5731d4301665642065980086e) for [this unittest](https://gitweb.torproject.org/user/isis/bridgedb.git/blob/4c18a4e2b89872c5731d4301665642065980086e:/lib/bridgedb/test/test_email_server.py#l326):
> BridgeDB will accept an email from an arbitrary gmail/yahoo email address at the SMTP layer, and then send the reply to a *different* arbitrary gmail/yahoo email address taken from the contents of the email headers.
>
> As you can see in the example...
(in the ticket description of legacy/trac#12086)
> the SMTP command
>
> {{{
> MAIL FROM: isisgrimalkin@gmail.com
> }}}
>
> combined with a `'From: isislovecruft@gmail.com'` in the email headers within the SMTP `DATA` segment caused the reply to be sent the reply to the later, when it came from the former.
While this was done quick-and-dirty with netcat, it's probably possible to configure msmtp to send a the same SMTP commands/info with embedded email headers still specifying an arbitrary email address, such that Gmail/Yahoo would produce a valid DKIM signature for it and pass it along to BridgeDB. (And thus the issue isn't merely that DKIM verification appears to be broken, but the issue is that we're not checking that source of an incoming email matches the destination of the response.)
> In addition, the person reading such a unsolicited response from BridgeDB also has no way to know who originally emailed BridgeDB to cause this email to end up in her inbox in the first place.
>
> I'm not exactly certain if this is a bug or a feature. While it could be used for sending some junk to an arbitrary gmail/yahoo address, it could also be used as a sort of
>
> "Dear BridgeDB, can I have some bridges? Asking for a friend."
>
> mechanism.
I'm guessing that we're likely to see more use of it for the former, more malicious activity than the latter benevolent one, and so we should probably consider this a pretty serious bug.
-----------------------------------------------------------------------------
Side note:
All the bugs found with that unittest were present in older versions of BridgeDB, and possibly have always been present, and they don't appear to be resultant from my recent rewrite of the email servers ([as sysrqb noted](https://trac.torproject.org/projects/tor/ticket/5463#comment:21), my rewrite retained portions of the old codebase). I just wanted to point that out so that I'm not blamed for introducing them. Unfortunately, I didn't catch this while staring at the code for several hours. (But hiphiphooray for unittests! :D )meskiomeskio@torproject.orgmeskiomeskio@torproject.org