|
|
|
== What it detects ==
|
|
|
|
## 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 [wiki:doc/OONI/CensorshipDetectionTools/Switzerland Switzerland Censorship Detection Tools Evaluation page] for full outline of the project as it existed.
|
|
|
|
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](./doc/OONI/CensorshipDetectionTools/Switzerland) for full outline of the project as it existed.
|
|
|
|
|
|
|
|
== Inputs ==
|
|
|
|
## Inputs
|
|
|
|
|
|
|
|
An active connection between two clients.
|
|
|
|
|
|
|
|
== Experiment ==
|
|
|
|
## 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 ==
|
|
|
|
## Control
|
|
|
|
|
|
|
|
This test would not be used to detect known censorship methods, but rather to discover the mechanisms of newly implemented ones.
|
|
|
|
|
|
|
|
== Output ==
|
|
|
|
## 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 ==
|
|
|
|
## 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.
|
|
|
|
|
| ... | ... | @@ -36,9 +36,9 @@ |
|
|
|
|
|
|
|
* 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.
|
|
|
|
|
|
|
|
== Questions ==
|
|
|
|
## Questions
|
|
|
|
|
|
|
|
1. Can [https://github.com/ioerror/tlsdate Jake's TLSdate], or a Python port of it, be used to replace NTP in this case?
|
|
|
|
1. Can [Jake's TLSdate](https://github.com/ioerror/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?
|
| ... | ... | |
| ... | ... | |