- anti-censorship-team - lists.torproject.org

goptlib's git repository, and its (recent) source code
by Vinicius Zavam 27 Sep '20

27 Sep '20

olá Anti-censorship Team, I write to you to share the current status of "goptlib" and its git repositories, plus mirrors (and the source code). As maintainer of "a few" packages depending on goptlib, I missed an updated version of its main git repo (git.tpo/pluggable-transports/goptlib) into the actual GitHub Orga. of the Tor Project (@torproject), or any official mirror like the ones hosted at the new GitLab server - AFAIK, most people relied on @ahf's GitHub sync in the past (also not up to date). - FYI: packages depending on goptlib which were recently ported into *BSD include the OONI Probe CLI So, I took the chance of getting a synced copy into the TorBSD's goptlib repo (github.com/torbsd/goptlib) - which was sadly also with an outdated version of the source code. - I took the already existing repo, and just synced it; did not create or change anything. This move is based on the lack of support of the ports frameworks we currently use on OpenBSD/FreeBSD/NetBSD; they work nicely with GitHub's or GitLab's API, but not with cgit(web). another solution for that would be serving a tarball via https://dist.tpo (but I did not find any). I would be pretty much happy to help and would volunteer myself to keep it always on track, should any extra hands are needed here; but I have a couple questions: - should my GH account be linked to tpo's (@torproject)? - would you like us (TorBSD/tdp) to sign any additional sync or commit? - how oft should we sync (or/and sign)? - is it fine to keep the current updated repo, or would you like us to "deprecate" it? - any other suggestions, ideas or objections? You can reach out to me via email or on IRC (my key+info are on https://tpo/about/people page) That's it... and TYVM for the hard work! Muito obrigado :) KR, -- Vinicius Zavam https://keybase.io/egypcio

2 1

Reading group 2020-10-01: Triplet Censors: Demystifying Great Firewall's DNS Censorship Behavior
by David Fifield 17 Sep '20

17 Sep '20

After the team meeting on 2020-10-01 we will discuss this paper from FOCI 2020: Triplet Censors: Demystifying Great Firewall's DNS Censorship Behavior https://www.usenix.org/conference/foci20/presentation/anonymous

1 0

Will be absent for the Aug 20 reading group
by David Fifield 19 Aug '20

19 Aug '20

The reading group at the 20 August meeting is scheduled to be on my paper on Turbo Tunnel. I've just remembered that I won't be able to be present at that meeting. I don't necessarily have to be part of this reading group, but if you want me to be, it will have to be another time.

2 3

New censorship event, in Belarus. No way to add it
by kuroneko＠dismail.de 12 Aug '20

12 Aug '20

Belarus has been experiencing serious internet connectivity issues for 3 days already. I tried to add a new censorship event to <https://trac.torproject.org/projects/tor/wiki/doc/MetricsTimeline>, but the wiki has been rendered read-only. See also: https://twitter.com/KuroNeko10x/status/1293035387468648450. Is there any other way to add a new censorship event to metrics.torproject.org at the moment? -- kuroneko / KuroNeko / 黒ネコ https://twitter.com/KuroNeko10x

2 1

Next week's reading group: Adoption and Abandonment of VPNs
by Cecylia Bocovich 23 Jul '20

23 Jul '20

Hey everyone! Our next anti-censorship reading group will take place on July 23 at the end of our usual meeting at 16:00 UTC. The reading next week is a new paper being presented at the Privacy Enhancing Technologies Symposium (PETS) this week titled: "Emotional and Practical Considerations Towards the Adoption and Abandonment of VPNs as a Privacy-Enhancing Technology" Link to the paper: https://petsymposium.org/2020/files/papers/issue1/popets-2020-0006.pdf This talk will be live streamed tomorrow (Thursday) July 16th in the censorship session that runs from 12:40–13:55 ET (16:40-17:55 UTC) at the following link (along with some other talks that may be interesting to this group): https://www.youtube.com/watch?v=JdDgAuuilZk Cecylia

3 3

How do wiki pages work in the new gitlab?
by David Fifield 24 Jun '20

24 Jun '20

Were wiki pages from Trac copied over to gitlab somewhere? I have found "Wiki" links on some gitlab pages, but not mirrored content from Trac. The page I care about is https://trac.torproject.org/projects/tor/wiki/doc/MetricsTimeline which is used for the timeline annotations under Tor Metrics graphs. Even if wiki content was not automatically copied over, I'm thinking of giving that page a new home on gitlab.

3 2

Next week's reading group: V2Ray & VMess
by David Fifield 11 Jun '20

11 Jun '20

The topic of the reading group next week will be V2Ray and VMess. The reading group happens after the weekly team IRC meeting, which will be at 16:00 UTC on Thursday, 2020-06-11. https://trac.torproject.org/projects/tor/wiki/org/teams/AntiCensorshipTeam#… V2Ray is a platform for deploying proxy protocols. It offers a number of composable proxy protocols, transports, and obfuscation options. https://www.v2ray.com/en/ https://github.com/v2ray/v2ray-core VMess is one of the proxy protocols supported by V2Ray. From my cursory understanding, it is in a similar vein to protocols like obfs4 and Shadowsocks. https://github.com/v2ray/manual/blob/master/eng_en/protocols/vmess.md I started a discussion thread, hoping to attract comments from people who are familiar with V2Ray and know the state of the art. https://github.com/net4people/bbs/issues/36 There is a beginner's guide to setting up V2Ray: https://guide.v2fly.org/en_US/

1 2

Request for comments: Generalising BridgeDB
by Philipp Winter 09 Jun '20

09 Jun '20

We have been struggling with maintaining GetTor and BridgeDB because both projects have accumulated a considerable amount of technical debt. Besides, they implement similar tasks (generally speaking, they distribute resources to users), which means that we are maintaining redundant code. Given these issues, we have been thinking about generalising and merging GetTor's and BridgeDB's architecture. That could mean 1) turning GetTor into a BridgeDB distributor or 2) building a new system. The rest of this email discusses the latter option. Below is a diagram that proposes a design. On the left side, we have scripts and tools that take as input resources (e.g., bridge descriptors, Tor Browser download links, or even HTTPS or Snowflake proxy information) and write them to our resource DB. On the right side, we have several distributors (e.g., our existing Email/HTTPS/Moat distributors, but possibly also a Salmon, GetTor, or wolpertinger, our "hand bridges to OONI" distributor). In the middle sits the Matchmaker, which receives requests from distributors and answers them with data from our resource DB. ┌───────┐ │User DB│ ┌───────────┐ └───┬───┘ │Bridge desc├──┐ ┌─────┴─────┐ │ parser │ │ ┌─┤Salmon dist│ └───────────┘ │ │ └───────────┘ ┌────────────┐ │┌───────────┐ ┌──────────┐ │ ┌─────────┐ │Tor Browser ├─┼┤Resource DB├─ SQL─┤Matchmaker├ TCP ┼─┤Moat dist│ │link scraper│ │└───────────┘ └──────────┘ │ └─────────┘ └────────────┘ │ │ ┌───────────┐ ┌────────────┐ │ └─┤GetTor dist│ │Snowflake or├─┘ └───────────┘ │https proxy?│ └────────────┘ Cecylia suggested that all (or some) of these components can live in separate processes. That has the following advantages: * The system becomes easier to maintain and test. * We can build distributors in different languages. * A failing distributor doesn't affect the rest of the system. * A distributor doesn't have direct access to our database. For now, let's assume that distributors talk to the Matchmaker over TCP and use a protocol like JSON, gob, or protobufs. When a distributor asks the Matchmaker for a resource, it provides the following information: * The resource type (e.g., an obfs4 bridge) * A client-specific ID (e.g., its IP address) * The client's location (e.g., Russia) The Matchmaker then responds with one or more resources, similar to how BridgeDB currently does it. If any of these resources go offline at some point, the Matchmaker should notify the distributor so it can react accordingly. I would love to hear your thoughts on the above, even if it's far from comprehensive. Do you think that the above design sketch accommodates our present and foreseeable future needs? Cheers, Philipp

1 0

ftp file transfers have no protocol headers?
by Roger Dingledine 03 Jun '20

03 Jun '20

Hi folks, I was trying to help a user in #tor to get their ftp server running behind an onion, and rediscovering the ftp protocol's weird separation between the control channel and the file transfer channels, and I realized it could be interesting in the obfs4 / "unclassifiable protocols" context. To recap, when you ftp a file, you connect to port 21, and tell it you want to download a file. In the modern era, clients and servers use "passive mode" by default, where the server opens a high-numbered port, and you connect to that port and it dumps the file on you. I might be mistaken (please tell me if I am), but I believe there are no protocol headers or preamble or handshake or anything to the download. You just connect and the bytes start flowing. If this is so, and if ftp were still popular, then there are a bunch of high-numbered-port connections which will be hard to classify by protocol because they are simply a file, on the network. Of course, many files have structure of their own, including some "header"-like preface that e.g. says it's a zip file. By that reasoning, a variant of obfsproxy that wrapped Tor traffic to look like a password-protected zip file could give it many other things to blend with on a large network like China's backbone. (Compression is good but not enough, because DPI engines already know how to uncompress a zipped flow to look inside it. So we need some sort of encryption or password or the like too.) By that reasoning also, it might be interesting to separate the two directional flows in an obfs connection -- i.e. so there's a "download" flow, and a separate "upload" flow. This approach will surely look weird in some contexts (two flows rather than one, and no ftp control connection, gotcha), but maybe in other contexts it will have many friends -- I'm thinking network backbones where there are many flows, many users are natted, and it's expensive to try to tie together state between permutations of flows. If you google for 'why is ftp still used' you find a bunch of articles lamenting that people won't move away from it, and especially that large orgs won't move away from it. Maybe some of those large orgs are reasoning that if they secure the files contents themselves, then the transfer protocol doesn't matter so much. That scenario would play well into our goals of having a bunch of high-entropy files being passed around with no protocol headers. Hm, --Roger

2 1

Plans for BridgeDB's future
by Philipp Winter 14 May '20

14 May '20

This email introduces our plans for BridgeDB's future. I attached a diagram that illustrates how these plans integrate into BridgeDB's existing design. Red components in the diagram (Salmon, bridgestrap, and wolpertinger) are new, and in the process of being built. I introduce these components below. The Salmon social distributor --------------------------------- A PETS'16 paper introduced the Salmon social proxy distributor: <https://censorbib.nymity.ch/#Douglas2016a> In a nutshell, Salmon hands out bridges to users while maintaining per-user reputation scores. Alice's reputation goes up if her bridge remains unblocked after she got it, and it goes down if the bridge is blocked after Alice got it. Users can invite each other, which results in an invitation graph. Eventually, we will hopefully have a Salmon distributor which will live alongside our Moat, HTTPS, and Email distributors. If this interests you, consider attending our anti-censorship meeting on May 14 because we will be discussing the Salmon paper as part of our reading group: <https://trac.torproject.org/projects/tor/wiki/org/teams/AntiCensorshipTeam#…> We are only just starting to think about Salmon, so I have no code or design to share at this point. All that matters for now is that Salmon needs to know where bridges are blocked. BridgeDB does not have this information but the following software components seek to fix that. Bridgestrap ----------- Bridgestrap exposes an API that takes as input a bridge line and responds by telling you if it could establish a Tor circuit over the given bridge. BridgeDB will check with bridgestrap if the bridges it's about to hand out actually work. This isn't always the case as the following ticket shows: <https://bugs.torproject.org/30441> We have a working prototype of bridgestrap: <https://gitlab.torproject.org/phw/bridgestrap> We coordinate development in this ticket: <https://bugs.torproject.org/31874> Wolpertinger ------------ Wolpertinger exposes an API that lets censorship measurement platforms like OONI request bridges to measure. Wolpertinger later fetches OONI's test results and feeds them back into BridgeDB's bridge database. This allows BridgeDB to take into account a user's location when distributing bridges: a user in Turkey won't be given bridges that are known to be blocked in Turkey. In addition to OONI, we could repurpose bridgestrap as another censorship measurement tool by setting it up on a VPS in, say, Turkey and have wolpertinger periodically feed it bridges to test. Wolpertinger is work in progress but we already have some code: <https://gitlab.torproject.org/torproject/anti-censorship/wolpertinger> We coordinate development in this ticket: <https://bugs.torproject.org/32740> A practical example ------------------- To illustrate how these pieces fit together, let us consider the example in the attached diagram. Imagine that the bridge 1.2.3.4:1234 was just set up and reported itself to Serge, our bridge authority. Serge syncs its bridge descriptors to BridgeDB every 30 minutes and BridgeDB reloads those descriptors every 30 minutes, so it takes a maximum of 60 minutes until BridgeDB knows about this new bridge. Now, a user from Turkey requests a bridge over HTTPS. Since BridgeDB sees the user's IP address, it knows that the request is coming from Turkey. First, BridgeDB will ask a local instance of bridgestrap if the bridge it intends to hand to the user is working. This is important because the only testing we currently have in place is done by the bridge authority, which makes sure that a bridge's OR port is reachable. Nothing is testing a bridge's obfs4 port, which means that a user may end up with a bridge whose obfs4 port is firewalled. Bridgestrap can tell BridgeDB if a bridge is functional but it doesn't know if the bridge is blocked in Turkey. This is where wolpertinger comes in. Wolpertinger works in an asynchronous manner to BridgeDB and 1) hands out bridges to OONI probes, 2) collects OONI's test results, and 3) writes these results back to BridgeDB's bridge database, allowing BridgeDB to learn if a given bridge is blocked in Turkey. If everything works out, our user will receive bridges that are functional and unblocked in Turkey. Please let me know if you have questions or feedback. Cheers, Philipp

2 1

2024

2023

2022

2021

2020

2019

anti-censorship-team