[TWN team] Recent changes to the wiki pages
Lunar
lunar at torproject.org
Mon Aug 4 18:00:06 UTC 2014
===========================================================================
=== https://trac.torproject.org/projects/tor/wiki/TorWeeklyNews/2014/31 ===
===========================================================================
version 30
Author: harmony
Date: 2014-08-04T17:21:26+00:00
fix some bits
--- version 29
+++ version 30
@@ -31,13 +31,13 @@
The attack is suspected to be linked to a now-cancelled talk that was
due to be delivered at the BlackHat security conference [XXX]. There
-have been many fruitful research projects involving theoretical attacks
-on Tor’s security, but this was not one of them. Not only were there
-problems with the process of responsible disclosure, but, as Roger
-wrote, “the attacker encoded the name of the hidden service in the
-injected signal (as opposed to, say, sending a random number and keeping
-a local list mapping random number to hidden service name)”, thereby
-“[putting] users at risk indefinitely into the future”.
+have been several fruitful and positive research projects involving
+theoretical attacks on Tor’s security, but this was not among them. Not
+only were there problems with the process of responsible disclosure,
+but, as Roger wrote, “the attacker encoded the name of the hidden
+service in the injected signal (as opposed to, say, sending a random
+number and keeping a local list mapping random number to hidden service
+name)”, thereby “[putting] users at risk indefinitely into the future”.
On the other hand, it is important to note that “while this particular
variant of the traffic confirmation attack allows high-confidence and
@@ -85,15 +85,15 @@
worried users to act faster than operators of directory authorities.
Despite being “usually on the side of transparency”, Roger Dingledine
-udescribe [XXX] being “stuck” on the issue, “because the arms race is so
+described [XXX] being “stuck” on the issue, “because the arms race is so
lopsidedly against us”.
Roger explains: “we can scan for whether exit relays handle certain
websites poorly, but if the list that we scan for is public, then exit
-relays can mess with other websites and know they'll get away with it.
+relays can mess with other websites and know they’ll get away with it.
We can scan for incorrect behavior on various ports, but if the list of
ports and the set of behavior we do is public, then again relays are
-free to mess with things we don't look for.”
+free to mess with things we don’t look for.”
A better future and more transparency probably lies in adaptative test
systems run by multiple volunteer groups. Until they come to existence,
@@ -138,7 +138,7 @@
Anthony G. Basile announced a new release of tor-ramdisk, an i686 or
x86_64 uClibc-based micro Linux distribution whose only purpose is to
host a Tor server. Version 20140801 [XXX] updates Tor to version
-0.2.4.23, and the kernel to 3.15.7 with Gentoo's hardened patches.
+0.2.4.23, and the kernel to 3.15.7 with Gentoo’s hardened patches.
[XXX]: http://opensource.dyc.edu/pipermail/tor-ramdisk/2014-August/000132.html
@@ -150,15 +150,15 @@
less, cut, etcetera; download TBB through Tor, with pinned certs and signature
checking; and even spit out and run xplanet configs (with router/circuit
markers)!” The application is written in Python and uses the
-txtorcon library [XXX]. meejah describes it as early-alpha and warn that it
+txtorcon library [XXX]. meejah describes it as early-alpha and warns that it
might contain “serious, anonymity-destroying bugs”. Watch out!
[XXX]: https://lists.torproject.org/pipermail/tor-dev/2014-August/007295.html
[XXX]: https://github.com/meejah/carml
[XXX]: https://txtorcon.readthedocs.org/
-Only two weeks left for the Google Summer of Code students, and the last but
-one round of reports: Juha Nurmi on the ahmia.fi project [XXX], Marc Juarez on
+Only two weeks left for the Google Summer of Code students, and the last round of
+reports but one: Juha Nurmi on the ahmia.fi project [XXX], Marc Juarez on
website fingerprinting defenses [XXX], Amogh Pradeep on Orbot and Orfox
improvements [XXX], Zack Mullaly on the HTTPS Everywhere secure ruleset update
mechanism [XXX], Israel Leiva on the GetTor revamp [XXX], Quinn Jarrell on the
@@ -177,7 +177,7 @@
[XXX]: https://lists.torproject.org/pipermail/tor-dev/2014-August/007293.html
The Tails team is looking for testers to solve a possible incompatiblity
-in one of the recommended installation procedure. If you have a running Tails
+in one of the recommended installation procedures. If you have a running Tails
system, a spare USB stick and some time, please help [XXX]. Don't miss
the recommended command-line options [XXX]!
version 29
Author: harmony
Date: 2014-08-04T17:16:05+00:00
security advisory item
--- version 28
+++ version 29
@@ -12,12 +12,64 @@
Welcome to the thirty-first 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]:
+Tor and the RELAY_EARLY traffic confirmation attack
+---------------------------------------------------
+
+Roger Dingledine ended several months of concern and speculation in the
+Tor community with a security advisory posted to the tor-announce
+mailing list [XXX] and the Tor blog [XXX].
+
+In it, he gave details of a five-month-long active attack on operators
+and users of Tor hidden services that involved a variant of the
+so-called “Sybil attack”: the attacker signed up “around 115 fast
+non-exit relays” (now removed from the Tor network), and configured them
+to inject a traffic header signal consisting of RELAY_EARLY cells to
+“tag” any hidden service descriptor requests received by malicious
+relays — a tag which could then be picked up by other bad nodes acting
+as entry guards [XXX], in the process identifying clients which
+requested information about a particular hidden service.
+
+The attack is suspected to be linked to a now-cancelled talk that was
+due to be delivered at the BlackHat security conference [XXX]. There
+have been many fruitful research projects involving theoretical attacks
+on Tor’s security, but this was not one of them. Not only were there
+problems with the process of responsible disclosure, but, as Roger
+wrote, “the attacker encoded the name of the hidden service in the
+injected signal (as opposed to, say, sending a random number and keeping
+a local list mapping random number to hidden service name)”, thereby
+“[putting] users at risk indefinitely into the future”.
+
+On the other hand, it is important to note that “while this particular
+variant of the traffic confirmation attack allows high-confidence and
+efficient correlation, the general class of passive (statistical)
+traffic confirmation attacks remains unsolved and would likely have
+worked just fine here”. In other words, the tagging mechanism used in
+this case is the innovation; the other element of the attack is a known
+weakness of low-latency anonymity systems, and defending against it is a
+much harder problem.
+
+“Users who operated or accessed hidden services from early February
+through July 4 should assume they were affected” and act accordingly; in
+the case of hidden service operators, this may mean changing the
+location of the service. Accompanying the advisory were two new releases
+for both the stable and alpha tor branches (0.2.4.23 and 0.2.5.6-alpha);
+both include a fix for the signal-injection issue that causes tor to
+drop circuits and give a warning if RELAY_EARLY cells are detected going
+in the wrong direction (towards the client), and both prepare the ground
+for clients to move to single entry guards (rather than sets of three)
+in the near future. Relay operators should be sure to upgrade; a
+point-release of the Tor Browser bundle will offer the same fixes to Tor
+clients. Nusenu suggested [XXX] that relay operators regularly check
+their logs for the new warning, “even if the attack origin is not
+directly attributable from a relay’s point of view”. Be sure to read the
+full security advisory for a fuller explanation of the attack and its
+implications.
+
+ [XXX]: https://lists.torproject.org/pipermail/tor-announce/2014-July/000094.html
+ [XXX]: https://blog.torproject.org/blog/tor-security-advisory-relay-early-traffic-confirmation-attack
+ [XXX]: https://www.torproject.org/docs/faq#EntryGuards
+ [XXX]: https://blog.torproject.org/blog/recent-black-hat-2014-talk-cancellation
+ [XXX]: https://lists.torproject.org/pipermail/tor-relays/2014-August/005046.html
Why is bad-relays a closed mailing list?
----------------------------------------
@@ -185,5 +237,4 @@
Possible items:
- * Tor security advisory: "relay early" traffic confirmation attack https://lists.torproject.org/pipermail/tor-announce/2014-July/000094.html https://lists.torproject.org/pipermail/tor-relays/2014-August/005046.html
* Proposal 236 and the guardiness of a guard https://lists.torproject.org/pipermail/tor-dev/2014-July/007269.html
--
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