Skip to content
Snippets Groups Projects

Switzerland

Last edited by Alexander Færøy

What it detects

Switzerland was a Python program developed by the Electronic Frontier Foundation, which aimed at detecting packet-level network interference in a protocol-agnostic manner. See the Switzerland Censorship Detection Tools Evaluation page for full outline of the project as it existed.

Inputs

An active connection between two clients.

Experiment

Alice and Bob connect both to each other, and also to a neutral observer, called Switzerland. Both Alice and Bob exchange asymmetric keys with the Switzerland server. After determining clock drift and a few other things (TODO: fill in specific setup problems from notes), Alice and Bob separately compute hashes of the headers for all packets sent and received from their own perspectives, and send these hashes to Switzerland for comparison. Switzerland then attempts to instruct Alice and Bob in masking out headers which have been modified due to common albeit benign quirks, such as those due to NAT routers. (Project Bismark might be able to provide more information on the ways that various routers modify packets.) When potentially malicious changes to a stream are detected, Switzerland requests the packet captures for that segment of the stream from both Alice and Bob for further analysis.

Control

This test would not be used to detect known censorship methods, but rather to discover the mechanisms of newly implemented ones.

Output

The report should output, in as readable/parse-able as possible format, a comparison of the stream segments where malicious activity was detected from both the perspectives of Alice and Bob.

Notes

  • This test should only be run after testing for traffic shaping, as such shaping would drastically reduce the number of non-masked out headers. Therefore, if OONI is to include it, it should only be run after a Network Latency/Traffic Shaping test, or else the Switzerland module should include it as a pre-test.

  • Switzerland used NTP to try to sync Alice, Bob, and Switzerland. If feasible, an alternate method for eliminating clock drift should be implemented. See Question !#1.

  • The unreliability of TCP's builtin state machine could cause errors in Alice/Bob submitting hash batches to Switzerland, and it might be worthwhile to use UDP with an alternate state machine, such as that used by Mosh, for communication between client and server. See Question !#2 (closed)

  • The heuristic for determining the "first" packet needs improvement.

  • Needs a good human-friendly way to display results. See Question !#3 (closed).

  • pde stated that there were libpcap performance issues, as well as the FastCollector.c circular buffer occasionally filling due to latency in either calculating hashes or in sending them to Switzerland.

  • Needs more testing/research on dynamic header masking. See Question !#4 (closed).

  • As it is passive, OONI clients would need some method of generating traffic, and either another client to connect to or an separate OONI server. See Question !#5 (closed).

Questions

  1. Can Jake's TLSdate, or a Python port of it, be used to replace NTP in this case?
    • Yes, I've read through the code and I believe it'll work just the same in Python.
    • We might be able to get around the required privileges by setting an time variable just for OONI, instead of for the system clock.
  2. Is it a good idea to implement an alternate state machine for client<->server communication?
  3. Does scapy have anything already that compares segments of streams?
  4. Does Project Bismark have more information on packet header modification done by specific routers?
  5. Should "Bob" be another OONI server (perhaps an M-Lab node) instead of another client?
    • This should probably be the default, but also give options for users to tests a P2P connection to a friend.

Comments

    Please register or sign in to add a comment.