Opened 6 weeks ago

Last modified 5 weeks ago

#32026 new enhancement

Using An Alternative To TCP To Avoid Packet Injection?

Reported by: Aphrodites1995 Owned by:
Priority: Medium Milestone:
Component: Circumvention/Censorship analysis Version:
Severity: Normal Keywords:
Cc: dcf Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

According to https://www.cs.tufts.edu/comp/116/archive/fall2016/ctang.pdf , the GFW only injects packets, mostly TCP RST signals. 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. With the DNS inspection, we could have IPs for bridges/servers, which do the DNS queries on non censored DNS servers.

Child Tickets

Change History (7)

comment:1 in reply to:  description Changed 6 weeks ago by dcf

Replying to 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.

Here's a proof-of-concept tool to ignore RST packets:

See also the 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.

comment:2 Changed 6 weeks ago by Aphrodites1995

So how exactly does the GFW get the IPs to ban? Do they have only tor running on a single system, then packet capturing everything that comes out of it? How do you avoid them getting these IPs now?

comment:3 in reply to:  2 ; Changed 6 weeks ago by dcf

Replying to Aphrodites1995:

So how exactly does the GFW get the IPs to ban?

That's a big topic. See Ten ways to discover Tor bridges. In China, it's some combination of at least the following techniques:

  • Harvesting addreses from BridgeDB (this is private obfs4 bridges work, but ones from BridgeDB do not).
  • Extracting hard-coded addresses from source code or executable packages.
  • Running a client copy of Tor or Tor Browser in a black-box fashion and recording the addresses it connects to.
  • Running middle nodes and recording the addresses that connect to them.
  • Identifying the Tor protocol by its TLS handshake (when pluggable transports are not used).
  • Active probing to check whether a server really is a Tor bridge (works on plain Tor and obfs3, does not work on meek and obfs4).

The blocking techniques affect more than Tor. Here is some of the background research.

There are short summaries of some of these papers at https://www.bamsoftware.com/papers/thesis/summaries.txt and
https://groups.google.com/d/msg/traffic-obf/-z0gzKONGtI/r07EA8hUAAAJ.

How do you avoid them getting these IPs now?

By using pluggable transports that are resistant to active probing and passive detection, which at the moment is obfs4 and meek.

comment:4 in reply to:  3 ; Changed 6 weeks ago by arma

Replying to dcf:

In China, it's some combination of at least the following techniques:

  • Running middle nodes and recording the addresses that connect to them.

Wow, is this one thought to actually be happening? Citation or details? :)

If so, we could conceivably run some private obfs4 bridges and connect to public relays in an ordered fashion to figure out which ones are watching, "bad relays trap" style.

comment:5 Changed 6 weeks ago by Aphrodites1995

If obfs4 is resistant, why doesn't it work in china? Is it because of the middle node problem? So then why can't we just have one proxy as a node, and not do the onion thing, or at least make that an option? (I know TOR stands for The Onion Router, but it would be okay to betray the name for the sake of anti censorship, right? Also, is it possible for the GFW to read messages encrypted in TLS? If it couldn't, there is a whole lot of unreadable traffic out there, and obfs4 should be resistant, right?

Last edited 6 weeks ago by Aphrodites1995 (previous) (diff)

comment:6 in reply to:  4 Changed 5 weeks ago by dcf

Replying to arma:

Replying to dcf:

In China, it's some combination of at least the following techniques:

  • Running middle nodes and recording the addresses that connect to them.

Wow, is this one thought to actually be happening? Citation or details? :)

If so, we could conceivably run some private obfs4 bridges and connect to public relays in an ordered fashion to figure out which ones are watching, "bad relays trap" style.

Sorry, it was a mistake to list the middle-node technique under the China heading. As far as I know, there's no evidence that the GFW does that.

comment:7 in reply to:  5 Changed 5 weeks ago by dcf

Replying to Aphrodites1995:

If obfs4 is resistant, why doesn't it work in china? Is it because of the middle node problem?

obfs4 does work in China, as far as I know, but only if you use a private bridge. You can't use the "obfs4" dropdown in Tor Browser, because that uses a hardcoded list of default bridges, and all of them are already blocked. Users who set up their own obfs4 bridge or have a friend do it are able to use obfs4, but that is only a tiny fraction of users. See https://censorbib.nymity.ch/#Matic2017a. The hard problem here is address distribution--you need to distribute proxy addresses to your potential users, but somehow also prevent a censor from learning all of them and blocking them. Tor's answer to address distribution is BridgeDB, but it's not good enough against China. (And there aren't enough running obfs4 servers listed in BridgeDB to make enumeration really challenging.)

So then why can't we just have one proxy as a node, and not do the onion thing, or at least make that an option? (I know TOR stands for The Onion Router, but it would be okay to betray the name for the sake of anti censorship, right? Also, is it possible for the GFW to read messages encrypted in TLS? If it couldn't, there is a whole lot of unreadable traffic out there, and obfs4 should be resistant, right?

Of course you can separate circumvention from onion routing. There are plenty of circumvention systems that don't try to provide anonymity, like Psiphon, Lantern, and Shadowsocks. And in fact they and Tor use the same or similar circumvention techniques. Just run one of those, if you don't need the additional features of Tor.

Middlebox firewalls cannot passively decrypt TLS traffic. There is a lot of unreadable traffic, and that is probably why obfs4 and similar protocols are effective, as long as the IP address is not known to be an obfs4 server. But if you're a censor, once you have determined (by whatever means), that an IP address hosts an obfs4 server, you don't care about any passive protocol identification. You just block the IP address entirely. See https://www.bamsoftware.com/papers/fronting/#sec:related-work and the framing around "blocking by content" and "blocking by address." Blocking by address is the harder part; you need more than just protocol obfuscation to deal with that.

Note: See TracTickets for help on using tickets.