The Tor Censorship Analyzer (#7137 (moved))
Deliverable summary:
- Start a tool that a censored developer can run to discover why their Tor is failing to connect: brainstorm a list of "things to check", and sort them by how useful they'd be to check / how hard they'd be to build.
In short, the tool's purpose is to make the process of analyzing possible Tor censorship events easier and faster. At the moment, we heavily rely on cooperating users who are often no tech people. Instead of teaching them how to run wireshark and generate traffic, it would be great to just say "hey, please run this tool!".
Deliverable goal: In the first step we need a comprehensive list of features, how relevant they are and how hard they are to implement. All these requirements should then be summed up in a blog post or a tech report by the end of February.
Deliverable deadline: 28. Feb. 2013.
Please feel free to modify and add stuff and to share your opinion.
What should the tool be able to do?
Below is a list of features which we want to have.
- Connect to the directory authorities and check if it's possible to download the consensus. Probably easy.
- Check if https://bridges.torproject.org is reachable. Probably easy.
- Connect to public relays and (private) bridges and see whether the connection succeeds. Probably easy.
- Connect to private bridges with brdgrd and other patches applied and see whether the connection succeeds. Probably easy.
- Debug the TLS connection setup step by step to determine TLS-based blocking. This might need server support unless we manipulate for example TTLs so that the TLS client hello never reaches the relay/bridge. Depending on how detailed we want the results, this might be tricky or even hard to implement.
- Test pluggable transports (obfs2, obfs3?) or flash proxies for reachability. This might need some work.
- Collect information about the user's environment (ISP, ASN, traceroutes). This is very sensitive information. Probably rather easy to implement.
- Create a pcap of the debugging process to allow us further inspection. While very handy, pcaps are highly sensitive data and would require administrator access. Probably easy.
- Reconstruct possible DPI fingerprints. daphne was designed for this purpose and could be integrated. This is a hard problem.
- Test other services and protocols for reachability to rule out interferences which might lead to wrong interpretation. For example: Is all TLS traffic blocked/throttled? Is the user behind a captive portal which only allows data going over an HTTP proxy? This is probably rather hard since we have to consider plenty of things.
- Optional: Output the test results in a user friendly way (e.g. "vanilla Tor does not work, so try obfsproxy"). That way, users could run the tool without our help and solve their own problems. It might also reduce the problems the helpdesk has to deal with. Probably easy to implement but it will need some effort to be actually useful in practice.
How should the tool be designed?
The architecture will be influenced by the features we want to have (see above).
- Ease of use is crucial! It will eventually be run by users. Ideally, users should just click on it.
- Ideally, the tool should not require Administrator/root access.
- No need to reinvent the wheel: Ideally, it should be part of OONI.
- We have to see the results eventually. How does the data reach us? Do we want a client/server architecture with automatic data transmission or will the tool spit out data.zip which should then be mailed to us?
- We should keep the design of Tor Browser in mind. For example, our tool should also not leave any data traces such as pcaps behind.
- In case we have a client/server model: How do we keep the server(s) reachable? A censor could simply block our testing infrastructure to prevent analysis. Also, all our tests should not stand out and be indistinguishable from ordinary Tor/Web/... traffic.
- All the features should be testable. Otherwise, we might end up shipping code which does not work in "real" environments (see here for more details).