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

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

Better bridge distribution methods
by soncyq47 05 May '20

05 May '20

There are 4 parts. -- /1./ -- For those that are new let me explain my discussion with Philipp Winter. I suggest a browser fingerprinting based bridge distribution. Each fingerprint only gets one bridge, so if you keep automatically asking you just keep getting the same address over and over. I can tell you that it is almost impossible to exhaustively spoof a fingerprint, and we can use that to our advantage. We can group similar fingerprints together so that it doesn't matter if someone spoofs a few things. And we should ignore the user-agent. >>I think I'm missing something here. Doesn't it suffice for an adversary to tamper with a single feature to create a new browser fingerprint, and thus obtain different bridges? I suppose it would depend on how the server derives its fingerprints.<< Like I said: Once we've given out all the bridges to each unique fingerprint then we start grouping new fingerprints to the nearest match. In other words we assume the first users are more legitimate, and the GFW comes along later. So in the beginning we give out a new bridge to a fingerprint that is anyhow different from one we’ve seen before, and once we’ve given them all out (that we are willing to give out through fingerprinting), then if a new fingerprint comes along, he gets the same bridge as the fingerprint that had the highest quantity of same aspects to it. This defeats partial spoofing. Like I said, full spoofing is near impossible. -- /2./ -- >>I know lots of people in China using Linode and Google Cloud which also a credit card. They only support the credit card like VISA or MasterCard instead of China UnionPay card. So it isn't too hard if someone wants to get the card, especially is GFW who be described as "unlimited fund" by GFW technology review blog. They don't block the IP just because a few people use it. Yes, the credit card it did block a lot of people:(<< Thanks Tom for clearing up my misunderstanding. -- /3./ – Why not switch Obfs4 bridges to dynamic IPs and remove UpdateBridgesFromAuthority. This would make it like WAY more blocking resistant. -- /4./ – I take back what I said, I recon the Salmon algorithm is currently the best proxy distribution we have. I’m planning to read the paper, but just from what I’ve seen from the talk... https://www.invidio.us/watch?v=RO3wXRn8BfY … I see one major vulnerability: what if the GFW gets just one bridge, then creates thousands of accounts (which there is no barrier for), then sends an invite across all of those accounts, then waits for trust level to get high, and all of those accounts gets a new bridge, repeat until you know all the bridges, then only block them all in one go once they have all the addresses. The solution is to put a limit on how many addresses are given out per accounts with knowledge of a certain bridge. Basically extending the recommendation grouping that every bridge which accounts know only allows for a finite quantity of new bridges to be received. So an adversary that has one address can’t crawl the whole network, but only a fraction of it. Another but minor weakness, I don’t think social network based distribution would scale well compared to fingerprinting based distribution. I’m not claiming to know it all but hopefully my thoughts are helpful.

2 1

Better bridge distribution methods
by Philipp WInter 01 May '20

01 May '20

(Moving this discussion to anti-censorship-team@. See below for context.) On Wed, Apr 29, 2020 at 11:35:48PM +0000, soncyq47 wrote: > ---MY EMAIL HAS 3 PARTS SO PLEASE READ IT ALL--- > > > I believe it's feasible (albeit not trivial) for an adversary to modify > > these fingerprints, e.g., by making Firefox believe that it runs under a > > different screen resolution, has a variety of apps installed, etc. > > /1./ It's obviously possible to spoof a few things. The point I was > making is that there are like 20 or 50, if not more aspects of the > fingerprint, and we can measure it all, so it's practically impossible > to spoof them all. We could just then group similar fingerprints > together. I think I'm missing something here. Doesn't it suffice for an adversary to tamper with a single feature to create a new browser fingerprint, and thus obtain different bridges? I suppose it would depend on how the server derives its fingerprints. It's not a bad idea but I'm not convinced that the implementation effort would be worth the outcome. > > Another issue is that for this to work, we would have to store the > > fingerprint of requesting users and we would rather not store unique, > > user-specific identifiers. > > This problem might be slightly mitigated with federation. But I > totally agree with the privacy issue you're saying. > > /2./ I have a theory for why paid VPNs get blocked less, maybe the > operators of the GFW can't get access to an American credit card, so > the VPN doesn't have to worry about IP distribution, just the > encryption algorithm. I don't have any thoughts on this. > /3./ What about SMS distribution. I know there are tricks to get lots > of numbers, but what I've seen is usually limited to one country, so > we could just separate area codes into different distribution buckets. Again, not necessarily a bad idea but expensive to build. Our resources are very limited and we need to be rather confident that something works out before investing a substantial amount of development time. > Please reply about what you think of my 3 points. > Cheers > > > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ > On Wednesday, April 29, 2020 4:16 PM, Philipp WInter <phw(a)nymity.ch> wrote: > > > On Tue, Apr 28, 2020 at 09:52:29PM +0000, soncyq47 wrote: > > > > > Sorry I don't understand Selenium very well, but in terms of > > > automating, each fingerprint only gets one bridge, so if you keep > > > automatically asking you just keep getting the same address over and > > > over. > > > > I believe it's feasible (albeit not trivial) for an adversary to modify > > these fingerprints, e.g., by making Firefox believe that it runs under a > > different screen resolution, has a variety of apps installed, etc. > > > > Another issue is that for this to work, we would have to store the > > fingerprint of requesting users and we would rather not store unique, > > user-specific identifiers. > > > > Cheers, > > Philipp

2 1

Paper for May 14 reading group: Salmon
by Philipp Winter 01 May '20

01 May '20

I suggest, we read the PETS'16 paper "Salmon" for our May 14 reading group: <https://censorbib.nymity.ch/#Douglas2016a> I added it to our meeting pad at: <https://pad.riseup.net/p/tor-anti-censorship-keep> Cheers, Philipp

1 0

Reading group 2020-04-30: MassBrowser
by David Fifield 29 Apr '20

29 Apr '20

The topic of tomorrow's reading group is MassBrowser. https://censorbib.nymity.ch/#Nasr2020a https://massbrowser.cs.umass.edu/ The reading group follows the team meeting which begins at 18:00 UTC. https://trac.torproject.org/projects/tor/wiki/org/teams/AntiCensorshipTeam#… If you haven't had a chance to read the paper yet, here is a draft of my written summary. I plan to post it to net4people/bbs after hearing back from the authors. https://framabin.org/p/?803eae8e7a2829d8#hPFXVNDvLtX2c8D6h2Y1Il1z9RCfDE84zv…

1 0

Questions for the SymTCP paper
by Roger Dingledine 22 Apr '20

22 Apr '20

[redirecting from the original tor-project@ post to here] On Thu, Apr 09, 2020 at 11:34:29AM -0700, Philipp Winter wrote: > == Reading group == > > * We will discuss "SymTCP: Eluding Stateful Deep Packet Inspectionwith Automated Discrepancy Discovery" on April 16 > * https://censorbib.nymity.ch/#Wang2020a > * Questions to ask and goals to have: > * What aspects of the paper are questionable? > * Are there immediate actions we can take based on this work? > * Are there long-term actions we can take based on this work? > * Is there future work that we want to call out, in hopes that others will pick it up? Thanks Philipp. For those who like more structure for your readings, here are three Tor-oriented "homework" questions for you to think about while you're reading this paper: (1) Do any of the tricks that they come up with work, or help us find tricks that work, from entirely user space, like Tor or Tor Browser? If we can get past the initial "no, they're all packet-based tricks, so we'd need root at the least" to finding some that can be done with socket functions or the like, that would be really neat. (2) Are there promising techniques that only require root-level changes on the client side? In particular, could Tails ship with some kernel or iptables changes that make DPI engines not trigger on bridge handshakes? (Doing it to protect Tor handshakes for relays or popular bridges seems like a much harder problem, because if the censor blackholes the IP address when they see a verboten handshake, then *everybody* needs to talk to it in a safe way, or somebody else will get it blocked and now you can't use it either.) (3) How about only server-side? I'm imagining asking Linux bridge operators to run a few iptables rules to make their bridges more robust. (Like the old "drop the first 3 syn packets in a flow, because the GFW network stack is optimized to only send 3, but real OSes try more than 3 times" trick.) And for extra credit: can anything be done on Android or iOS? Or maybe better: what would it take to apply these ideas to Android Tor Browser / Orbot users, or to iOS Onion Browser users? Thanks! --Roger

3 2

How to run Tor Browser through a DoH/DoT tunnel
by David Fifield 20 Apr '20

20 Apr '20

I made a post about the DNS tunnel I have been working on. It uses a DNS over HTTPS or DNS over TLS resolver for covertness, and the interior of the tunnel follows the Turbo Tunnel design so the peers can be more free about when they send to each other. https://github.com/net4people/bbs/issues/30 It doesn't exist as a proper pluggable transport, but it's pretty easy to hack together a way to access a bridge through the tunnel. I made the linked post using Tor Browser through the DNS tunnel. It's just two steps. First, get the tunnel client software and run it with the proper parameters. git clone https://www.bamsoftware.com/git/dnstt.git cd dnstt-client go build ./dnstt-client -doh https://dns.google/dns-query -pubkey a8090ab2d7b918e69ed4b2340fcd9c2af33c08e3620af98fb9c6a460fb63f76d tor.rinsed-tinsel.site 127.0.0.1:7000 You can replace "https://dns.google/dns-query" with another server from https://github.com/curl/curl/wiki/DNS-over-HTTPS#publicly-available-servers Second, in Tor Browser, go to about:preferences#tor, select "Provide a bridge", and enter 127.0.0.1:7000 4D6C0DF6DEC9398A4DEF07084F3CD395A96DD2AD tor will connect to 127.0.0.1:7000 as if it were a remote bridge, but that port actually leads through the tunnel to the ORPort of my bridge giygas. What I had to do to set up the server side: first I went into the DNS configuration for my domain rinsed-tinsel.site and added the records A tns.rinsed-tinsel.site points to 192.81.135.242 AAAA tns.rinsed-tinsel.site points to 2600:3c01::f03c:91ff:fe73:b602 NS tor.rinsed-tinsel.site is managed by tns.rinsed-tinsel.site The A and AAAA records are the IP addresses of my bridge. Then I ran the following server commands (plus port forwarding for port 53). Notice that the tunnel server is configured to terminate the tunnel at the ORPort of the locally running tor bridge. ./dnstt-server -gen-key -privkey-file dnstt-tor.key -pubkey-file dnstt-tor.pub ./dnstt-server -udp :5300 -privkey-file dnstt-tor.key tor.rinsed-tinsel.site 192.81.135.242:9001 I won't commit to running the server part of the tunnel forever, but I'll leave it set up the way it is for a while in case you want to try it.

1 0

Join us for our reading groups (every two weeks)
by Philipp Winter 13 Apr '20

13 Apr '20

The anti-censorship team recently started experimenting with reading groups. The idea is to pick a paper or project, and we all read it over a period of two weeks, and then discuss it right after our anti-censorship IRC meeting. Here's the log of our first session, in which we discussed the paper "Detecting Probe-Resistant Proxies": <http://meetbot.debian.net/tor-meeting/2020/tor-meeting.2020-04-02-17.59.log…> <https://censorbib.nymity.ch/#Frolov2020a> We will post summaries of our discussions on the net4people BBS: <https://github.com/net4people/bbs/issues> Next up is the SymTCP paper, which we will discuss on Thursday, Apr 16: <https://censorbib.nymity.ch/#Wang2020a> We will announce future iterations of the reading group on our weekly IRC meeting pad: <https://pad.riseup.net/p/tor-anti-censorship-keep> Feel free to join us! Cheers, Philipp

1 0

2025

2024

2023

2022

2021

2020

2019

anti-censorship-team