Re: [tor-bugs] #32026 [Circumvention/Censorship analysis]: Using An Alternative To TCP To Avoid Packet Injection?

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#32026: Using An Alternative To TCP To Avoid Packet Injection?
-----------------------------------------------+------------------------
 Reporter:  Aphrodites1995                     |          Owner:  (none)
     Type:  enhancement                        |         Status:  new
 Priority:  Medium                             |      Milestone:
Component:  Circumvention/Censorship analysis  |        Version:
 Severity:  Normal                             |     Resolution:
 Keywords:                                     |  Actual Points:
Parent ID:                                     |         Points:
 Reviewer:                                     |        Sponsor:
-----------------------------------------------+------------------------

Comment (by dcf):

 Replying to [ticket:32026 Aphrodites1995]:
 > According to
 https://www.cs.tufts.edu/comp/116/archive/fall2016/ctang.pdf ;, the GFW
 only injects packets, mostly TCP RST signals.

 Well, that statement is not fully correct. While it's true that, according
 to our current understanding, the GFW cannot selectively drop single
 packets from a flow (but see https://censorbib.nymity.ch/#Marczak2015a for
 contrary evidence), the GFW is also capable of just blocking ''all''
 packets for a single IP address. That's how Tor relays and bridges are
 blocked, by IP blocking, not by RST injection. So a protocol that uses TCP
 tricks to avoid RST injection would not be helpful in unblocking Tor
 relays and bridges. As your reference acknowledges, as network protocols
 have become more encrypted, the firewall relies less on RST injection and
 more on IP blocking. See Section II of
 https://censorbib.nymity.ch/#Tschantz2016a for a brief overview of typical
 assumed censor capabilities.

 > What if TOR has bridges/servers that do not respond to TCP RST? This
 would render the connection interfering part of GFW useless. Here, a
 connection ends only when both sides send a "END" signal to the other side
 with their private key for the connection only that is shared through the
 connection. We don't even need to obfuscate TOR traffic anymore as the
 packets are not blocked.

 There's a history of research on this kind of idea, going back to 2006 at
 least. You may want to skim some of these to get up to speed.
  * [https://censorbib.nymity.ch/#Clayton2006a Ignoring the Great Firewall
 of China]
  * [https://censorbib.nymity.ch/#Khattak2013a Towards Illuminating a
 Censorship Monitor's Model to Facilitate Evasion]
  * [https://censorbib.nymity.ch/#Wang2017a Your State is Not Mine: A
 Closer Look at Evading Stateful Internet Censorship]

 Here's a proof-of-concept tool to ignore RST packets:
  * https://github.com/darkk/rstlss

 See also the [https://github.com/net4people/bbs/issues/9 Turbo Tunnel]
 idea, among whose claimed benefits are decoupling the circumvention state
 from the state of any single TCP connection.

 There's no shortage of abstract ideas on this topic--what helps more is a
 concrete plan for implementation of a specific selection of ideas. But any
 plan would also have to have a good story regarding IP blocking and active
 probing--that's really the reason for protocol obfuscation.

 > With the DNS inspection, we could have IPs for bridges/servers, which do
 the DNS queries on non censored DNS servers.

 That is already how it works. Try this: `tor-resolve example.com`. When
 you're using Tor, all DNS queries are tunneled through the Tor circuit and
 resolved by the exit node.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/32026#comment:1>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online

_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs