Opened 7 months ago

Closed 5 months ago

Last modified 4 months ago

#29297 closed task (implemented)

Write reachability tests to verify if obfs4 is working or not

Reported by: chelseakomlo Owned by: cohosh
Priority: Medium Milestone:
Component: Archived/Obfsproxy Version:
Severity: Normal Keywords: obfs4, network-team-roadmap-2019-Q1Q2
Cc: cohosh, dcf, phw Actual Points:
Parent ID: #29279 Points: 2
Reviewer: dcf, ahf Sponsor: Sponsor19

Description (last modified by cohosh)

The main goal of this is to determine whether obfs4 bridges are being blocked due to bridge IP enumeration, or if there is something blockable about the obfs4 protocol.

These tests will use new, private (unpublished) obfs4 IP addresses that have not been used for censorship circumvention prior to these tests.

The outcome should be a script that users we reach out to in censored can run from which we can collect metrics about their ability to connect and bandwidth measurements. Before we send out the script we should figure out:

  • Whether we have all necessary metrics on the bridge side to verify if obfs4 is working and whether it is being throttled
  • How we are going to collect the client-side measurement data

Child Tickets

Attachments (1)

proxy-probe-bridgetest.tar.gz (6.6 KB) - added by dcf 5 months ago.
Export of bridgetest/ at commit 79f5fd646d49d1156b8ee50ec76b7e846ce348bb of https://www.bamsoftware.com/git/repo.eecs.berkeley.edu/proxy-probe.git

Download all attachments as: .zip

Change History (18)

comment:1 Changed 7 months ago by cohosh

Component: - Select a componentObfuscation/Obfsproxy
Status: newassigned

comment:2 Changed 6 months ago by cohosh

Status: assignednew

comment:3 Changed 6 months ago by cohosh

tickets are unassigned, reverting to 'new'

comment:4 Changed 6 months ago by gaba

Sponsor: Sponsor19

comment:5 Changed 6 months ago by gaba

Actual Points: 2
Points: 2

comment:6 Changed 6 months ago by cohosh

Description: modified (diff)
Owner: set to cohosh
Status: newassigned
Summary: Add any necessary metrics to verify if obfs4 is working or notWrite reachability tests to verify if obfs4 is working or not
Type: defecttask

comment:7 Changed 5 months ago by gaba

Keywords: network-team-roadmap-2019-Q1Q2 added

Changed 5 months ago by dcf

Export of bridgetest/ at commit 79f5fd646d49d1156b8ee50ec76b7e846ce348bb of https://www.bamsoftware.com/git/repo.eecs.berkeley.edu/proxy-probe.git

comment:8 Changed 5 months ago by dcf

We wrote some obfs4 testing scripts when we were testing in Kazakhstan. You can use them for inspiration. This is an export of the bridgetest/ directory in https://www.bamsoftware.com/git/repo.eecs.berkeley.edu/proxy-probe.git.

attachment:proxy-probe-bridgetest.tar.gz

[SITENAME] is an arbitrary identifier for the probe site
that you have to choose.

Add to crontab to run hourly tests:
	0 */1 * * * cd ~/kz && ./bridgetest.sh [SITENAME]

Generate a CSV file from logs:
	find log -name '*.log' | sort | ./makecsv > bridgetest.csv

Make a graph:
	Rscript graph.R bridgetest.csv

Some background is here:

https://www.bamsoftware.com/proxy-probe/kz-data/
https://www.bamsoftware.com/papers/thesis/#p200
doc/OONI/censorshipwiki/CensorshipByCountry/Kazakhstan#a20348-obfs4 (shows average bootstrap percentages)

The tarball I attached to this ticket is slightly newer than the bridgetest-20170525.zip linked there. kz-data-20170525.tar.xz has about 4 months of sample data from US and KZ, including pcaps.

Last edited 5 months ago by dcf (previous) (diff)

comment:9 in reply to:  8 ; Changed 5 months ago by cohosh

Replying to dcf:

We wrote some obfs4 testing scripts when we were testing in Kazakhstan. You can use them for inspiration. This is an export of the bridgetest/ directory in https://www.bamsoftware.com/git/repo.eecs.berkeley.edu/proxy-probe.git.

Thanks! These are very useful. I've forked this repo here: https://github.com/cohosh/bridgetest
and started making modifications for these new tests.

The first thing I did was modify bridgetest to take the bridge lines from an input file since we're using private bridges for this test: https://github.com/cohosh/bridgetest/commit/9a9f6603cba878f7dbf0193be38eb957b83d76ac

And I've added a large (~100M) file download to check for throttling. This might be too large, but no matter the size I'd suggest running this test perhaps 4x a day as opposed to every hour to reduce load on the bridges and the probe sites. This commit adds the file download: https://github.com/cohosh/bridgetest/commit/dcb9daaf41c2898b714291d012e3b06449016ee5

comment:10 Changed 5 months ago by cohosh

Status: assignedneeds_review

Putting this in needs_review to move things along... one thing I can think of that we might want is more granular large file download information as opposed to just "the time it takes to download the entire file". We can of course get this from tcpdump if we can capture on the probe site.

comment:11 Changed 5 months ago by ahf

Reviewer: dcf, ahf

comment:12 Changed 5 months ago by dcf

Cc: dcf added

comment:13 Changed 5 months ago by ahf

Resolution: implemented
Status: needs_reviewclosed

I think the code for this looks good. As there is nothing to merge as such, I'll close the ticket for now.

I think at some point we need to remember to move this code over to the mythical Gitlab instance once that is available.

comment:14 in reply to:  9 ; Changed 5 months ago by dcf

Replying to cohosh:

And I've added a large (~100M) file download to check for throttling.

Does this mean that there are multiple 100 MB pcaps being produced every day? That could be a lot of data to manage. Or are you not doing full packet capture for this part?

comment:15 in reply to:  14 Changed 5 months ago by cohosh

Replying to dcf:

Replying to cohosh:

And I've added a large (~100M) file download to check for throttling.

Does this mean that there are multiple 100 MB pcaps being produced every day? That could be a lot of data to manage. Or are you not doing full packet capture for this part?

I'm not planning on doing a full packet capture unless the overall results look suspicious, and then I will turn packet capture on to investigate more closely. Perhaps with a smaller file.

comment:16 Changed 5 months ago by phw

Cc: phw added

comment:17 Changed 4 months ago by phw

We briefly discussed the possibility of traffic throttling on IRC. Here's a summary:

  • We should check if the download's throughput decreases over time, i.e., is the first MB retrieved just as fast as the last MB?
  • Rumour has it that it takes "several minutes" for the GFW's traffic shaping to kick in [citation needed].
Note: See TracTickets for help on using tickets.