Changes between Version 51 and Version 52 of TorWeeklyNews/2014/33


Ignore:
Timestamp:
Aug 20, 2014, 12:01:32 PM (6 years ago)
Author:
harmony
Comment:

sent

Legend:

Unmodified
Added
Removed
Modified
  • TorWeeklyNews/2014/33

    v51 v52  
    55'''Subject:''' Tor Weekly News — August 20th, 2014
    66
    7 '''Status:''' Frozen. Only technical and language fixes are welcome. New items should go in [wiki:TorWeeklyNews/2014/34 next week's edition]
    8 
    9 {{{
    10 ========================================================================
    11 Tor Weekly News                                        August 20th, 2014
    12 ========================================================================
    13 
    14 Welcome to the thirty-third issue of Tor Weekly News in 2014, the weekly
    15 newsletter that covers what is happening in the community around Tor,
    16 Aphex Twin’s favorite anonymity network [1].
    17 
    18   [1]: https://www.dailydot.com/entertainment/aphex-twin-deep-web-album-syro/
    19 
    20 Tor Browser 3.6.4 and 4.0-alpha-1 are out
    21 -----------------------------------------
    22 
    23 Erinn Clark took to the Tor Blog [2] to announce two new releases by the
    24 Tor Browser team. The stable version (3.6.4) contains fixes for several
    25 new OpenSSL bugs, although since Tor should only be vulnerable to one of
    26 them, and “as this issue is only a DoS”, it is not considered a critical
    27 security update. This release also brings Tor Browser users the fixes
    28 that give log warnings about the RELAY_EARLY traffic confirmation attack
    29 explained last month [3]. Please be sure to upgrade as soon as possible.
    30 
    31 Alongside this stable release, the first alpha version of Tor Browser
    32 4.0 is now available. Among the most exciting new features of this
    33 series is the inclusion of the meek [4] pluggable transport. In contrast
    34 to the bridge-based transports already available in Tor Browser, meek
    35 relies on a principle of “too big to block”, as its creator David
    36 Fifield explained: “instead of going through a bridge with a secret
    37 address, you go through a known domain (www.google.com for example) that
    38 the censor will be reluctant to block. You don’t need to look up any
    39 bridge addresses before you get started” [5]. meek currently supports
    40 two “front domains”, Google and Amazon Web Services; it may therefore be
    41 especially useful for users behind extremely restrictive national or
    42 local firewalls. David posted a fuller explanation of meek, and how to
    43 configure it, in a separate blog post [6].
    44 
    45 This alpha release also “paves the way to [the] upcoming autoupdater by
    46 reorganizing the directory structure of the browser”, as Erinn wrote.
    47 This means that users upgrading from any previous Tor Browser series
    48 cannot extract the new version over their existing Tor Browser folder,
    49 or it will not work.
    50 
    51 You can consult the full list of changes and bugfixes for both versions
    52 in Erinn’s post, and download the new releases themselves from the Tor
    53 website [7].
    54 
    55   [2]: https://blog.torproject.org/blog/tor-browser-364-and-40-alpha-1-are-released
    56   [3]: https://blog.torproject.org/blog/tor-security-advisory-relay-early-traffic-confirmation-attack
    57   [4]: https://trac.torproject.org/projects/tor/wiki/doc/meek
    58   [5]: https://blog.torproject.org/blog/how-use-%E2%80%9Cmeek%E2%80%9D-pluggable-transport#comment-70044
    59   [6]: https://blog.torproject.org/blog/how-use-%E2%80%9Cmeek%E2%80%9D-pluggable-transport
    60   [7]: https://www.torproject.org/dist/torbrowser/
    61 
    62 The Tor network no longer supports designating relays by name
    63 -------------------------------------------------------------
    64 
    65 Since the very first versions of Tor [8], relay operators have been able
    66 to specify “nicknames” for their relays. Such nicknames were initially
    67 meant to be unique across the network, and operators of directory
    68 authorities would manually “bind” a relay identity key after verifying
    69 the nickname. The process became formalized with the “Named” flag
    70 introduced in the 0.1.1 series [9], and later automated with the 0.2.0
    71 series. If a relay held a unique nickname for long enough, the authority
    72 would recognize the binding, and subsequently reserve the name for half
    73 a year.
    74 
    75 Nicknames are useful because it appears humans are not very good at
    76 thinking using long strings of random bits. Initially, they made it
    77 possible to understand what was happening in the network more easily,
    78 and to designate a specific relay in an abbreviated way. Having two
    79 relays in the network with the same nickname is not really problematic
    80 when one is looking at nodes, or a list in Globe [10], as relays can
    81 always be differentiated by their IP addresses or identity keys.
    82 
    83 But complications arise when nicknames are used to specify one relay to
    84 the exclusion of another. If the wrong relay gets selected, it can
    85 become a security risk. Even though real efforts [11] have been made to
    86 improve the situation, properly enforcing uniqueness has always been
    87 problematic, and a burden for the few directory authorities that handle
    88 naming.
    89 
    90 Back in April, the “Heartbleed” bug [12] forced many relays to switch to
    91 a new identity key, thus losing their “Named” flag. Because this meant
    92 that anyone designating relays by their nickname would now have a hard
    93 time continuing to do so, Sebastian Hahn decided to use the opportunity
    94 to get rid of the idea entirely [13].
    95 
    96 This week, Sebastian wrote [14]: “Code review down to 0.2.3.x has shown
    97 that the naming-related code hasn’t changed much at all, and no issues
    98 were found which would mean a Named-flag free consensus would cause any
    99 problems. gabelmoo and tor26 have stopped acting as Naming Directory
    100 Authorities, and — pending any issues — will stay that way.”
    101 
    102 This means that although you can still give your relay a nickname in its
    103 configuration file, designating relays by nickname for any other purpose
    104 (such as telling Tor to avoid using certain nodes) has now stopped
    105 working.  “If you — in your Tor configuration file — refer to any relay
    106 by name and not by identity hash, please change that immediately. Future
    107 versions of Tor will not support using names in the configuration at
    108 all”, warns Sebastian [15].
    109 
    110   [8]: https://gitweb.torproject.org/tor.git/blob/161d7d1:/src/config/torrc.in#l20
    111   [9]: https://gitweb.torproject.org/torspec.git/blob/HEAD:/attic/dir-spec-v2.txt#l427
    112  [10]: https://globe.torproject.org/#/search/query=Unnamed
    113  [11]: https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/122-unnamed-flag.txt
    114  [12]: https://blog.torproject.org/blog/openssl-bug-cve-2014-0160
    115  [13]: https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/235-kill-named-flag.txt
    116  [14]: https://lists.torproject.org/pipermail/tor-dev/2014-August/007348.html
    117  [15]: https://lists.torproject.org/pipermail/tor-talk/2014-August/034380.html
    118 
    119 Miscellaneous news
    120 ------------------
    121 
    122 meejah announced [16] the release of version 0.11.0 of txtorcon, a
    123 Twisted-based Python controller library for Tor. This release brings
    124 several API improvements; see meejah’s message for full release notes
    125 and instructions on how to download it.
    126 
    127  [16]: https://lists.torproject.org/pipermail/tor-dev/2014-August/007375.html
    128 
    129 Mike Perry posted an overview [17] of a recent report put together by
    130 iSEC Partners and commissioned by the Open Technology Fund to explore
    131 “current and future hardening options for the Tor Browser”. Among other
    132 things, Mike’s post addresses the report’s immediate hardening
    133 recommendations, latest thoughts on the proposed Tor Browser “security
    134 slider”, and longer-term security development measures, as well as ways
    135 in which the development of Google Chrome could inform Tor Browser’s own
    136 security engineering.
    137 
    138  [17]: https://blog.torproject.org/blog/isec-partners-conducts-tor-browser-hardening-study
    139 
    140 Nick Mathewson asked for comments [18] on Trunnel, “a little tool to
    141 automatically generate binary encoding and parsing code based on C-like
    142 structure descriptions” intended to prevent “Heartbleed”-style
    143 vulnerabilities from creeping into Tor’s binary-parsing code in C. “My
    144 open questions are: Is this a good idea? Is it a good idea to use this
    145 in Tor? Are there any tricky bugs left in the generated code? What am I
    146 forgetting to think of?”, wrote Nick.
    147 
    148  [18]: https://lists.torproject.org/pipermail/tor-dev/2014-August/007355.html
    149 
    150 George Kadianakis followed up his journey to the core [19] of what Tor
    151 does when trying to connect to entry guards in the absence of a network
    152 connection with another post [20] running through some possible
    153 improvements to Tor’s behavior in these situations: “I’m looking forward
    154 to some feedback on the proposed algorithms as well as improvements and
    155 suggestions”.
    156 
    157  [19]: https://lists.torproject.org/pipermail/tor-dev/2014-June/007042.html
    158  [20]: https://lists.torproject.org/pipermail/tor-dev/2014-August/007346.html
    159 
    160 Arturo Filastò requested feedback [21] on some proposed changes to the
    161 format of the “test deck” used by ooni-probe, the main project of the
    162 Open Observatory of Network Interference. “A test deck is basically a
    163 way of telling it ‘Run this list of OONI tests with these inputs and by
    164 the way be sure you also set these options properly when doing so’…This
    165 new format is supposed to overcome some of the limitations of the old
    166 design and we hope that a major redesign will not be needed in the near
    167 future”, wrote Arturo.
    168 
    169  [21]: https://lists.torproject.org/pipermail/tor-dev/2014-August/007353.html
    170 
    171 Tor’s importance to users who are at risk, for a variety of reasons,
    172 makes it an attractive target for creators of malware, who distribute
    173 fake or modified versions of Tor software for malicious purposes.
    174 Following a recent report of a fake Tor Browser in circulation, Julien
    175 Voisin carried out an investigation of the compromised software, and
    176 posted a detailed analysis [22] of the results. To ensure you are
    177 protected against this sort of attack, make sure you verify any Tor
    178 software you download [23] before running it!
    179 
    180  [22]: http://dustri.org/b/torbundlebrowserorg.html
    181  [23]: https://www.torproject.org/docs/verifying-signatures
    182 
    183 Arlo Breault submitted a status report for July [24].
    184 
    185  [24]: https://lists.torproject.org/pipermail/tor-reports/2014-August/000622.html
    186 
    187 As the annual Google Summer of Code season draws to a close, Tor’s GSoC
    188 students are submitting their final reports. Israel Leiva reported on
    189 the revamp of GetTor [25], Marc Juarez on the framework for website
    190 fingerprinting countermeasures [26], Juha Nurmi on ahmia.fi [27], Noah
    191 Rahman on Stegotorus enhancement [28], Amogh Pradeep on
    192 Orbot+Orfox [29], Daniel Martí on consensus diffs [30], Mikhail Belous
    193 on the multicore tor daemon work [31], Zack Mullaly on the secure
    194 ruleset updater for HTTPS Everywhere [32], and Quinn Jarrell on Fog, the
    195 pluggable transport combiner [33].
    196 
    197  [25]: https://lists.torproject.org/pipermail/tor-dev/2014-August/007368.html
    198  [26]: https://lists.torproject.org/pipermail/tor-reports/2014-August/000623.html
    199  [27]: https://lists.torproject.org/pipermail/tor-reports/2014-August/000624.html
    200  [28]: https://lists.torproject.org/pipermail/tor-dev/2014-August/007377.html
    201  [29]: https://lists.torproject.org/pipermail/tor-dev/2014-August/007379.html
    202  [30]: https://lists.torproject.org/pipermail/tor-dev/2014-August/007386.html
    203  [31]: https://lists.torproject.org/pipermail/tor-dev/2014-August/007389.html
    204  [32]: https://lists.eff.org/pipermail/https-everywhere/2014-August/002234.html
    205  [33]: https://lists.torproject.org/pipermail/tor-dev/2014-August/007393.html
    206 
    207 Tor help desk roundup
    208 ---------------------
    209 
    210 The help desk has been asked if it is possible to set up an anonymous
    211 blog using Tor. The Hyde project [34], developed by Karsten Loesing,
    212 documents the step-by-step process of using Tor, Jekyll, and Nginx to
    213 host an anonymous blog as a hidden service.
    214 
    215  [34]: https://github.com/kloesing/hyde/blob/master/publisher-manual/index.md
    216 
    217 News from Tor StackExchange
    218 ---------------------------
    219 
    220 The Tor StackExchange site is looking for another friendly and helpful
    221 moderator [35]. Moderators need to take care of flagged items (spam,
    222 me-too comments, etc.), and are liaisons between the community and
    223 StackExchange’s community team. So, if you’re interested, have a look at
    224 the theory of moderation [36] and post an answer to the question at the
    225 Tor StackExchange Meta site.
    226 
    227  [35]: https://meta.tor.stackexchange.com/q/207/88
    228  [36]: http://blog.stackoverflow.com/2009/05/a-theory-of-moderation/
    229 
    230 Upcoming events
    231 ---------------
    232 
    233  Aug 20-22        | Roger @ USENIX Security Symposium ’14
    234                   | San Diego, California, USA
    235                   | https://www.usenix.org/conference/usenixsecurity14
    236                   |
    237  Aug 20 13:30 UTC | little-t tor development meeting
    238                   | #tor-dev, irc.oftc.net
    239                   |
    240  Aug 22 15:00 UTC | OONI development meeting
    241                   | #ooni, irc.oftc.net
    242                   | https://lists.torproject.org/pipermail/ooni-dev/2014-August/000145.html
    243                   |
    244  Aug 25 18:00 UTC | Tor Browser online meeting
    245                   | #tor-dev, irc.oftc.net
    246                   |
    247  Sep 03 19:00 UTC | Tails contributors meeting
    248                   | #tails-dev, irc.indymedia.org / h7gf2ha3hefoj5ls.onion
    249                   | https://mailman.boum.org/pipermail/tails-project/2014-August/000016.html
    250 
    251 
    252 This issue of Tor Weekly News has been assembled by Lunar, harmony,
    253 David Fifield, qbi, Matt Pagan, Sebastian Hahn, Ximin Luo, and dope457.
    254 
    255 Want to continue reading TWN? Please help us create this newsletter.
    256 We still need more volunteers to watch the Tor community and report
    257 important news. Please see the project page [37], write down your
    258 name and subscribe to the team mailing list [38] if you want to
    259 get involved!
    260 
    261  [37]: https://trac.torproject.org/projects/tor/wiki/TorWeeklyNews
    262  [38]: https://lists.torproject.org/cgi-bin/mailman/listinfo/news-team
    263 }}}
     7'''Status:''' Sent.