Opened 4 months ago

Last modified 7 weeks ago

#28655 assigned defect

If a bridge supports obfs4, don't give out its other flavors

Reported by: arma Owned by: dgoulet
Priority: High Milestone:
Component: Obfuscation/BridgeDB Version:
Severity: Normal Keywords: bridgedb
Cc: Actual Points:
Parent ID: Points: 2
Reviewer: Sponsor: Sponsor19

Description

There's a FOCI 2018 paper looking at blocking of bridges inside China, and one of their conclusions is that China has moved from "block by IP:port" to "block to IP":
https://www.usenix.org/conference/foci18/presentation/dunna

If that is so, it means that when bridgedb gives out the vanilla ORPort of an obfs4 bridge, then some user will get it, try to use it from inside China, trigger the active probing, and get the whole IP address blocked -- including the obfs4 port.

The fix: when bridgedb gets a bridge that supports an active-probing resistant transport (right now that means obfs4), it needs to decide not to give out the other transports for that bridge (vanilla ORPort, obfs3, etc).

(There are two caveats for this plan. First, it means we're prioritizing obfs4 bridges for the China context, since all of these transports will still be useful for countries other than China. I'm ok with that. Second, it assumes that the FOCI paper is actually correct in its conclusions about how China has changed its blocking. I recall in the Q&A at the end of the presentation that some folks questioned the analysis, but I didn't follow it enough to form a solid opinion. But even if China isn't doing its censorship in this new way yet, now is a great time for bridgedb to become able to handle it.)

Child Tickets

Change History (7)

comment:1 in reply to:  description Changed 4 months ago by dcf

Replying to arma:

There's a FOCI 2018 paper looking at blocking of bridges inside China, and one of their conclusions is that China has moved from "block by IP:port" to "block to IP":

Second, it assumes that the FOCI paper is actually correct in its conclusions about how China has changed its blocking. I recall in the Q&A at the end of the presentation that some folks questioned the analysis, but I didn't follow it enough to form a solid opinion. But even if China isn't doing its censorship in this new way yet, now is a great time for bridgedb to become able to handle it.)

My, Lynn Tsai's, and Qi Zhong's monitoring of default Tor Browser bridges also reached this conclusion, that the GFW changed from single-port blocking to all-port blocking (at least for these special bridges). The change happened in October 2016.

https://www.bamsoftware.com/papers/thesis/#sec:china-perport
https://www.bamsoftware.com/papers/thesis/#sec:china-allports

The blocking event of October 20, 2016 was noteworthy not only because it occurred before a release, but also because it affected more than one port on some bridges. See point ⓗ in Figure 5.2. When GreenBelt:7013 was blocked, so were GreenBelt:5881 (which had escaped blocking in the previous batch) and GreenBelt:12166 (which was awaiting deployment in the next batch). Similarly, when MaBishomarim:7920 and JonbesheSabz:4148 were blocked, so were the Orbot-reserved MaBishomarim:1984 and JonbesheSabz:1984 (point ⓚ), ending an eight-month unblocked streak.

comment:2 in reply to:  description Changed 4 months ago by dcf

Replying to arma:

Second, it assumes that the FOCI paper is actually correct in its conclusions about how China has changed its blocking.

Zhongjie Wang, Yue Cao, Zhiyun Qian, Chengyu Song, and Srikanth V. Krishnamurthy observed the same in their INTANG paper, §7.3:

Meanwhile, any hidden bridge nodes requested by the remaining 7 vantage points triggers active probing [‌13, 31‌] and are immediately blocked by the GFW, i.e., any node in China can no longer connect to this IP via any port. This is very different from what was previously reported i.e., the GFW only blocks the Tor port on that hidden bridge [‌31‌], and could cause collateral damage as the Amazon EC2 IPs are recycled. We test 5 different hidden bridge IPs and find no exceptions so far.

This test was done between May 10 and May 18, 2017, according to my correspondence with the authors.

comment:3 Changed 3 months ago by gaba

Keywords: bridgedb added

comment:4 Changed 2 months ago by gaba

Owner: sysrqb deleted
Points: 2
Priority: MediumHigh
Status: newassigned

comment:5 Changed 7 weeks ago by dgoulet

Owner: set to dgoulet

comment:6 Changed 7 weeks ago by dcf

Linking #7349, which is like this ticket, but more comprehensive in that it would allow bridges not to expose their ORPort at all, not merely prevent BridgeDB from advertising it. That would also prevent mass-scanning discovery like

Last edited 7 weeks ago by dcf (previous) (diff)

comment:7 in reply to:  6 Changed 7 weeks ago by arma

Replying to dcf:

Linking #7349, which is like this ticket, but more comprehensive

I would say differently comprehensive, but not a superset of this one.

In this ticket, I want us to e.g. stop giving out the obfs3 port when there is an obfs4 port.

More broadly, if a bridge supports both active-probing-resistant and active-probing-vulnerable options, then we should give out only the active-probing-resistant ones.

Note: See TracTickets for help on using tickets.