GSoC 2022: Designing the middlebox and port-filtering experiments

[DecFox]

GSoC 2022: Designing the middlebox and port-filtering experiments

Introduction

The main objectives of this Google Summer of Code were to

• develop a TLS middlebox experiment: Designing and implementing an experiment to detect censoring middleboxes using iterative network tracing. (Much like traceroute but for the TLS ClientHello packet)

• design a port-filtering experiment: Designing an experiment to detect port-blocking censorship mechanisms using TCP connections and a test-helper.

In the following I will describe the deliverables of my GSoC experience, and link to the corresponding pull requests in the ooni/probe-cli repository.

I would like to thank @bassosimone and @hellais for their constant help and guidance throughout the summer.

Deliverable 1: Developing the TLS middlebox experiment

Issue: #2124

Pull Request: ooni/probe-cli#817

This experiment provides OONI users with the ability to experiment and determine the location of middleboxes that reset TCP connections. For instance, here is a measurement from India depicting the presence of a TLS middlebox at TTL=4, blocking SNI=1337x.be:
https://explorer.ooni.org/measurement/20220909T091529Z_tlsmiddlebox_IN_24560_n1_Wik9rh6YO610MfMY?input=tlstrace%3A%2F%2F1337x.be

The main objectives of this experiment were:

• Design an iterative tracing experiment for a TLS ClientHello packet record
  the response of each iteration

• Conclude the presence of a censoring TLS middlebox using the trace we obtain

The underlying methodology for the experiment is described here: https://iamkush.me/sni-airtel/. Traditionally, TCP-Traceroute tools make use of raw sockets which require elevated permissions to run (as documented in the article above). This presented as a challenge since our objective was to have an implementation which could run on all OONI platforms without the need of special privileges for the user. To this end, we create TCP connections with the default TTL and then reduce the TTL when initiating the TLS handshake.

On Unix, we capture ICMP soft errors in the TLS handshake using the SO_ERROR socket option. Unfortunately, this approach does not seem to work on Windows and further research is required. While we cannot locate middlebox addresses due to the inability to read the ICMP response, SO_ERROR allows us to provide extra data for measurements (in unix) which can be crucial in concluding the presence of a middlebox and the hop number associated with it.

Another current limitation of my implementation is that "normal" traceroute suffers from deficiencies pertaining to mutipath routing and load balancers where packets are routed based on flow-identifiers. This can lead to inconsistent tracing results for a single target due to variable source port values, making measurements difficult to analyse. This encouraged us to think about extended tracing methodologies like paris-traceroute (described here). During the summer, I spent some time researching over these.

We documented several ideas (like these) as further improvements we would like to see in the experiment here: #2270. I hope to continue working on these issues in the future.

Deliverable 2: Designing the port-filtering experiment

Issue: #2005

Pull Request: ooni/probe-cli#891

This experiment allows users to test if a particular port has been blocked due to a port-filtering mechanism. The use-cases can be extended to verify network shutdowns and scan for functioning ports (as in the case of Kazakhstan: https://ntc.party/t/network-shutdown-all-around-kazakhstan/1601/19)

The main objectives of this experiment were:

• Design an MVP for a port-filtering experiment with the ability to perform TCP connections to a set of ports

• Design a test-helper with the ability to listen for a TCP connection on a set of ports and deployed with OONI services

The idea of the new experiment was to make use of the netxlite package to perform a TCPConnect to a list of ports and conclude if the ports are subject to blocking. We concluded to extend the designed MVP a little more before deploying the test-helper.

Further improvements we want to implement are documented in the feedback here: ooni/probe-cli#891 (comment)

Deliverable 3: Working on the measurexlite package

Pull Request (simplequicping): ooni/probe-cli#852

Pull Request (dnsping): ooni/probe-cli#831

The need for a new network experiment methodology mainly stemmed from the need to use a new way of measurement for tlsmiddlebox. This methodology allowed us to split each operation independently, making it easier to process and analyze the data we collected on the probe side. It also allows us to provide more precise and actionable feedback to users, choose follow up measurements more carefully, all without needing to talk to the backend.

I contributed in designing this measurement methodology which came to be known as step-by-step, introducing a new tracing library called measurexlite. The idea was to move away from the wrapper-based approach in network experiments and introducing context-based tracing to store measurements concurrently. This redesign tied into my own tlsmiddlebox goals.

The design document can be accessed here: https://github.com/ooni/probe-cli/blob/master/docs/design/dd-003-step-by-step.md

As part of my contributions, I reviewed design documents and contributed some development effort to implement the new methodology for some selected sub-cases: implementing tracing support for DNS and QUIC implementations in netxlite. This was followed by changes to improve our initial implementation and refactoring the experimental simplequicping and dnsping nettests to use the new measurement methodology. Subsequently, I also used this strategy to implement the tlsmiddlebox experiment.

Other related work: ooni/probe-cli#857, ooni/probe-cli#864, ooni/probe-cli#867, ooni/probe-cli#918

Design Strategies and Bug fixes

In the meantime, I also worked on some design strategies and refactors closely related to measurexlite and DNS resolution. The subsequent work is attached here.

• DNS delayed responses in measurexlite (with help from @bassosimone): This was a valuable addition int the OONI measurement methodology since users can now detect delayed/late DNS responses. This serves the use-case when delayed legit responses are sent to the user after the censor has responded. This feature has been inculcated in the upcoming webconnectivity@v0.5 release: feat: context-based tracing to record delayed DNS responses probe-cli#870, feat: record delayed DNS responses in dnsping probe-cli#878

• Introduce context-based tracing in system resolver: feat: collect system resolver results using context probe-cli#856, feat: add support for system resolver in measurexlite probe-cli#858

I also worked on some PoCs to reflect possible implementation designs. These subsequently act as references for future changes and refactors.

• Introducing a TRR2 resolver (design PR): feat: TRR2 resolver  probe-cli#846

• Introducing a new input parser for experiments (design PR): feat: introduce input parser for experiments probe-cli#884

Using the tlsmiddlebox experiment

The tlsmiddlebox experiment can be run using the miniooni tool. Users can build and run using:

go build ./internal/cmd/miniooni
./miniooni tlsmiddlebox -ni tlstrace://1337x.be -O TestHelper=tlshandshake://example.com

Using the portfiltering experiment

You can run the experiment with a local test-helper.

Build and deploy testhelper locally

To run the testhelper:

go build ./internal/cmd/ooporthelper
sudo ./ooporthelper # reserved ports require elevated permissions

Build and run portfiltering

To run the experiment:

go build ./internal/cmd/miniooni
./miniooni portfiltering

[bassosimone]

Hey, @DecFox, thank you so much for opening this issue about your GSoC experience with us! Congratulations on your achievements so far and thanks a lot for helping out with improving how we design experiments! I am happy to see that tlsmiddleboxes has landed and can now be used for further testing! Looking forward to continuing to work together on the port filtering experiment PoC, collect more data, and make it land safely on the main branch! 🥳 🙏 💯

[bassosimone]

Thank you! I have completed the evaluation on GSoC, so we can close this issue now!