[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
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@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@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/anti-censorship-team
On Sun, Apr 12, 2020 at 09:24:39AM -0400, Dave Levin wrote:
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.
Hi Dave,
We haven't gotten around to reading the Geneva paper yet but you may be interested in our reading group discussion log of SymTCP. Some of our thoughts may apply to Geneva too: http://meetbot.debian.net/tor-meeting/2020/tor-meeting.2020-04-16-17.59.log.html
Cheers, Philipp
anti-censorship-team@lists.torproject.org
-
Dave Levin -
Philipp Winter -
Roger Dingledine