[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

[tor-talk] Tor Weekly News â August 20th, 2014

========================================================================
Tor Weekly News                                        August 20th, 2014
========================================================================

Welcome to the thirty-third issue of Tor Weekly News in 2014, the weekly
newsletter that covers what is happening in the community around Tor,
Aphex Twinâs favorite anonymity network [1].
[1]: https://www.dailydot.com/entertainment/aphex-twin-deep-web-album-syro/ 

Tor Browser 3.6.4 and 4.0-alpha-1 are out
-----------------------------------------

Erinn Clark took to the Tor Blog [2] to announce two new releases by the
Tor Browser team. The stable version (3.6.4) contains fixes for several
new OpenSSL bugs, although since Tor should only be vulnerable to one of
them, and âas this issue is only a DoSâ, it is not considered a critical
security update. This release also brings Tor Browser users the fixes
that give log warnings about the RELAY_EARLY traffic confirmation attack
explained last month [3]. Please be sure to upgrade as soon as possible.

Alongside this stable release, the first alpha version of Tor Browser
4.0 is now available. Among the most exciting new features of this
series is the inclusion of the meek [4] pluggable transport. In contrast
to the bridge-based transports already available in Tor Browser, meek
relies on a principle of âtoo big to blockâ, as its creator David
Fifield explained: âinstead of going through a bridge with a secret
address, you go through a known domain (www.google.com for example) that
the censor will be reluctant to block. You donât need to look up any
bridge addresses before you get startedâ [5]. meek currently supports
two âfront domainsâ, Google and Amazon Web Services; it may therefore be
especially useful for users behind extremely restrictive national or
local firewalls. David posted a fuller explanation of meek, and how to
configure it, in a separate blog post [6].

This alpha release also âpaves the way to [the] upcoming autoupdater by
reorganizing the directory structure of the browserâ, as Erinn wrote.
This means that users upgrading from any previous Tor Browser series
cannot extract the new version over their existing Tor Browser folder,
or it will not work.

You can consult the full list of changes and bugfixes for both versions
in Erinnâs post, and download the new releases themselves from the Tor
website [7].
[2]: https://blog.torproject.org/blog/tor-browser-364-and-40-alpha-1-are-released [3]: https://blog.torproject.org/blog/tor-security-advisory-relay-early-traffic-confirmation-attack 
  [4]: https://trac.torproject.org/projects/tor/wiki/doc/meek
[5]: https://blog.torproject.org/blog/how-use-%E2%80%9Cmeek%E2%80%9D-pluggable-transport#comment-70044 [6]: https://blog.torproject.org/blog/how-use-%E2%80%9Cmeek%E2%80%9D-pluggable-transport 
  [7]: https://www.torproject.org/dist/torbrowser/

The Tor network no longer supports designating relays by name
-------------------------------------------------------------

Since the very first versions of Tor [8], relay operators have been able
to specify ânicknamesâ for their relays. Such nicknames were initially
meant to be unique across the network, and operators of directory
authorities would manually âbindâ a relay identity key after verifying
the nickname. The process became formalized with the âNamedâ flag
introduced in the 0.1.1 series [9], and later automated with the 0.2.0
series. If a relay held a unique nickname for long enough, the authority
would recognize the binding, and subsequently reserve the name for half
a year.

Nicknames are useful because it appears humans are not very good at
thinking using long strings of random bits. Initially, they made it
possible to understand what was happening in the network more easily,
and to designate a specific relay in an abbreviated way. Having two
relays in the network with the same nickname is not really problematic
when one is looking at nodes, or a list in Globe [10], as relays can
always be differentiated by their IP addresses or identity keys.

But complications arise when nicknames are used to specify one relay to
the exclusion of another. If the wrong relay gets selected, it can
become a security risk. Even though real efforts [11] have been made to
improve the situation, properly enforcing uniqueness has always been
problematic, and a burden for the few directory authorities that handle
naming.

Back in April, the âHeartbleedâ bug [12] forced many relays to switch to
a new identity key, thus losing their âNamedâ flag. Because this meant
that anyone designating relays by their nickname would now have a hard
time continuing to do so, Sebastian Hahn decided to use the opportunity
to get rid of the idea entirely [13].

This week, Sebastian wrote [14]: âCode review down to 0.2.3.x has shown
that the naming-related code hasnât changed much at all, and no issues
were found which would mean a Named-flag free consensus would cause any
problems. gabelmoo and tor26 have stopped acting as Naming Directory
Authorities, and â pending any issues â will stay that way.â

This means that although you can still give your relay a nickname in its
configuration file, designating relays by nickname for any other purpose
(such as telling Tor to avoid using certain nodes) has now stopped
working.  âIf you â in your Tor configuration file â refer to any relay
by name and not by identity hash, please change that immediately. Future
versions of Tor will not support using names in the configuration at
allâ, warns Sebastian [15].
[8]: https://gitweb.torproject.org/tor.git/blob/161d7d1:/src/config/torrc.in#l20 [9]: https://gitweb.torproject.org/torspec.git/blob/HEAD:/attic/dir-spec-v2.txt#l427 
 [10]: https://globe.torproject.org/#/search/query=Unnamed
[11]: https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/122-unnamed-flag.txt 
 [12]: https://blog.torproject.org/blog/openssl-bug-cve-2014-0160
[13]: https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/235-kill-named-flag.txt [14]: https://lists.torproject.org/pipermail/tor-dev/2014-August/007348.html [15]: https://lists.torproject.org/pipermail/tor-talk/2014-August/034380.html 

Miscellaneous news
------------------

meejah announced [16] the release of version 0.11.0 of txtorcon, a
Twisted-based Python controller library for Tor. This release brings
several API improvements; see meejahâs message for full release notes
and instructions on how to download it.
[16]: https://lists.torproject.org/pipermail/tor-dev/2014-August/007375.html 

Mike Perry posted an overview [17] of a recent report put together by
iSEC Partners and commissioned by the Open Technology Fund to explore
âcurrent and future hardening options for the Tor Browserâ. Among other
things, Mikeâs post addresses the reportâs immediate hardening
recommendations, latest thoughts on the proposed Tor Browser âsecurity
sliderâ, and longer-term security development measures, as well as ways
in which the development of Google Chrome could inform Tor Browserâs own
security engineering.
[17]: https://blog.torproject.org/blog/isec-partners-conducts-tor-browser-hardening-study 

Nick Mathewson asked for comments [18] on Trunnel, âa little tool to
automatically generate binary encoding and parsing code based on C-like
structure descriptionsâ intended to prevent âHeartbleedâ-style
vulnerabilities from creeping into Torâs binary-parsing code in C. âMy
open questions are: Is this a good idea? Is it a good idea to use this
in Tor? Are there any tricky bugs left in the generated code? What am I
forgetting to think of?â, wrote Nick.
[18]: https://lists.torproject.org/pipermail/tor-dev/2014-August/007355.html 

George Kadianakis followed up his journey to the core [19] of what Tor
does when trying to connect to entry guards in the absence of a network
connection with another post [20] running through some possible
improvements to Torâs behavior in these situations: âIâm looking forward
to some feedback on the proposed algorithms as well as improvements and
suggestionsâ.
[19]: https://lists.torproject.org/pipermail/tor-dev/2014-June/007042.html [20]: https://lists.torproject.org/pipermail/tor-dev/2014-August/007346.html 

Arturo Filastà requested feedback [21] on some proposed changes to the
format of the âtest deckâ used by ooni-probe, the main project of the
Open Observatory of Network Interference. âA test deck is basically a
way of telling it âRun this list of OONI tests with these inputs and by
the way be sure you also set these options properly when doing soââThis
new format is supposed to overcome some of the limitations of the old
design and we hope that a major redesign will not be needed in the near
futureâ, wrote Arturo.
[21]: https://lists.torproject.org/pipermail/tor-dev/2014-August/007353.html 

Torâs importance to users who are at risk, for a variety of reasons,
makes it an attractive target for creators of malware, who distribute
fake or modified versions of Tor software for malicious purposes.
Following a recent report of a fake Tor Browser in circulation, Julien
Voisin carried out an investigation of the compromised software, and
posted a detailed analysis [22] of the results. To ensure you are
protected against this sort of attack, make sure you verify any Tor
software you download [23] before running it!

 [22]: http://dustri.org/b/torbundlebrowserorg.html
 [23]: https://www.torproject.org/docs/verifying-signatures

Arlo Breault submitted a status report for July [24].
[24]: https://lists.torproject.org/pipermail/tor-reports/2014-August/000622.html 

As the annual Google Summer of Code season draws to a close, Torâs GSoC
students are submitting their final reports. Israel Leiva reported on
the revamp of GetTor [25], Marc Juarez on the framework for website
fingerprinting countermeasures [26], Juha Nurmi on ahmia.fi [27], Noah
Rahman on Stegotorus enhancement [28], Amogh Pradeep on
Orbot+Orfox [29], Daniel Martà on consensus diffs [30], Mikhail Belous
on the multicore tor daemon work [31], Zack Mullaly on the secure
ruleset updater for HTTPS Everywhere [32], and Quinn Jarrell on Fog, the
pluggable transport combiner [33].
[25]: https://lists.torproject.org/pipermail/tor-dev/2014-August/007368.html [26]: https://lists.torproject.org/pipermail/tor-reports/2014-August/000623.html [27]: https://lists.torproject.org/pipermail/tor-reports/2014-August/000624.html [28]: https://lists.torproject.org/pipermail/tor-dev/2014-August/007377.html [29]: https://lists.torproject.org/pipermail/tor-dev/2014-August/007379.html [30]: https://lists.torproject.org/pipermail/tor-dev/2014-August/007386.html [31]: https://lists.torproject.org/pipermail/tor-dev/2014-August/007389.html [32]: https://lists.eff.org/pipermail/https-everywhere/2014-August/002234.html [33]: https://lists.torproject.org/pipermail/tor-dev/2014-August/007393.html 

Tor help desk roundup
---------------------

The help desk has been asked if it is possible to set up an anonymous
blog using Tor. The Hyde project [34], developed by Karsten Loesing,
documents the step-by-step process of using Tor, Jekyll, and Nginx to
host an anonymous blog as a hidden service.
[34]: https://github.com/kloesing/hyde/blob/master/publisher-manual/index.md 

News from Tor StackExchange
---------------------------

The Tor StackExchange site is looking for another friendly and helpful
moderator [35]. Moderators need to take care of flagged items (spam,
me-too comments, etc.), and are liaisons between the community and
StackExchangeâs community team. So, if youâre interested, have a look at
the theory of moderation [36] and post an answer to the question at the
Tor StackExchange Meta site.

 [35]: https://meta.tor.stackexchange.com/q/207/88
 [36]: http://blog.stackoverflow.com/2009/05/a-theory-of-moderation/

Upcoming events
---------------

 Aug 20-22        | Roger @ USENIX Security Symposium â14
                  | San Diego, California, USA
                  | https://www.usenix.org/conference/usenixsecurity14
                  |
 Aug 20 13:30 UTC | little-t tor development meeting
                  | #tor-dev, irc.oftc.net
                  |
 Aug 22 15:00 UTC | OONI development meeting
                  | #ooni, irc.oftc.net
| https://lists.torproject.org/pipermail/ooni-dev/2014-August/000145.html 
                  |
 Aug 25 18:00 UTC | Tor Browser online meeting
                  | #tor-dev, irc.oftc.net
                  |
 Sep 03 19:00 UTC | Tails contributors meeting
| #tails-dev, irc.indymedia.org / h7gf2ha3hefoj5ls.onion | https://mailman.boum.org/pipermail/tails-project/2014-August/000016.html 


This issue of Tor Weekly News has been assembled by Lunar, harmony,
David Fifield, qbi, Matt Pagan, Sebastian Hahn, Ximin Luo, and dope457.

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 [37], write down your
name and subscribe to the team mailing list [38] if you want to
get involved!

 [37]: https://trac.torproject.org/projects/tor/wiki/TorWeeklyNews
 [38]: https://lists.torproject.org/cgi-bin/mailman/listinfo/news-team
--
tor-talk mailing list - tor-talk@xxxxxxxxxxxxxxxxxxxx
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk