Changes between Version 6 and Version 7 of TorWeeklyNews/2015/2


Ignore:
Timestamp:
Jan 14, 2015, 12:01:01 PM (4 years ago)
Author:
harmony
Comment:

sent

Legend:

Unmodified
Added
Removed
Modified
  • TorWeeklyNews/2015/2

    v6 v7  
    55'''Subject:''' Tor Weekly News — January 14th, 2015
    66
    7 {{{
    8 ========================================================================
    9 Tor Weekly News                                       January 14th, 2015
    10 ========================================================================
    11 
    12 Welcome to the second issue in 2015 of Tor Weekly News, the weekly
    13 newsletter that covers what’s happening in the Tor community.
    14 
    15 What to do if meek gets blocked
    16 -------------------------------
    17 
    18 Regular readers of Tor Weekly News will be familiar with meek [1], the
    19 pluggable transport developed by David Fifield. Where most existing
    20 transports work by connecting clients to “bridge” relays that are
    21 difficult for the adversary to discover (or identify as relays), meek
    22 makes all of a client’s Tor traffic appear as though it is destined for
    23 a domain that is “too big to block” — in other words, web platforms so
    24 popular that a censor cannot prevent access to them without disrupting
    25 lots of unrelated Internet activity in its sphere of control — when in
    26 fact the traffic is sent to meek servers running on those platforms,
    27 which in turn relay it into the regular Tor network. Google, Amazon, and
    28 Microsoft are some of the services whose domain names currently work as
    29 disguises for meek.
    30 
    31 Unfortunately, that doesn’t mean meek is unblockable. As David wrote [2]
    32 to the tor-talk mailing list, “that’s the wrong way to think about the
    33 problem”. “It is designed to be difficult and expensive to block […] but
    34 suppose a censor makes that call, and blocks Google/Amazon/whatever.
    35 What then?”
    36 
    37 Two easy solutions are selecting a different backend (meek-amazon
    38 instead of meek-google, for example) or using a different DNS server:
    39 “The most common way to block a domain name is by DNS poisoning; i.e.,
    40 the IP address behind the name is accessible, but the local DNS server
    41 gives you a false address. Try a public DNS server such as 8.8.8.8. But
    42 if that works, be aware that it’s probably only a temporary fix, as
    43 censors have historically figured out the alternate-DNS trick pretty
    44 fast.”
    45 
    46 “What you really want to do”, David suggested, “if the easy things don’t
    47 work, is choose a different front domain.” Please see David’s message
    48 for a fuller explanation of the difference between the backend and the
    49 “front domain”, and a guide to configuring new domains — as well as one
    50 to setting up your own meek web app, if all else fails.
    51 
    52   [1]: https://trac.torproject.org/projects/tor/wiki/doc/meek
    53   [2]: https://lists.torproject.org/pipermail/tor-talk/2015-January/036410.html
    54 
    55 Miscellaneous news
    56 ------------------
    57 
    58 sycamoreone announced [3] orc, a Go library that implements parts of
    59 Tor’s control protocol. “I do have some ideas for a higher-level
    60 interface, but no fixed plan yet. The next step will probably be to add
    61 net/http-like handlerFuncs to handle (asynchronous) replies from the
    62 onion router.”
    63 
    64   [3]: https://lists.torproject.org/pipermail/tor-talk/2015-January/036425.html
    65 
    66 taxakis linked [4] to “Post-Quantum Secure Onion Routing” [5] by
    67 Satrajit Ghosh and Aniket Kate, a new paper proposing a successor to the
    68 currently-used ntor handshake protocol that would be “resilient against
    69 quantum attacks, but also at the same time allow OR nodes to use the
    70 current DH public keys, and consequently require no modification to the
    71 current Tor public key infrastructure.” Nick Mathewson wondered [6]
    72 whether “anybody around here has the cryptographic background to comment
    73 on the PQ part of their scheme?”, and compared it to Yawning Angel’s
    74 experimental “basket” protocol [7].
    75 
    76   [4]: https://lists.torproject.org/pipermail/tor-talk/2015-January/036420.html
    77   [5]: http://eprint.iacr.org/2015/008
    78   [6]: https://lists.torproject.org/pipermail/tor-talk/2015-January/036429.html
    79   [7]: https://lists.torproject.org/pipermail/tor-dev/2014-December/007977.html
    80 
    81 Nick also sent out a draft of proposal 240 [8], describing “a simple way
    82 for directory authorities to perform signing key revocation”.
    83 
    84   [8]: https://lists.torproject.org/pipermail/tor-dev/2015-January/008115.html
    85 
    86 Daniel Forster asked [9] for advice on proposed research into splitting
    87 traffic over multiple entry guards in combination with traffic padding:
    88 “Is the approach heading in a not so great direction w.r.t. the Tor
    89 Project’s ‘only one entry node’ decision?”
    90 
    91   [9]: https://lists.torproject.org/pipermail/tor-dev/2015-January/008099.html
    92 
    93 Karsten Loesing submitted his status report for December [10], and
    94 George Kadianakis sent out the report for SponsorR [11].
    95 
    96  [10]: https://lists.torproject.org/pipermail/tor-reports/2015-January/000744.html
    97  [11]: https://lists.torproject.org/pipermail/tor-reports/2015-January/000745.html
    98 
    99 “After CCC I have a list of people that I have given raspberry pi’s with
    100 ooniprobe, and I would like to start coordinating with them via a
    101 mailing list”, wrote Arturo Filastò [12], and the result is the
    102 ooni-operators mailing list [13]. If you regularly run ooniprobe, or
    103 want to start, be sure to sign up!
    104 
    105  [12]: https://bugs.torproject.org/14140
    106  [13]: https://lists.torproject.org/cgi-bin/mailman/listinfo/ooni-operators
    107 
    108 Aleksejs Popovs shared with the ooni-dev mailing list [14] the results
    109 of an OONI investigation into Latvian internet censorship, conducted
    110 using ooniprobe.
    111 
    112  [14]: https://lists.torproject.org/pipermail/ooni-dev/2015-January/000220.html
    113 
    114 Dan O’Huiginn started a conversation [15] about how to ensure users are
    115 informed of the possible consequences of running OONI tests.
    116 
    117  [15]: https://lists.torproject.org/pipermail/ooni-dev/2015-January/000208.html
    118 
    119 Thanks to John Knoll [16] and Monsieur Tino [17] for running mirrors of
    120 the Tor Project’s website and software archive!
    121 
    122  [16]: https://lists.torproject.org/pipermail/tor-mirrors/2015-January/000828.html
    123  [17]: https://lists.torproject.org/pipermail/tor-mirrors/2015-January/000835.html
    124 
    125 “How do we prevent a website mirror admin from tampering with the served
    126 files?”, wondered Frédéric Cornu [18]. Christian Krbusek clarified [19]
    127 that “in fact, you can’t prevent that, but you are also mirroring the
    128 signature files. So anybody downloading from any mirror — even the
    129 original host — should verify the downloads”. Andrew Lewman added [20]
    130 that “the binaries are signed by well-known keys of tor packagers and
    131 developers. The mirror update script randomly selects a binary and
    132 verifies it each time it runs. If the binaries don’t match, the mirror
    133 is removed from the public list.”
    134 
    135  [18]: https://lists.torproject.org/pipermail/tor-mirrors/2015-January/000844.html
    136  [19]: https://lists.torproject.org/pipermail/tor-mirrors/2015-January/000845.html
    137  [20]: https://lists.torproject.org/pipermail/tor-mirrors/2015-January/000848.html
    138 
    139 Upcoming events
    140 ---------------
    141 
    142   Jan 14 13:30 UTC | little-t tor development meeting
    143                    | #tor-dev, irc.oftc.net
    144                    |
    145   Jan 14 16:00 UTC | Pluggable transports meeting
    146                    | #tor-dev, irc.oftc.net
    147                    | https://lists.torproject.org/pipermail/tor-dev/2015-January/008143.html
    148                    |
    149   Jan 16 19:30 UTC | Tails/Jessie progress meeting
    150                    | #tails-dev, irc.oftc.net
    151                    | https://mailman.boum.org/pipermail/tails-dev/2014-December/007696.html
    152                    |
    153   Jan 19 18:00 UTC | Tor Browser online meeting
    154                    | #tor-dev, irc.oftc.net
    155                    |
    156   Jan 19 18:00 UTC | OONI development meeting
    157                    | #ooni, irc.oftc.net
    158                    |
    159   Jan 20 18:00 UTC | little-t tor patch workshop
    160                    | #tor-dev, irc.oftc.net
    161                    |
    162   Jan 22 17:30 JST | Jacob @ Free Software Initiative of Japan
    163                    | Tokyo, Japan
    164                    | http://www.fsij.org/monthly-meetings/2015/Jan.html
    165 
    166 
    167 This issue of Tor Weekly News has been assembled by Harmony.
    168 
    169 Want to continue reading TWN? Please help us create this newsletter.
    170 We still need more volunteers to watch the Tor community and report
    171 important news. Please see the project page [21], write down your
    172 name and subscribe to the team mailing list [22] if you want to
    173 get involved!
    174 
    175  [21]: https://trac.torproject.org/projects/tor/wiki/TorWeeklyNews
    176  [22]: https://lists.torproject.org/cgi-bin/mailman/listinfo/news-team
    177 }}}
     7'''Status:''' [https://lists.torproject.org/pipermail/tor-news/2015-January/000080.html Sent].