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

Next steps for unclassifiable protocols
by Roger Dingledine 03 Oct '20

03 Oct '20

Hi folks, Here are some brainstorming thoughts to get us started improving our "unclassifiable protocols" idea. ---------------------------------------------------------------------- For context, right now we have essentially one deployed design in this space, which is obfs4: https://gitweb.torproject.org/pluggable-transports/obfs4.git/tree/doc/obfs4… This protocol does a short handshake (one client message, one server message) to establish session keys, then it just sends bytes back and forth with an (additional) layer of encryption so no payload bytes assist an attacker with doing content-based protocol classification. ---------------------------------------------------------------------- One of the more thorough analyses of obfs4 comes from the FTE folks: https://www.freehaven.net/anonbib/#ccs2015obfsdetection where they show a classifier that assesses entropy of the first server-side packet, plus looking at the length of that initial message, and they can consistently pick out obfs4 flows with only a 0.25% false positive rate compared to background traffic they recorded at their university. That false positive rate is where it gets interesting: it sounds good until we realize that it means it flags 1 in every 400 flows as being obfs4, i.e. it falsely tags about 36000 flows in the 14M flow dataset. And the false positives aren't randomly distributed either: 1.22% of their SSL flows are falsely tagged as obfs4, and it's the ones where the SNI in the SSL handshake has a lot of entropy (because everything else in the SSL handshake is already random). Also, entire protocols like RTMP get caught up and tagged as obfs4, because their handshake starts out with a block of random bytes. A key takeaway is that if they ran this classifier, with its high true positive rate and low false positive rate, on a large country's network traffic, approximately none of the flows that it would tag as obfs4 would actually be obfs4. Their Section 7 in that paper has a good discussion of the base rate issues and how they apply here. Are there other papers that design or analyze classifiers for obfs4? ---------------------------------------------------------------------- The good news: It would seem that obfs4 is most effective in the "long tail of varied traffic" scenario. That is, considering the spectrum between "small corporate network" and "China backbone", obfs4 needs that more broad background traffic in order to make its false positives too painful to block. The bad news: I still worry about an attack that puts together many building blocks, each of which individually is like the "1% false positive rate" classifier in the above paper, but that together drive their false positive rate low enough that blocking is safe to do. One observation there is that the more complexity there is to a protocol, the harder it is to "really" look like it, i.e. to match it in all dimensions at once. Consider this lovingly handcrafted graph, where the X axis is how thoroughly we try to look like some expected protocol, and the Y axis is how close we can get to making the adversary unwilling to block us: 1_| |_1 | | |\ /| | \ / | | \ / | | \ / | 0_| \___________________________________________/ |_0 | | There's a huge valley in the middle, where we're trying to look like something, but we're not doing it well at all, so there is little damage from blocking us. The ramp on the right is the game that FTE tries to play, where in theory if they're not perfectly implementing their target protocol then the adversary can deploy a distinguisher and separate their traffic from the "real" protocol, but in practice there are enough broken and weird implementations of the protocol in the wild that even being "close enough" might cause the censor to hesitate. And the ramp on the left is our unclassifiable traffic game, where we avoid looking like any particular expected protocol, and instead rely on the long tail of legitimate traffic to include something that we blend with. Observation: *both* of these ramps are in the "broken in theory, but works in practice" situation. I started out thinking it was just the obfs4 one, and that the FTE one was somehow better grounded in theory. But neither side is actually trying to build the ideal perfect protocol, whatever that even is. The game in both cases is about false positives, which come from messy (i.e. hard to predict) real-world background traffic. One research question I wrestled with while making the graph: which ramp is steeper? That is, which of these approaches is more forgiving? Does one of them have a narrower margin for error than the other, where you really have to be right up against the asymptote or it doesn't work so well? For both approaches, their success depends on the variety of expected background traffic. The steepness of the right-hand (look-like-something) ramp also varies greatly based on the specific protocol it's trying to look like. At first glance we might think that the more complex the protocol, the better you're going to need to be at imitating it in all dimensions. That is, the more aspects of the protocol you need to get right, the more likely you'll slip up on one of them. But competing in the other direction is: the more complex the protocol, the more broken weird implementations there could be in practice. I raise the protocol complexity question here because I think it has something subtle and critical to do with the look-like-nothing strategy. Each dimension of the protocol represents another opportunity to deploy a classifier building block, where each classifier by itself is too risky to rely on, but the composition of these blocks produces the killer distinguisher. One of the features of the unclassifiable protocol that we need to maintain, as we explore variations of it, is the simplicity: it needs to be the case that the adversary can't string together enough building-block classifiers to reach high confidence. We need to force them into building classifiers for *every other protocol*, rather than letting them build a classifier for our protocol. (I'll also notice that I'm mushing together the notion of protocol complexity with other notions like implementation popularity and diversity: a complex proprietary protocol with only one implementation will be no fun to imitate, but the same level of complexity where every vendor implements their own version will be much more workable.) ---------------------------------------------------------------------- I've heard two main proposed ways in which we could improve obfs in theory -- and hopefully thus in practice too: (A) Aaron's idea of using the latest adversarial machine learning approaches to evolve a traffic transform that resists classifying. That is, play off the classifiers with our transform, in many different background traffic scenarios, such that we end up with a transform that resists classifying (low true positive and/or high false positive) in many of the scenarios. (B) Philipp's idea from scramblesuit of having the transform be parameterized, and for each bridge we choose and stick with a given set of parameters. That way we're not generating *flows* that each aim to blend in, but rather we're generating bridges that each aim to blend differently. This diversity should adapt well to many different background traffic scenarios because in every scenario some bridges might be identified but some bridges will stay under the radar. At first glance these two approaches look orthogonal, i.e. we can do both of them at once. For example, Aaron's approach tells us the universe of acceptable parameters, and Philipp's approach gives us diversity within that universe. Aaron: How do we choose the parameter space for our transforms to explore? How much of that can be automated, and how much needs to be handcrafted by subject-matter-experts? I see how deep learning can produce a magic black-box classifier, but I don't yet see how that approach can present us with a magic black-box transform. And as a last note, it would sure be nice to produce transforms that are robust relative to background traffic, i.e. to not be brittle or overfit to a particular scenario. Otherwise we're giving up one of our few advantages in the arms race, which is that right now we force the censor to characterize the traffic -- including expected future traffic! -- and assess whether it's safe to block us. There. Hopefully some of these ideas will cause you to have better ideas. :) --Roger

2 2

Better bridge distribution methods
by Philipp WInter 30 Apr '20

30 Apr '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

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

How moat works
by Philipp Winter 02 Apr '20

02 Apr '20

Here's Matt's email on how moat works. ----- Forwarded message from Matthew Finkel <sysrqb(a)torproject.org> ----- [...] "meek-server" is (basically) the mirror-image of "meek", except it's on the server-side instead of the client-side - it decapsulates the request which was encapsulated by the meek client. Usually, this is the "pluggable transport bridge" running on some cloud VM (Google App Engine, MS Azure, AWS, etc.). It receives the normal incoming "transformed" traffic from the client, decodes it, and passes it onto the tor bridge. With moat, this configuration is tweaked a bit. Instead of running the meek-server and a tor bridge on a cloud vm, the meek server is running on the bridgedb server (and the incoming traffic is passed onto bridgedb rather than being passed onto the tor bridge). This means the cloud service is only being used for its CDN capability (and purely domain fronting), acting as a pass-through: from the client to the CDN to bridges.torproject.org, verses how meek is usually run where the tor bridge is running in the cloud, as well. With meek, there is an actual reflector VM where meek-server and the tor bridge usually run. With moat, the "reflector" is in name only, it simply associates the incoming connection with the CDN client configuration, so the CDN knows which client configuration it should look at for handling the traffic. Diagram of standard meek setup (which you probably already saw): https://trac.torproject.org/projects/tor/wiki/doc/meek#Overview The description of how this works is in this ticket: https://trac.torproject.org/projects/tor/ticket/16650 The general flow is: - Tor Browser's Tor Launcher creates HTTP request for https://bridges.torproject.org/moat - Tor Launcher starts a meek-client as a local proxy and pass in this request - The meek-client establishes a TLS connection with CDN (client -> https://ajax.aspnetcdn.com) - The meek-client then sends HTTP requests within this TLS tunnel where the host header is https://onion.azureedge.net and the body of the encapsulated request is the TCP stream for the HTTP request from Tor Launcher - This allows for creating the end-to-end TLS connection between Tor Launcher and BridgeDB - All traffic sent to the CDN is then proxied to https://bridges.torproject.org/meek (client -> CDN -> https://bridges.torproject.org/meek) - On the bridgedb server, there is an Apache webserver running that looks for incoming requests for /meek and redirects them to the meek-server running locally (client -> CDN -> https://bridges.torproject.org/meek -> meek-server) - The meek-server takes the incoming connections and decapsulates the enclosed request and passes it back to the Apache webserver (where the enclosed request is the TLS connection for https://bridges.torproject.org/moat) (client -> CDN -> https://bridges.torproject.org/meek -> meek-server (local) -> https://bridges.torproject.org/moat) - The Apache webserver then passes this request to BridgeDB for handling. Responses go in the reverse order. (client -> CDN -> https://bridges.torproject.org/meek -> meek-server (local) -> https://bridges.torproject.org/moat -> bridgedb) The result of this is the client establishes the usual TLS connection with the CDN (therefore using it as the domain-front), then all traffic is passed from the CDN onto bridges.torproject.org. Within that pass-through connection, moat establishes another end-to-end TLS connection with bridges.torproject.org. The ticket (29096) suggests changing how meek-server is currently run. Right now, it's simply a (hacky) shell script. My understanding of this is using ptadapter would simply be replacing the shell script with a maintained python program, but it'd provide essentially the same thing. https://gitweb.torproject.org/project/bridges/bridgedb-admin.git/tree/bin/r… The meek-server configuration is described here (if you're configuring it as a tor bridge). https://trac.torproject.org/projects/tor/wiki/doc/meek#MicrosoftAzure [...] ----- End forwarded message -----

1 0