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

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

Merging bridgedb and gettor?
by Roger Dingledine 14 May '20

14 May '20

Hi folks! I've been pondering our two tools, gettor and bridgedb, and realizing that conceptually they overlap in a bunch of ways. Does that mean, while Cecylia is exploring getting gettor back on its feet, we should make them overlap more in a technical sense too? Some initial thoughts: + Having fewer tools to maintain is an obvious win, in terms of fewer moving pieces, fewer things to explain to people, less mental energy. + Broadly speaking, they are both tools that want to support a variety of low bandwidth "access methods" for reaching them, and they use these access methods to tell users about "resources". - They have different threat models in terms of how they want to protect the resources they give out, which makes them have different preferences about which access methods will work best. + But they both have a notion of "these resources aren't suitable for giving to people in this location", that is, they both want to learn something about *where* the user will be trying to apply the resource, and they both want to pull in some external "constraints" data set. + And being able to reuse (share) access methods could still be a win. For example, if Gettor learns how to answer people over Telegram, then it becomes much easier for BridgeDB to experiment with answering people over Telegram. + The monitoring tools ("is it working, am I getting answers, are the resources it gives me appropriate") overlap a lot between the two. - They have different text they want to use when interacting with users, and maybe different ways of handling errors. So those differences won't go away. = There are external tasks that gettor wants to do, such as pushing Tor Browser to the various websites that make up the resources we return. But just as BridgeDB is growing external modules like Wolpertinger, it's reasonable that GetTor could have external modules that publish/mirror our packages to various sites. ? Is there a third thing that Tor wants to do, of the form "use this access method to give people this resource"? Generalizing from three would be even better than generalizing from two. Please use this initial brainstorming as a starting point and take this thread wherever it should best go. For example, maybe they should be two different front-ends and as much functionality as possible would be merged into a library that they both use. Or maybe gettor is essentially a smaller "lift" so it should become a module of what bridgedb does. Several options here. --Roger

2 1

Tor Project removed a ticket about censorship
by wtfareyouthinking＠secmail.pro 14 May '20

14 May '20

What the F are you thinking, Tor Project? Why did you delete ticket #24351 and some documents instead of locking it? And why I can't make a comment or create a ticket on trac.torproject.org about this? You're developing Tor and telling people to resist censorship yet you've helped spammer to achieve their objective - deface anti-Cloudflare related documents/tickets. I really don't understand why you did this. I suggest you restore ticket #24351 and lock it.

1 0

Weekly team meetings now at 16:00 UTC
by Philipp Winter 11 May '20

11 May '20

Hi all, >From now on, anti-censorship team meetings will start at 16:00 UTC instead of 18:00 UTC. See you all on Thursday, 16:00 UTC in #tor-meeting! I updated our meeting pad, our team wiki page, and our Google calendar. Cheers, Philipp

1 0

Moving weekly meeting time to 16:00 UTC?
by Philipp Winter 08 May '20

08 May '20

To make it easier for folks in Asia to attend our meeting, I'm proposing moving it to 16:00 UTC, which is two hours earlier than our current meeting time. Is there anyone for whom this doesn't work? If so, would 17:00 UTC work instead? Thanks, Philipp

2 1

Kazakhstan and Obfs4
by soncyq47 08 May '20

08 May '20

Here are my thoughts on Kazakhstan blocking Obfs4 >>kzblocked provided some more information on IRC. >>But you can bypass it by putting HTTP-like bytes inside the random padding of the obfs4 client handshake. The padding is ordinarily filled with random bytes. Filling the padding with zeroes does not bypass as reliably. I'm pretty confident I know how it works. DPI research papers merely deal with theoretical attacks, but Brandon Wiley bought copies of physical DPI hardware and knows exactly how it works. The main thing they do is look for signatures in the first 4 bytes of the first packet. The second main thing is look for packet lengths. In this case I believe it is the third most common attack which is to look at how frequently each byte value occurs to measure entropy. https://youtu.be/IfLh3tr2amk?t=1334 (start at 18:20 but 22:14 is where it gets relevant) The solution is to send more of certain byte values than others to decrease entropy. I find it interesting that someone on the ticket said FTE worked.

2 1

My Introduction_GSoC Student
by Hashik Donthineni 07 May '20

07 May '20

Hello everyone! My name is Hashik Donthineni (IRC: HashikD), I am a GSoC 2020 student. I will be working on* Snowflake Proxy on the Android *project with the help of my mentors Cecylia (Cohosh), Phillipp (phw). I am really excited to join the Tor team! Thank you all for giving me this exciting opportunity! Regards, D. Hashik

1 0

Development plan sketch for a DNS pluggable transport
by David Fifield 07 May '20

07 May '20

Earlier I posted how to use Tor through my new DNS tunnel. https://lists.torproject.org/pipermail/anti-censorship-team/2020-April/0000… https://www.bamsoftware.com/software/dnstt/#proxy-tor Here's a sketch of what development tasks would be needed to turn it into a proper pluggable transport. I estimate it would be about a GSoC's worth of work, though it's too late to be a GSoC project this year. It would be a good project for someone who wants experience with the mechanics of implementing a pluggable transport, using a circumvention component that's already working. - Replace command-line interface with managed goptlib interface. - Client ClientTransportPlugin dns exec dns-client Bridge dns 192.0.2.4:1 FINGERPRINT domain=t.example.com doh=https://dns.example/dns-query pubkey=0000111122223333444455556666777788889999aaaabbbbccccddddeeeeffff - Server ServerTransportOptions dns mtu=1232 ServerTransportPlugin dns exec ./dns-server - Make the server generate a keypair on first run, store it in pt_state like obfs4proxy. - Add uTLS to the client to disguise TLS fingerprint. - Add ExtOrPort support to the server. - For USERADDR, choose a distinguished placeholder client address. See the last paragraph of https://lists.torproject.org/pipermail/metrics-team/2020-March/001142.html - Bonus: Enhance the bridge configuration panel to enable configuring the resolver without kludges like "meek-google" and "meek-amazon". - Or ship with a list of resolvers and choose one at random. I don't know whether a DNS transport is deployable by default like other transports, but it could be a good thing to have in reserve.

1 0

Better bridge distribution methods
by soncyq47 06 May '20

06 May '20

>>*Browser fingerprinting* fails because if I try to get bridges from my desktop vs my laptop vs my cell vs at a library vs at an internet cafe, I will not be mapped to the same user. Additionally, if I make a change to my setup (switch from Firefox to Chrome, new monitor resolution, etc.) even on the same machine I likely would not be mapped to the same profile (or if I am, it seems that a censor would be able to generate enough profiles that they end up in several "trusted" groups). I'd also argue that collecting the browser fingerprints of some of the most vulnerable Tor users (those that need bridges) is a risk. While I trust the Tor project to maintain good data and security practices at present, am I confident that a new vulnerability won't arise, or a new 0 day that could be used to acquire the information Tor maintains? No - especially not with the value that a DB of fingerprints of those subverting censorship would be to a censor.<< Sure, you could get a few bridges, but it is not trivial easy for an adversary to get hundreds, therefore browser fingerprinting is effective. Even if you switch from Firefox to Chrome, some aspects of the fingerprint remain the same. There are even some fingerprint test websites that can fingerprint your device, cross-browser, ex: UniqueMachine. I’m not exactly sure what you mean Sam by trusted groups. If the censor gets several bridges, it’s not a big deal. In terms of what I said about grouping similar fingerprints together, I thought a simple way to do it would be to assume the first fingerprints are more legitimate and the censor shows up later. In terms of the anonymity risk. The way I see it is my suggestions should be a last resort for users. Obviously using Tor through an insecure distribution is much better than not being able to use Tor. If users can’t get a working bridge, they might switch to something dangerous like Ultrasurf, or who knows what the alternative is. >>*Social networks* fail because they are not usable by all users (whether by choice or by censorship). This approach will also require maintenance.<< Social networks may not scale well, but it more than compensates by being super blocking resistant. I think it requires less maintenance. >>I'll propose one more potential - PGP signing, which I think works better than the above three, but is far from perfect.<< I think you’re missing the aim. We are not merely trying to identify our users, but trying to prevent an adversary from creating too many identities. Unfortunately it seems like the more blocking resistant you make it, the more privacy invasive. Social networks are an exception. The censor may create as many identities as it wants, but it wont increase his knowledge of addresses. In a sense knowledge of a bridge is treated like an identity. And users must have knowledge of a bridge regardless of IP distribution. >>1. Reach-ability probing from adversarial regions (aka identifying burnt bridges)<< It seems obvious to me at least that in the stead of probing from enemies of the internet, we merely watch which countries are connecting to the bridges. If we see a consistent decrease from a country then we know something’s up. This is much safer. >>2. Ability for bridges to easily and quickly change IP address (refreshing a bridge)<< Don’t forget we need to also disable UpdateBridgesFromAuthority because it would be trivial to update the blacklist otherwise. Cheers

1 0