[TWN team] Recent changes to the wiki pages

Lunar lunar at torproject.org
Tue Aug 19 14:00:20 UTC 2014


===========================================================================
=== https://trac.torproject.org/projects/tor/wiki/TorWeeklyNews/2014/33 ===
===========================================================================

version 49
Author: harmony
Date:   2014-08-19T13:24:19+00:00

   update status

--- version 48
+++ version 49
@@ -3,6 +3,8 @@
 '''Editor:''' harmony
 
 '''Subject:''' Tor Weekly News — August 20th, 2014
+
+'''Status:''' Frozen. Only technical and language fixes are welcome. New items should go in [wiki:TorWeeklyNews/2014/34 next week's edition] 
 
 {{{
 ========================================================================

version 48
Author: harmony
Date:   2014-08-19T13:20:34+00:00

   move dcf's item to next week in case he has time to write it

--- version 47
+++ version 48
@@ -260,10 +260,3 @@
  [37]: https://trac.torproject.org/projects/tor/wiki/TorWeeklyNews
  [38]: https://lists.torproject.org/cgi-bin/mailman/listinfo/news-team
 }}}
-
-* (''Not sure how to write this, I wish dcf could provide a short writeup -- Lunar'') Tor-related talks at [https://www.defcon.org/html/defcon-22/dc-22-index.html Def Con 22], August 7–10, 2014 in Las Vegas:
-  * [https://defcon.org/html/defcon-22/dc-22-speakers.html#Zoz Don’t Fuck It Up] ([http://dropcanvas.com/d85g8 slides], temporary URL) by Zoz. Zoz talked about how to use Tor and other tools to keep safe while practicing civil disobedience.
-  * [https://defcon.org/html/defcon-22/dc-22-speakers.html#Lackey Masquerade: How a Helpful Man-in-the-Middle Can Help You Evade Monitoring] ([https://www.portalmasq.com/portal-defcon.pdf slides], [http://arstechnica.com/information-technology/2014/08/a-portable-router-that-conceals-your-internet-traffic/ Ars Technica]) by Ryan Lackey, Marc Rogers, and the Grugq. The talk was different than what the title and abstract imply. They discussed a hardware "travel router" running Tor and pluggable transports (see pages 24 ff. of the slides).
-  * [https://defcon.org/html/defcon-22/dc-22-speakers.html#Vedaa Impostor — Polluting Tor Metadata] by Charlie Vedaa and Mike Larsen. The authors presented simple JavaScript programs designed to cause false positives for Tor-detecting rules in network monitors such as Snort, Bro, and XKeyScore. Their programs are at http://impostor.io/.
-  * ''I (dcf) didn't see this one, so I can't say anything about it.''\\
-    [https://defcon.org/html/defcon-22/dc-22-speakers.html#Metacortex Touring the Darkside of the Internet. An Introduction to Tor, Darknets, and Bitcoin] by Metacortex and Grifter.

version 47
Author: harmony
Date:   2014-08-19T13:13:03+00:00

   freeze

--- version 46
+++ version 47
@@ -11,38 +11,36 @@
 
 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,
-the anonymity network preferred by Aphex Twin [XXX].
-
- [XXX]: https://www.dailydot.com/entertainment/aphex-twin-deep-web-album-syro/
+the anonymity network preferred by Aphex Twin [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 [XXX] 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 [XXX]. Please be sure to
-upgrade as soon as possible.
+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 [XXX] 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” [XXX]. 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 [XXX].
-
-This alpha release also “paves the way to [the] upcoming autoupdater by
+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,
@@ -50,51 +48,51 @@
 
 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 [XXX].
-
- [XXX]: https://blog.torproject.org/blog/tor-browser-364-and-40-alpha-1-are-released
- [XXX]: https://blog.torproject.org/blog/tor-security-advisory-relay-early-traffic-confirmation-attack
- [XXX]: https://trac.torproject.org/projects/tor/wiki/doc/meek
- [XXX]: https://blog.torproject.org/blog/how-use-%E2%80%9Cmeek%E2%80%9D-pluggable-transport#comment-70044
- [XXX]: https://blog.torproject.org/blog/how-use-%E2%80%9Cmeek%E2%80%9D-pluggable-transport
- [XXX]: https://www.torproject.org/dist/torbrowser/
+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 [XXX], relay operators have been
-able to specify “nicknames” for their relays. Such nicknames were initially
+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 [XXX], 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.
+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 with the same nickname in the whole network is not really
-problematic when one is looking at nodes, or a list in Globe [XXX], as
+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 if real efforts [XXX] have been made to
+become a security risk. Even if 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 [XXX] forced many relays to switch to
+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 addressing relays with 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 [XXX].
-
-This week, Sebastian wrote [XXX]: “Code review down to 0.2.3.x has shown
+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
@@ -102,32 +100,32 @@
 
 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
+(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 [XXX].
-
- [XXX]: https://gitweb.torproject.org/tor.git/blob/161d7d1:/src/config/torrc.in#l20
- [XXX]: https://gitweb.torproject.org/torspec.git/blob/HEAD:/attic/dir-spec-v2.txt#l427
- [XXX]: https://globe.torproject.org/#/search/query=Unnamed
- [XXX]: https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/122-unnamed-flag.txt
- [XXX]: https://blog.torproject.org/blog/openssl-bug-cve-2014-0160
- [XXX]: https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/235-kill-named-flag.txt
- [XXX]: https://lists.torproject.org/pipermail/tor-dev/2014-August/007348.html
- [XXX]: https://lists.torproject.org/pipermail/tor-talk/2014-August/034380.html
+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 [XXX] the release of version 0.11.0 of txtorcon, a
+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.
 
- [XXX]: https://lists.torproject.org/pipermail/tor-dev/2014-August/007375.html
-
-Mike Perry posted an overview [XXX] of a recent report put together by
+ [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
@@ -136,125 +134,118 @@
 in which the development of Google Chrome could inform Tor Browser’s own
 security engineering.
 
- [XXX]: https://blog.torproject.org/blog/isec-partners-conducts-tor-browser-hardening-study
-
-Nick Mathewson asked for comments [XXX] on Trunnel, “a little tool to
-automatically generate binary encoding and parsing code based on
-C-like structure descriptions” intended to prevent Heartbleed-style
+ [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.
 
- [XXX]: https://lists.torproject.org/pipermail/tor-dev/2014-August/007355.html
-
-George Kadianakis followed up his journey to the core [XXX] of what Tor
+ [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 [XXX] running through some possible
-improvements to Tor’s behavior in these situations: “I’m looking forward
+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”.
 
- [XXX]: https://lists.torproject.org/pipermail/tor-dev/2014-June/007042.html
- [XXX]: https://lists.torproject.org/pipermail/tor-dev/2014-August/007346.html
-
-Arturo Filastò requested feedback [XXX] 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.
-
- [XXX]: https://lists.torproject.org/pipermail/tor-dev/2014-August/007353.html
+ [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 [XXX] of the results. To ensure you are
+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 [XXX] before running it!
-
- [XXX]: http://dustri.org/b/torbundlebrowserorg.html
- [XXX]: https://www.torproject.org/docs/verifying-signatures
-
-Arlo Breault submitted a status report for July [XXX].
-
- [XXX]: https://lists.torproject.org/pipermail/tor-reports/2014-August/000622.html
+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 [XXX], Marc Juarez on the framework for website
-fingerprinting countermeasures [XXX], Juha Nurmi on ahmia.fi [XXX], Noah
-Rahman on Stegotorus enhancement [XXX], Amogh Pradeep on
-Orbot+Orfox [XXX], Daniel Martí on consensus diffs [XXX], Mikhail Belous
-on the multicore tor daemon work [XXX], Zack Mullaly on the secure
-ruleset updater for HTTPS Everywhere [XXX], and Quinn Jarrell on Fog,
-the pluggable transport combiner [XXX].
-
- [XXX]: https://lists.torproject.org/pipermail/tor-dev/2014-August/007368.html
- [XXX]: https://lists.torproject.org/pipermail/tor-reports/2014-August/000623.html
- [XXX]: https://lists.torproject.org/pipermail/tor-reports/2014-August/000624.html
- [XXX]: https://lists.torproject.org/pipermail/tor-dev/2014-August/007377.html
- [XXX]: https://lists.torproject.org/pipermail/tor-dev/2014-August/007379.html
- [XXX]: https://lists.torproject.org/pipermail/tor-dev/2014-August/007386.html
- [XXX]: https://lists.torproject.org/pipermail/tor-dev/2014-August/007389.html
- [XXX]: https://lists.eff.org/pipermail/https-everywhere/2014-August/002234.html
- [XXX]: https://lists.torproject.org/pipermail/tor-dev/2014-August/007393.html
+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's possible to set up an anonymous blog 
-using Tor. The Hyde project [XXX], 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. 
-
- [XXX]: https://github.com/kloesing/hyde/blob/master/publisher-manual/index.md
+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 [XXX]. 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 [XXX] and
-post an answer to the question at the Tor StackExchange Meta site.
-
- [XXX]: https://meta.tor.stackexchange.com/q/207/88
- [XXX]: http://blog.stackoverflow.com/2009/05/a-theory-of-moderation/
-
-Easy development tasks to get involved with
--------------------------------------------
-
-Text with cited source [XXX].
-
- [XXX]: 
+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
 ---------------
 
- August 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.  3 19:00 UTC | Tails contributors meeting
-                   | #tails-dev, irc.indymedia.org / h7gf2ha3hefoj5ls.onion
-                   | https://mailman.boum.org/pipermail/tails-project/2014-August/000016.html
+ 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,
@@ -262,12 +253,12 @@
 
 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 [XXX], write down your
-name and subscribe to the team mailing list [XXX] if you want to
+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!
 
-  [XXX]: https://trac.torproject.org/projects/tor/wiki/TorWeeklyNews
-  [XXX]: https://lists.torproject.org/cgi-bin/mailman/listinfo/news-team
+ [37]: https://trac.torproject.org/projects/tor/wiki/TorWeeklyNews
+ [38]: https://lists.torproject.org/cgi-bin/mailman/listinfo/news-team
 }}}
 
 * (''Not sure how to write this, I wish dcf could provide a short writeup -- Lunar'') Tor-related talks at [https://www.defcon.org/html/defcon-22/dc-22-index.html Def Con 22], August 7–10, 2014 in Las Vegas:

version 46
Author: harmony
Date:   2014-08-19T12:59:44+00:00

   credits

--- version 45
+++ version 46
@@ -257,8 +257,8 @@
                    | https://mailman.boum.org/pipermail/tails-project/2014-August/000016.html
 
 
-This issue of Tor Weekly News has been assembled by XXX, Matt Pagan,
-Sebastian Hahn and Ximin Luo. 
+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

version 45
Author: harmony
Date:   2014-08-19T12:52:11+00:00

   add gsoc reports to misc

--- version 44
+++ version 45
@@ -185,6 +185,26 @@
 
  [XXX]: 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 [XXX], Marc Juarez on the framework for website
+fingerprinting countermeasures [XXX], Juha Nurmi on ahmia.fi [XXX], Noah
+Rahman on Stegotorus enhancement [XXX], Amogh Pradeep on
+Orbot+Orfox [XXX], Daniel Martí on consensus diffs [XXX], Mikhail Belous
+on the multicore tor daemon work [XXX], Zack Mullaly on the secure
+ruleset updater for HTTPS Everywhere [XXX], and Quinn Jarrell on Fog,
+the pluggable transport combiner [XXX].
+
+ [XXX]: https://lists.torproject.org/pipermail/tor-dev/2014-August/007368.html
+ [XXX]: https://lists.torproject.org/pipermail/tor-reports/2014-August/000623.html
+ [XXX]: https://lists.torproject.org/pipermail/tor-reports/2014-August/000624.html
+ [XXX]: https://lists.torproject.org/pipermail/tor-dev/2014-August/007377.html
+ [XXX]: https://lists.torproject.org/pipermail/tor-dev/2014-August/007379.html
+ [XXX]: https://lists.torproject.org/pipermail/tor-dev/2014-August/007386.html
+ [XXX]: https://lists.torproject.org/pipermail/tor-dev/2014-August/007389.html
+ [XXX]: https://lists.eff.org/pipermail/https-everywhere/2014-August/002234.html
+ [XXX]: https://lists.torproject.org/pipermail/tor-dev/2014-August/007393.html
+
 Tor help desk roundup
 ---------------------
 
@@ -256,13 +276,3 @@
   * [https://defcon.org/html/defcon-22/dc-22-speakers.html#Vedaa Impostor — Polluting Tor Metadata] by Charlie Vedaa and Mike Larsen. The authors presented simple JavaScript programs designed to cause false positives for Tor-detecting rules in network monitors such as Snort, Bro, and XKeyScore. Their programs are at http://impostor.io/.
   * ''I (dcf) didn't see this one, so I can't say anything about it.''\\
     [https://defcon.org/html/defcon-22/dc-22-speakers.html#Metacortex Touring the Darkside of the Internet. An Introduction to Tor, Darknets, and Bitcoin] by Metacortex and Grifter.
-* Last round of GSoC reports:
-  - Revamp GetTor https://lists.torproject.org/pipermail/tor-dev/2014-August/007368.html
-  - wfpadtools https://lists.torproject.org/pipermail/tor-reports/2014-August/000623.html
-  - ahmia https://lists.torproject.org/pipermail/tor-reports/2014-August/000624.html
-  - Stegotorus https://lists.torproject.org/pipermail/tor-dev/2014-August/007377.html
-  - Orbot & Orfox https://lists.torproject.org/pipermail/tor-dev/2014-August/007379.html
-  - Consensus diff https://lists.torproject.org/pipermail/tor-dev/2014-August/007386.html
-  - multicore https://lists.torproject.org/pipermail/tor-dev/2014-August/007389.html
-  - HTTPS Everywhere https://lists.eff.org/pipermail/https-everywhere/2014-August/002234.html
-  - PT transport combiner https://lists.torproject.org/pipermail/tor-dev/2014-August/007393.html

version 44
Author: harmony
Date:   2014-08-19T12:40:06+00:00

   add clarification

--- version 43
+++ version 44
@@ -59,8 +59,8 @@
  [XXX]: https://blog.torproject.org/blog/how-use-%E2%80%9Cmeek%E2%80%9D-pluggable-transport
  [XXX]: https://www.torproject.org/dist/torbrowser/
 
-The Tor network doesn't support addressing relays by name anymore
------------------------------------------------------------------
+The Tor network no longer supports designating relays by name
+-------------------------------------------------------------
 
 Since the very first versions of Tor [XXX], relay operators have been
 able to specify “nicknames” for their relays. Such nicknames were initially
@@ -75,10 +75,11 @@
 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 with
-the same nickname in the whole network is not really problematic when
-one is looking at nodes, or a list in Globe [XXX], as relays can always
-be differentiated by their IP addresses or identity keys.
+and to designate a specific relay in an abbreviated way. Having two
+relays with the same nickname in the whole network is not really
+problematic when one is looking at nodes, or a list in Globe [XXX], 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
@@ -99,7 +100,9 @@
 problems. gabelmoo and tor26 have stopped acting as Naming Directory
 Authorities, and — pending any issues — will stay that way.”
 
-This means that designating relays by nickname has now stopped working.
+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

version 43
Author: harmony
Date:   2014-08-19T12:34:38+00:00

   some fixes

--- version 42
+++ version 43
@@ -63,43 +63,43 @@
 -----------------------------------------------------------------
 
 Since the very first versions of Tor [XXX], relay operators have been
-able specify “nicknames” for their relays. Such nicknames were initially
-meant to be unique accross the network, and operators of directory
+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 [XXX], and latter automated with the
+introduced in the 0.1.1 series [XXX], 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 address a specific relay in a shorter way. Having two relays with 
-the same nickname in the whole network is not really problematic when 
-one is looking at nodes, or a list on Globe [XXX] as relays can always 
-be differentiated by their IP addresses or identity keys. 
-
-But complications start when nicknames are used to specify a relay and 
-not another. If the wrong relay get selected, then it can become a 
-security risk. Even if a good amount of efforts [XXX] have been spent 
-trying to improve the situation, properly enforcing uniqueness has 
-always been problematic and a burden for the few directory authorities 
-handling naming. 
-
-Back in April, “Heartblead” [XXX] forced many relays to switch to a new
-identity key, thus loosing their “Named” flag. Because this meant that
-anyone addressing relays with nickname would now have a hard time
-continuing to do so, this was seen by Sebastian Hahn as the opportunity
+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 with
+the same nickname in the whole network is not really problematic when
+one is looking at nodes, or a list in Globe [XXX], 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 if real efforts [XXX] 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 [XXX] forced many relays to switch to
+a new identity key, thus losing their “Named” flag. Because this meant
+that anyone addressing relays with 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 [XXX].
 
 This week, Sebastian wrote [XXX]: “Code review down to 0.2.3.x has shown
-that the naming-related code hasn't changed much at all, and no issues
+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 mans that addressing relays by nicknames has now stopped working.
+This means that designating relays by nickname 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

version 42
Author: harmony
Date:   2014-08-19T12:27:59+00:00

   add isec item to misc

--- version 41
+++ version 42
@@ -123,6 +123,17 @@
 and instructions on how to download it.
 
  [XXX]: https://lists.torproject.org/pipermail/tor-dev/2014-August/007375.html
+
+Mike Perry posted an overview [XXX] 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.
+
+ [XXX]: https://blog.torproject.org/blog/isec-partners-conducts-tor-browser-hardening-study
 
 Nick Mathewson asked for comments [XXX] on Trunnel, “a little tool to
 automatically generate binary encoding and parsing code based on
@@ -252,4 +263,3 @@
   - multicore https://lists.torproject.org/pipermail/tor-dev/2014-August/007389.html
   - HTTPS Everywhere https://lists.eff.org/pipermail/https-everywhere/2014-August/002234.html
   - PT transport combiner https://lists.torproject.org/pipermail/tor-dev/2014-August/007393.html
-* iSEC Partners report https://blog.torproject.org/blog/isec-partners-conducts-tor-browser-hardening-study

version 41
Author: harmony
Date:   2014-08-19T11:56:18+00:00

   add missing link

--- version 40
+++ version 41
@@ -55,7 +55,7 @@
  [XXX]: https://blog.torproject.org/blog/tor-browser-364-and-40-alpha-1-are-released
  [XXX]: https://blog.torproject.org/blog/tor-security-advisory-relay-early-traffic-confirmation-attack
  [XXX]: https://trac.torproject.org/projects/tor/wiki/doc/meek
- [XXX]: XXX will link when I find out how to reference specific blog comments
+ [XXX]: https://blog.torproject.org/blog/how-use-%E2%80%9Cmeek%E2%80%9D-pluggable-transport#comment-70044
  [XXX]: https://blog.torproject.org/blog/how-use-%E2%80%9Cmeek%E2%80%9D-pluggable-transport
  [XXX]: https://www.torproject.org/dist/torbrowser/
 

version 40
Author: harmony
Date:   2014-08-19T11:19:08+00:00

   add item

--- version 39
+++ version 40
@@ -252,3 +252,4 @@
   - multicore https://lists.torproject.org/pipermail/tor-dev/2014-August/007389.html
   - HTTPS Everywhere https://lists.eff.org/pipermail/https-everywhere/2014-August/002234.html
   - PT transport combiner https://lists.torproject.org/pipermail/tor-dev/2014-August/007393.html
+* iSEC Partners report https://blog.torproject.org/blog/isec-partners-conducts-tor-browser-hardening-study

version 39
Author: harmony
Date:   2014-08-19T11:15:58+00:00

   add network down item

--- version 38
+++ version 39
@@ -134,6 +134,16 @@
 
  [XXX]: https://lists.torproject.org/pipermail/tor-dev/2014-August/007355.html
 
+George Kadianakis followed up his journey to the core [XXX] of what Tor
+does when trying to connect to entry guards in the absence of a network
+connection with another post [XXX] 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”.
+
+ [XXX]: https://lists.torproject.org/pipermail/tor-dev/2014-June/007042.html
+ [XXX]: https://lists.torproject.org/pipermail/tor-dev/2014-August/007346.html
+
 Arturo Filastò requested feedback [XXX] 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
@@ -232,7 +242,6 @@
   * [https://defcon.org/html/defcon-22/dc-22-speakers.html#Vedaa Impostor — Polluting Tor Metadata] by Charlie Vedaa and Mike Larsen. The authors presented simple JavaScript programs designed to cause false positives for Tor-detecting rules in network monitors such as Snort, Bro, and XKeyScore. Their programs are at http://impostor.io/.
   * ''I (dcf) didn't see this one, so I can't say anything about it.''\\
     [https://defcon.org/html/defcon-22/dc-22-speakers.html#Metacortex Touring the Darkside of the Internet. An Introduction to Tor, Darknets, and Bitcoin] by Metacortex and Grifter.
-* Guard nodes and network down events https://lists.torproject.org/pipermail/tor-dev/2014-August/007346.html
 * Last round of GSoC reports:
   - Revamp GetTor https://lists.torproject.org/pipermail/tor-dev/2014-August/007368.html
   - wfpadtools https://lists.torproject.org/pipermail/tor-reports/2014-August/000623.html

version 38
Author: harmony
Date:   2014-08-19T11:00:07+00:00

   add aphex twin

--- version 37
+++ version 38
@@ -10,7 +10,10 @@
 ========================================================================
 
 Welcome to the thirty-third issue of Tor Weekly News in 2014, the weekly
-newsletter that covers what is happening in the Tor community.
+newsletter that covers what is happening in the community around Tor,
+the anonymity network preferred by Aphex Twin [XXX].
+
+ [XXX]: https://www.dailydot.com/entertainment/aphex-twin-deep-web-album-syro/
 
 Tor Browser 3.6.4 and 4.0-alpha-1 are out
 -----------------------------------------
@@ -240,4 +243,3 @@
   - multicore https://lists.torproject.org/pipermail/tor-dev/2014-August/007389.html
   - HTTPS Everywhere https://lists.eff.org/pipermail/https-everywhere/2014-August/002234.html
   - PT transport combiner https://lists.torproject.org/pipermail/tor-dev/2014-August/007393.html
-* Aphex Twin Announces New Album SYRO on Tor Hidden Service: http://syro2eznzea2xbpi.onion http://pitchfork.com/news/56341-aphex-twin-announces-new-album-syro-via-the-deep-web/


===========================================================================
=== https://trac.torproject.org/projects/tor/wiki/TorWeeklyNews/2014/34 ===
===========================================================================

version 3
Author: harmony
Date:   2014-08-19T13:20:22+00:00

   add uncovered item from last week

--- version 2
+++ version 3
@@ -88,3 +88,12 @@
   [XXX]: https://trac.torproject.org/projects/tor/wiki/TorWeeklyNews
   [XXX]: https://lists.torproject.org/cgi-bin/mailman/listinfo/news-team
 }}}
+
+Possible items:
+
+* (''Not sure how to write this, I wish dcf could provide a short writeup -- Lunar'') Tor-related talks at [https://www.defcon.org/html/defcon-22/dc-22-index.html Def Con 22], August 7–10, 2014 in Las Vegas:
+  * [https://defcon.org/html/defcon-22/dc-22-speakers.html#Zoz Don’t Fuck It Up] ([http://dropcanvas.com/d85g8 slides], temporary URL) by Zoz. Zoz talked about how to use Tor and other tools to keep safe while practicing civil disobedience.
+  * [https://defcon.org/html/defcon-22/dc-22-speakers.html#Lackey Masquerade: How a Helpful Man-in-the-Middle Can Help You Evade Monitoring] ([https://www.portalmasq.com/portal-defcon.pdf slides], [http://arstechnica.com/information-technology/2014/08/a-portable-router-that-conceals-your-internet-traffic/ Ars Technica]) by Ryan Lackey, Marc Rogers, and the Grugq. The talk was different than what the title and abstract imply. They discussed a hardware "travel router" running Tor and pluggable transports (see pages 24 ff. of the slides).
+  * [https://defcon.org/html/defcon-22/dc-22-speakers.html#Vedaa Impostor — Polluting Tor Metadata] by Charlie Vedaa and Mike Larsen. The authors presented simple JavaScript programs designed to cause false positives for Tor-detecting rules in network monitors such as Snort, Bro, and XKeyScore. Their programs are at http://impostor.io/.
+  * ''I (dcf) didn't see this one, so I can't say anything about it.''\\
+    [https://defcon.org/html/defcon-22/dc-22-speakers.html#Metacortex Touring the Darkside of the Internet. An Introduction to Tor, Darknets, and Bitcoin] by Metacortex and Grifter.

version 2
Author: harmony
Date:   2014-08-19T13:18:34+00:00

   edit dates

--- version 1
+++ version 2
@@ -1,16 +1,17 @@
-''XXXth issue of Tor Weekly News. Covering what's happening from XXX Xth, 2014 to XXX Xth, 2014. To be released on XXX Xth, 2014.''
+''60th issue of Tor Weekly News. Covering what's happening from August 19th, 2014 to August 26th, 2014. To be released on August 27th, 2014.''
 
 '''Editor:''' 
 
-'''Subject:''' Tor Weekly News — XXX Xth, 2014
+'''Subject:''' Tor Weekly News — August 27th, 2014
 
 {{{
 ========================================================================
-Tor Weekly News                                            XXX Xth, 2014
+Tor Weekly News                                        August 27th, 2014
 ========================================================================
 
-Welcome to the Xth issue of Tor Weekly News in 2014, the weekly
-newsletter that covers what is happening in the XXX Tor community.
+Welcome to the thirty-fourth issue of Tor Weekly News in 2014, the
+weekly newsletter that covers what is happening in the XXX Tor
+community.
 
 Feature XXX
 -----------

version 1
Author: harmony
Date:   2014-08-19T13:16:38+00:00

   create page

--- 
+++ version 1
@@ -0,0 +1,89 @@
+''XXXth issue of Tor Weekly News. Covering what's happening from XXX Xth, 2014 to XXX Xth, 2014. To be released on XXX Xth, 2014.''
+
+'''Editor:''' 
+
+'''Subject:''' Tor Weekly News — XXX Xth, 2014
+
+{{{
+========================================================================
+Tor Weekly News                                            XXX Xth, 2014
+========================================================================
+
+Welcome to the Xth issue of Tor Weekly News in 2014, the weekly
+newsletter that covers what is happening in the XXX Tor community.
+
+Feature XXX
+-----------
+
+Feature 1 with cited source [XXX]
+
+ [XXX]:
+
+Monthly status reports for XXX month 2014
+-----------------------------------------
+
+The wave of regular monthly reports from Tor project members for the
+month of XXX has begun. XXX released his report first [XXX], followed
+by reports from name 2 [XXX], name 3 [XXX], and name 4 [XXX].
+
+ [XXX]:
+ [XXX]:
+ [XXX]:
+ [XXX]:
+
+Miscellaneous news
+------------------
+
+Item 1 with cited source [XXX].
+
+Item 2 with cited source [XXX].
+
+Item 3 with cited source [XXX].
+
+ [XXX]:
+ [XXX]:
+ [XXX]:
+
+Tor help desk roundup
+---------------------
+
+Summary of some questions sent to the Tor help desk. 
+
+News from Tor StackExchange
+---------------------------
+
+Text with cited source [XXX].
+
+ [XXX]:
+
+Easy development tasks to get involved with
+-------------------------------------------
+
+Text with cited source [XXX].
+
+ [XXX]: 
+
+Upcoming events
+---------------
+
+Jul XX-XX | Event XXX brief description
+          | Event City, Event Country
+          | Event website URL
+          |
+Jul XX-XX | Event XXX brief description
+          | Event City, Event Country
+          | Event website URL
+
+
+This issue of Tor Weekly News has been assembled by XXX, XXX, and
+XXX.
+
+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 [XXX], write down your
+name and subscribe to the team mailing list [XXX] if you want to
+get involved!
+
+  [XXX]: https://trac.torproject.org/projects/tor/wiki/TorWeeklyNews
+  [XXX]: https://lists.torproject.org/cgi-bin/mailman/listinfo/news-team
+}}}



-- 
Your friendly TWN monitoring script

      In case of malfunction, please reach out for lunar at torproject.org
          or for the worst cases, tell weasel at torproject.org to kill me.



More information about the news-team mailing list