[anti-censorship-team] Questions for the SymTCP paper

[Dave Levin]

Hi from the Geneva team,

Geneva is a genetic algorithm that we have trained to find ways to circumvent censorship through packet manipulation. Similar in outcome to SymTCP, but without requiring a model of TCP, and more easily applicable to new protocols. Within about an hour of gaining access to a box in Kazakhstan last summer, Geneva found ways to circumvent its new MitM HTTPS censorship.

We have some server-side packet-manipulation strategies that require no client-side modifications whatsoever. Several of them do not require root (like changing MSS). We also have client-side strategies that do not require root (like TCP segmentation, which was once thought to be no longer possible in China, but Geneva appears to have discovered bugs in the GFW).

Happy to discuss possibilities of application, or to train Geneva for you — we just need access to a box and application that are experiencing censorship. We tried training against active probing in China a little over a year ago but were unable to trigger it.

You can read more about Geneva at censorship.ai

Best,
Dave

> On Apr 12, 2020, at 5:01 AM, Roger Dingledine <arma at torproject.org> wrote:
> 
> [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
> 
> _______________________________________________
> anti-censorship-team mailing list
> anti-censorship-team at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/anti-censorship-team