Dropping packets with TCP MSS=1400 to foil GFW active probing
A paper from FOCI 2018 by Arun Dunna, Ciarán O'Brien, and Phillipa Gill on the subject of Tor bridge blocking in China has this interesting suggestion (Section 5.2): https://www.usenix.org/conference/foci18/presentation/dunna To do this, we write a series specific rules using iptables in order to drop packets from Chinese scanners. ... We use a rule to drop incoming Tor packets with an MSS of 1400. Further investigation would be needed to analyze potential false positives... We note that this method of dropping scan traffic successfully keeps our bridge relays from being blocked and allows our client in China to maintain access to the bridge. Like https://github.com/NullHypothesis/brdgrd, surely this trick won't work forever, but if you're setting up a new bridge, it's worth a try? This is completely untested, but I think the iptables rule would look something like this: iptables -A INPUT --protocol tcp --dport [your-bridge-port] -m tcpmss --mss 1400 -j DROP Then, after a while, check /var/lib/tor/stats/bridge-stats and see if you have any connections from "cn".
Is China successfully probing OBFS4 bridges? Or does this apply more to non obfs bridges? On Sun, Aug 19, 2018 at 6:57 PM David Fifield <david@bamsoftware.com> wrote:
A paper from FOCI 2018 by Arun Dunna, Ciarán O'Brien, and Phillipa Gill on the subject of Tor bridge blocking in China has this interesting suggestion (Section 5.2):
https://www.usenix.org/conference/foci18/presentation/dunna To do this, we write a series specific rules using iptables in order to drop packets from Chinese scanners. ... We use a rule to drop incoming Tor packets with an MSS of 1400. Further investigation would be needed to analyze potential false positives... We note that this method of dropping scan traffic successfully keeps our bridge relays from being blocked and allows our client in China to maintain access to the bridge.
Like https://github.com/NullHypothesis/brdgrd, surely this trick won't work forever, but if you're setting up a new bridge, it's worth a try?
This is completely untested, but I think the iptables rule would look something like this: iptables -A INPUT --protocol tcp --dport [your-bridge-port] -m tcpmss --mss 1400 -j DROP
Then, after a while, check /var/lib/tor/stats/bridge-stats and see if you have any connections from "cn". _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
On Sun, Aug 19, 2018 at 07:41:26PM -0400, Nathaniel Suchy wrote:
Is China successfully probing OBFS4 bridges? Or does this apply more to non obfs bridges?
China doesn't dynamically probe obfs4 bridges. (More precisely: they may try to probe, but the probes don't result in blocks for obfs4.) They only block obfs4 bridges whose addresses they learn in other ways. The MSS=1400 trick works, the authors report, even for non-obfuscated bridges.
Interesting. Is there any reason to not use an obfuscated bridge? On Mon, Aug 20, 2018 at 2:16 PM David Fifield <david@bamsoftware.com> wrote:
On Sun, Aug 19, 2018 at 07:41:26PM -0400, Nathaniel Suchy wrote:
Is China successfully probing OBFS4 bridges? Or does this apply more to non obfs bridges?
China doesn't dynamically probe obfs4 bridges. (More precisely: they may try to probe, but the probes don't result in blocks for obfs4.) They only block obfs4 bridges whose addresses they learn in other ways. The MSS=1400 trick works, the authors report, even for non-obfuscated bridges. _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
On Mon, Aug 20, 2018 at 02:25:40PM -0400, Nathaniel Suchy wrote:
Interesting. Is there any reason to not use an obfuscated bridge?
No, not really. obfs4 resists active probing without any special additional steps. But I can think of one reason why the MSS trick is worth trying, anyway. Due to a longstanding bug (really more of a design issue that's hard to repair), you can't run an obfs4 bridge without also running a vanilla (unobfuscated) bridge on a different port on the same IP address. So if anyone ever connects to that vanilla port, the bridge will get probed and the entire IP address blocked, including the obfs4 port. https://bugs.torproject.org/7349
Hi David, Couldn't I firewall the non-obfs port so only looback addresses may access it? Cordially, Nathaniel Suchy On Tue, Aug 21, 2018 at 11:37 AM David Fifield <david@bamsoftware.com> wrote:
On Mon, Aug 20, 2018 at 02:25:40PM -0400, Nathaniel Suchy wrote:
Interesting. Is there any reason to not use an obfuscated bridge?
No, not really. obfs4 resists active probing without any special additional steps. But I can think of one reason why the MSS trick is worth trying, anyway. Due to a longstanding bug (really more of a design issue that's hard to repair), you can't run an obfs4 bridge without also running a vanilla (unobfuscated) bridge on a different port on the same IP address. So if anyone ever connects to that vanilla port, the bridge will get probed and the entire IP address blocked, including the obfs4 port. https://bugs.torproject.org/7349 _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
On 22 Aug 2018, at 02:16, Nathaniel Suchy <me@lunorian.is> wrote:
Couldn't I firewall the non-obfs port so only looback addresses may access it?
For a private or hard-coded bridge, you can firewall your ORPort and set: AssumeReachable 1 Public BridgeDB bridges need an ORPort to pass bridge authority reachability checks. T
participants (3)
-
David Fifield -
Nathaniel Suchy -
teor