======================================================================== Tor Weekly News January 14th, 2015 ========================================================================
Welcome to the second issue in 2015 of Tor Weekly News, the weekly newsletter that covers what’s happening in the Tor community. What to do if meek gets blocked ------------------------------- Regular readers of Tor Weekly News will be familiar with meek [1], the pluggable transport developed by David Fifield. Where most existing transports work by connecting clients to “bridge” relays that are difficult for the adversary to discover (or identify as relays), meek makes all of a client’s Tor traffic appear as though it is destined for a domain that is “too big to block” — in other words, web platforms so popular that a censor cannot prevent access to them without disrupting lots of unrelated Internet activity in its sphere of control — when in fact the traffic is sent to meek servers running on those platforms, which in turn relay it into the regular Tor network. Google, Amazon, and Microsoft are some of the services whose domain names currently work as disguises for meek. Unfortunately, that doesn’t mean meek is unblockable. As David wrote [2] to the tor-talk mailing list, “that’s the wrong way to think about the problem”. “It is designed to be difficult and expensive to block […] but suppose a censor makes that call, and blocks Google/Amazon/whatever. What then?” Two easy solutions are selecting a different backend (meek-amazon instead of meek-google, for example) or using a different DNS server: “The most common way to block a domain name is by DNS poisoning; i.e., the IP address behind the name is accessible, but the local DNS server gives you a false address. Try a public DNS server such as 8.8.8.8. But if that works, be aware that it’s probably only a temporary fix, as censors have historically figured out the alternate-DNS trick pretty fast.” “What you really want to do”, David suggested, “if the easy things don’t work, is choose a different front domain.” Please see David’s message for a fuller explanation of the difference between the backend and the “front domain”, and a guide to configuring new domains — as well as one to setting up your own meek web app, if all else fails. [1]: https://trac.torproject.org/projects/tor/wiki/doc/meek [2]: https://lists.torproject.org/pipermail/tor-talk/2015-January/036410.html Miscellaneous news ------------------ sycamoreone announced [3] orc, a Go library that implements parts of Tor’s control protocol. “I do have some ideas for a higher-level interface, but no fixed plan yet. The next step will probably be to add net/http-like handlerFuncs to handle (asynchronous) replies from the onion router.” [3]: https://lists.torproject.org/pipermail/tor-talk/2015-January/036425.html taxakis linked [4] to “Post-Quantum Secure Onion Routing” [5] by Satrajit Ghosh and Aniket Kate, a new paper proposing a successor to the currently-used ntor handshake protocol that would be “resilient against quantum attacks, but also at the same time allow OR nodes to use the current DH public keys, and consequently require no modification to the current Tor public key infrastructure.” Nick Mathewson wondered [6] whether “anybody around here has the cryptographic background to comment on the PQ part of their scheme?”, and compared it to Yawning Angel’s experimental “basket” protocol [7]. [4]: https://lists.torproject.org/pipermail/tor-talk/2015-January/036420.html [5]: http://eprint.iacr.org/2015/008 [6]: https://lists.torproject.org/pipermail/tor-talk/2015-January/036429.html [7]: https://lists.torproject.org/pipermail/tor-dev/2014-December/007977.html Nick also sent out a draft of proposal 240 [8], describing “a simple way for directory authorities to perform signing key revocation”. [8]: https://lists.torproject.org/pipermail/tor-dev/2015-January/008115.html Daniel Forster asked [9] for advice on proposed research into splitting traffic over multiple entry guards in combination with traffic padding: “Is the approach heading in a not so great direction w.r.t. the Tor Project’s ‘only one entry node’ decision?” [9]: https://lists.torproject.org/pipermail/tor-dev/2015-January/008099.html Karsten Loesing submitted his status report for December [10], and George Kadianakis sent out the report for SponsorR [11]. [10]: https://lists.torproject.org/pipermail/tor-reports/2015-January/000744.html [11]: https://lists.torproject.org/pipermail/tor-reports/2015-January/000745.html “After CCC I have a list of people that I have given raspberry pi’s with ooniprobe, and I would like to start coordinating with them via a mailing list”, wrote Arturo Filastò [12], and the result is the ooni-operators mailing list [13]. If you regularly run ooniprobe, or want to start, be sure to sign up! [12]: https://bugs.torproject.org/14140 [13]: https://lists.torproject.org/cgi-bin/mailman/listinfo/ooni-operators Aleksejs Popovs shared with the ooni-dev mailing list [14] the results of an OONI investigation into Latvian internet censorship, conducted using ooniprobe. [14]: https://lists.torproject.org/pipermail/ooni-dev/2015-January/000220.html Dan O’Huiginn started a conversation [15] about how to ensure users are informed of the possible consequences of running OONI tests. [15]: https://lists.torproject.org/pipermail/ooni-dev/2015-January/000208.html Thanks to John Knoll [16] and Monsieur Tino [17] for running mirrors of the Tor Project’s website and software archive! [16]: https://lists.torproject.org/pipermail/tor-mirrors/2015-January/000828.html [17]: https://lists.torproject.org/pipermail/tor-mirrors/2015-January/000835.html “How do we prevent a website mirror admin from tampering with the served files?”, wondered Frédéric Cornu [18]. Christian Krbusek clarified [19] that “in fact, you can’t prevent that, but you are also mirroring the signature files. So anybody downloading from any mirror — even the original host — should verify the downloads”. Andrew Lewman added [20] that “the binaries are signed by well-known keys of tor packagers and developers. The mirror update script randomly selects a binary and verifies it each time it runs. If the binaries don’t match, the mirror is removed from the public list.” [18]: https://lists.torproject.org/pipermail/tor-mirrors/2015-January/000844.html [19]: https://lists.torproject.org/pipermail/tor-mirrors/2015-January/000845.html [20]: https://lists.torproject.org/pipermail/tor-mirrors/2015-January/000848.html Upcoming events --------------- Jan 14 13:30 UTC | little-t tor development meeting | #tor-dev, irc.oftc.net | Jan 14 16:00 UTC | Pluggable transports meeting | #tor-dev, irc.oftc.net | https://lists.torproject.org/pipermail/tor-dev/2015-January/008143.html | Jan 16 19:30 UTC | Tails/Jessie progress meeting | #tails-dev, irc.oftc.net | https://mailman.boum.org/pipermail/tails-dev/2014-December/007696.html | Jan 19 18:00 UTC | Tor Browser online meeting | #tor-dev, irc.oftc.net | Jan 19 18:00 UTC | OONI development meeting | #ooni, irc.oftc.net | Jan 20 18:00 UTC | little-t tor patch workshop | #tor-dev, irc.oftc.net | Jan 22 17:30 JST | Jacob @ Free Software Initiative of Japan | Tokyo, Japan | http://www.fsij.org/monthly-meetings/2015/Jan.html This issue of Tor Weekly News has been assembled by Harmony. Want to continue reading TWN? Please help us create this newsletter. We still need more volunteers to watch the Tor community and report important news. Please see the project page [21], write down your name and subscribe to the team mailing list [22] if you want to get involved! [21]: https://trac.torproject.org/projects/tor/wiki/TorWeeklyNews [22]: https://lists.torproject.org/cgi-bin/mailman/listinfo/news-team -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk