Measuring I2P Censorship at a Global Scale (FOCI 19)

[wkrp]

Measuring I2P Censorship at a Global Scale Nguyen Phong Hoang, Sadie Doreen, Michalis Polychronakis https://censorbib.nymity.ch/#Hoang2019a https://www.usenix.org/conference/foci19/presentation/hoang

This paper describes the first large-scale measurement study of the censorship of I2P. The authors tested for censorship of various aspects of I2P use: the main download web site and mirror sites, certain centralized bootstrapping servers, and the peer-to-peer relays that form the I2P network. They tested from about 1700 ASes and 164 countries, using VPN servers provided by VPN Gate. The main outcome is the detection of some form of I2P-related censorship in five countries: China, Iran, Kuwait, Oman, and Qatar; and in one academic network in South Korea.

This is the first research I am aware of that uses VPN Gate as a platform for censorship measurement. VPN Gate offers certain advantages over other techniques:

• VPN Gate servers are run by volunteers on their own PCs, in diverse networks including residential networks that are hard to access through commercial VPN services. There are about 5000 VPN Gate servers.
• VPN Gate, being a VPN service, allows direct and active tests across many layers of the network stack.
• VPN Gate servers are less likely to obscure their true geolocation or tamper with traffic (such as by injecting advertisements).

VPN Gate also has some drawbacks:

• There is high churn of servers and servers are not always online, only when their operator's PC is turned on. Measurements are only possible on an as-available basis.
• VPN Gate uses standard VPN protocols, like OpenVPN, that are not especially covert. As VPN Gate is a circumvention tool, firewalls that attempt to block circumvention may also prevent access to VPN Gate servers.
• VPN Gate volunteers do not specifically opt in to performing censorship measurement in the same way that OONI or ICLab volunteers do, but there is at least a greater degree of informed consent about proxying other people's traffic than exists with other peer-to-peer VPN services.

Overall, the authors consider VPN Gate not as a replacement, but as a complement to other measurement techniques.

The objects of testing are four parts of I2P that are possible targets of blocking:

• The main web site, https://geti2p.net/, from which the I2P software may be downloaded, and mirror sites like http://i2p-projekt.de/.
• Reseed servers, which are static, centralized servers that provide a new I2P client with enough information to bootstrap itself into the network.
• I2P relays. By design, and in contrast to Tor, each I2P relay does not know about all the others. The authors ran and tested their own I2P relays, which avoids problems with the unpredictable churn of third-party relays, and concerns about logging traffic that may be connected to a person.

The authors consulted I2P's guidelines for research and worked with members of the I2P team in designing their experiments.

The tests found some form of I2P-related blocking in six countries. In Iran, the mirror site (HTTP) but not the main site (HTTPS) were blocked by TCP injection of an HTTP 403 response. The same was the case in Kuwait, though only in 1 AS out of 6 available for testing. In Oman and Qatar, both the mirror site and main site were blocked by TCP injection, of an HTTP response in the case of HTTP, and of a TCP RST packet in the case of HTTPS.

In China, there was DNS poisoning of the main web site (but not the mirror site), as well as 3 out of 10 reseed servers. Some of the poisoned IP addresses are in the same subnets as have been observed in studies going back over a decade, such as in Lowe et al. 2007 (Table 2), Farnan et al. 2016 (§4.2), and Pearce et al. 2017 (Table 7). But there were also many previously undocumented IP addresses, including ones belonging to Facebook and SoftLayer—the reason for this is unknown. Inconsistently, AS 9808 differed from others in China, in that it poisoned some domains that others did not, using differently crafted packets. They did not find SNI filtering of I2P domains that were DNS-poisoned, illustrating a non-uniformity of blocking techniques: I2P domains are being treated differently than Wikipedia domains, which were documented by OONI to be blocked by both DNS and SNI. One academic network in South Korea, AS 1781, poisons the DNS of I2P domains, but it is likely according to a policy specific to the institution. Another two networks in South Korea sporadically poisoned DNS responses, but it looks like censorship leakage caused by proximity to China.

No blocking of I2P relays was observed anywhere.

An earlier paper on the topic of I2P censorship is An Empirical Study of the I2P Anonymity Network and its Censorship Resistance, evaluating I2P against a constructed, rather than naturally occurring adversary.

[ewust]

Is there any software for doing arbitrary measurement from VPN Gate (or other similar residential-based proxies like Luminati, Hola, etc). I think it'd be super useful to have a tool that lets a researcher craft a packet/connection, submit it to N hosts in country X, and then gets back a pcap or results for each host. One cool way could be a container of some kind (maybe docker, or even just a standard go API) that is setup to redirect its traffic to some measurement controller that (given a configuration) gets the traffic to exit from whatever residential-based proxies in country X and returns results (stdout logs from your custom script and/or pcaps).

Does anything approaching this already exist? I'm often finding myself asking questions like "I wonder what GFW/Iran/Country X does right now if you send a TLS/TCP/UDP/IP/IPv6 packet with the following features..." and usually the best answer is to spin up a VPS in the country which is often somewhat slow turnaround.

[wkrp]

Is there any software for doing arbitrary measurement from VPN Gate (or other similar residential-based proxies like Luminati, Hola, etc). I think it'd be super useful to have a tool that lets a researcher craft a packet/connection, submit it to N hosts in country X, and then gets back a pcap or results for each host. One cool way could be a container of some kind (maybe docker, or even just a standard go API) that is setup to redirect its traffic to some measurement controller that (given a configuration) gets the traffic to exit from whatever residential-based proxies in country X and returns results (stdout logs from your custom script and/or pcaps).

Does anything approaching this already exist? I'm often finding myself asking questions like "I wonder what GFW/Iran/Country X does right now if you send a TLS/TCP/UDP/IP/IPv6 packet with the following features..." and usually the best answer is to spin up a VPS in the country which is often somewhat slow turnaround.

VPN Gate uses standard VPN protocols, so anything you can make work with OpenVPN should also work with VPN Gate. The problem, of course, with standard VPN software is that by default it wants to take over your computer's default route, which is annoying and unhygienic when you're trying to run experiments. I don't exactly want my own web browsing, system updates, etc. to run over the VPN while I'm doing the experiment.

A few days ago I needed a vantage in Kazakhstan to check a web site that is only accessible from inside the country (Ref). To do it, I used a VPN Gate server in a Debian VM with OpenVPN. (Actually, it was Hoang et al.'s paper that reminded me VPN Gate could work for one-off tests like this.) First, I downloaded multiple samples from the VPN Gate server list:

while true; do wget http://www.vpngate.net/api/iphone/; sleep 900; done

Wget will create multiple files index.html, index.html.1, index.html.2... I let that run for a few hours until grep -i ,KZ, index.html* found a match. Then I took the OpenVPN_ConfigData_Base64 data, base64-decoded it, and saved it as kz.ovpn. Inside the VM, I installed the network-manager-openvpn-gnome package, which gives you an "Import a saved VPN configuration..." option under the Network Manager taskbar icon. After loading kz.ovpn, I could toggle the VPN on and off using Network Manager.

It may be possible to do something similar without a VM, using Linux network namespaces. I've used them before to capture the traffic of just a single process, without contamination from the rest of the system. I learned the trick from https://askubuntu.com/a/499850. $INTERFACE is your external network interface (e.g. eth0, wlan0) and $ADDRESS is your local LAN IP address (e.g. 192.168.0.100).

ip netns add net0
ip link add veth-a type veth peer name veth-b
ip link set veth-a netns net0
ip netns exec net0 ip address add 127.0.0.1/8 dev lo
ip netns exec net0 ip link set lo up
ip netns exec net0 ip address add 192.168.2.2/24 dev veth-a
ip netns exec net0 ip link set veth-a up
ip address add 192.168.2.1/24 dev veth-b
ip link set veth-b up
ip netns exec net0 ip route add default via 192.168.2.1 dev veth-a

mkdir -p /etc/netns/net0/
ln -sf /etc/resolv.conf /etc/netns/net0/

echo 1 > /proc/sys/net/ipv4/ip_forward
iptables -t nat -A POSTROUTING -s 192.168.2.0/24 -o $INTERFACE -j SNAT --to-source $ADDRESS

Now you can run commands inside the namespace with ip netns exec net0 <command>.

ip netns exec net0 ping example.com
ip netns exec net0 su myuser sh -c 'wget example.com'

You can even run a shell, and then everything that happens in that shell will be isolated to the network namespace.

ip netns exec net0 bash

To capture packets, just tcpdump -i veth-b from outside the namespace, or tcpdump -i veth-a from inside the namespace.

I haven't tried it, but likely you can run the openvpn command-line daemon inside the namespace, along with whatever command you want. To capture the in-VPN traffic, you'll have to tcpdump -i tun0 inside the network namespace.