Version 6 (modified by harmony, 4 years ago) (diff)


80th issue of Tor Weekly News. Covering what's happening from January 6th, 2015 to January 13th, 2015. To be released on January 14th, 2015.

Editor: Harmony

Subject: Tor Weekly News — January 14th, 2015

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 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

“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.


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.”


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].


Nick also sent out a draft of proposal 240 [8], describing “a simple way
for directory authorities to perform signing key revocation”.


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?”


Karsten Loesing submitted his status report for December [10], and
George Kadianakis sent out the report for SponsorR [11].


“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!


Aleksejs Popovs shared with the ooni-dev mailing list [14] the results
of an OONI investigation into Latvian internet censorship, conducted
using ooniprobe.


Dan O’Huiginn started a conversation [15] about how to ensure users are
informed of the possible consequences of running OONI tests.


Thanks to John Knoll [16] and Monsieur Tino [17] for running mirrors of
the Tor Project’s website and software archive!


“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.”


Upcoming events

  Jan 14 13:30 UTC | little-t tor development meeting
                   | #tor-dev,
  Jan 14 16:00 UTC | Pluggable transports meeting
                   | #tor-dev,
  Jan 16 19:30 UTC | Tails/Jessie progress meeting
                   | #tails-dev,
  Jan 19 18:00 UTC | Tor Browser online meeting
                   | #tor-dev,
  Jan 19 18:00 UTC | OONI development meeting
                   | #ooni,
  Jan 20 18:00 UTC | little-t tor patch workshop
                   | #tor-dev,
  Jan 22 17:30 JST | Jacob @ Free Software Initiative of Japan
                   | Tokyo, Japan

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!