Version 37 (modified by dope457, 7 years ago) (diff)

ported events from the last issue

Twelfth issue of Tor Weekly News. Covering what's happening from September 10th, 2013 to September 17th, 2013. To be released on September 18th, 2013.

Editor: harmony

Subject: Tor Weekly News — September, 18th 2013

Tor Weekly News                                     September 18th, 2013

Welcome to the twelfth issue of Tor Weekly News, the weekly newsletter that
covers what is happening in the closely-observed Tor community.

New Release of XXX

XXX: cite specific release date, numbers, and developers responsible

XXX: details about release


Official response to QUICK ANT disclosure

Another round of speculation regarding the attitude of state surveillance
agencies towards the Tor network was provoked by a slide [XXX] featured in an
edition of the Brazilian current-affairs show 'Fantástico', broadcast on
September 8th [XXX]. The slide, leaked as part of the ongoing Snowden
disclosures, appeared to show a tab in the alleged GCHQ [XXX] FLYING PIG
surveillance interface labelled 'Query QUICK ANT - Tor events QFD'. Users
on Reddit [XXX] and Twitter [XXX] began to suggest possible attacks on Tor
that might be managed through such an interface.

Andrew Lewman posted an official response on the Tor Blog [XXX] in which
he reiterated that "it's not clear what the NSA or GCHQ can or cannot do",
and that well-known theoretical attacks against the Tor network are clearly
described on the project's FAQ page [XXX].

He further added that the tool in question was more likely to involve
"some "Tor flow detector" scripts that let them pick Tor flows out of a
set of flows they're looking at" than "anything to do with deanonymizing
Tor users, except insofar as they might have traffic flows from both sides
of the circuit in their database."

Finally, he remarked that instead of engaging in speculation based on
limited evidence, "we'd rather spend our time developing Tor and conducting
research to make a better Tor."


Entry guards and linkability

Leif Ryge pointed out [XXX] an issue with Tor's current 'entry guards'
system, whereby connections entering Tor from different points on the
same network could potentially be linked to an individual user based on
the three entry nodes selected by that user's Tor client, which remain
constant for a period of 4-8 weeks [XXX].

Leif suggested that "assuming this is an accurate assessment, wouldn't
it make sense to maintain separate sets of entry guards for each network
that the user connects from?"

Nick Mathewson replied [XXX] with an acknowledgement of the problem and
a number of reasons why simply generating separate sets of guards might
also harm a user's anonymity: "You would *not*, for example, want to
maintain a different set of entry guards for every IP that you receive,
since if you did, a hostile DHCP server could feed you new IPs until you
picked a hostile guard. Similarly, if you are a busy traveller who changes
your view of what network you are on hundreds or thousands of times, your
chance of picking a hostile guard would rise accordingly." He also pointed
out that "having a record in your state file of every network you have
visited is not necessarily the best idea either."

Nick concluded by mentioning Roger Dingledine's proposal to lower the
number of entry guards selected by a client to one only, "to avoid the
property of letting guard choices identify Tor clients".


The lifecycle of a new relay: further research needed

In response to some confusion on the part of relay operators over the
apparently slow growth in the use of newly-established nodes by clients,
Roger Dingledine posted on the Tor Blog [XXX] a detailed account of how
new relays, and the bandwidth they supply, are gradually integrated into
the Tor network by directory authorities, bandwidth authorities, and clients
themselves. Roger stressed that "the descriptions here are in part anecdotal".

Roger described the four broad phases that define the development of a
relay within the network, and finished by offering a number of questions
for further research, under a general rubric: "what do these phases look
like with real-world data?" If you would like to contribute to the Tor
community's understanding of the interaction between individual relays
and the network as a whole, please take a look both at the list of sample
questions and at Tor's publicly-available archive of metrics data [XXX],
and see what you can find!


Quote of the week

“Back in the ancient pre-Tor days, at the height of the crypto wars, Ian
Goldberg asked me at Financial Crypto in 1998 why we created onion
routing. Not entirely facetiously I told him that the fascinating
technological problems and the potential to better protect people and
their activities was nice, but the real attraction was to create a
context where people who were sure they should hate each other were
forced to collaborate.” [XXX]

 — Paul Syverson


Miscellaneous news

Brian Callahan alerted relay operators running FreeBSD and OpenBSD to the
release of ports updated to the new tor [XXX].

Christian Sturm then promptly announced the release of updated packages for
NetBSD, DragonFly BSD, illumos, Minix, and "other systems potentially using
pkgsrc" [XXX].


Karsten Loesing updated tor's GeoIP database to the newest version [XXX].


The commitment level for the proposed Tor StackExchange page is hovering
at 73%; it needs to reach 100% before it will be accepted. If you think
you will be able to contribute by answering questions from current or
potential Tor users, please sign up! [XXX]


Fabio Pietrosanti announced that the available cipher suites for connections
to have been updated to a much stronger set [XXX].


Robert published the results of an investigation into different kinds of
round-trip time (RTT) measurement, and their efficiency in building circuits
through the Tor network [XXX].


George Kadianakis asked for comments on his early draft of a proposal for
different methods of migrating the Hidden Service protocol to a more secure
version [XXX].


In the course of a thread about the size of browser windows posing a
fingerprinting threat, harmony discovered that users of Ubuntu's Unity
desktop should disable the 'automaximize' behavior, as it can override one
of Tor Browser's anti-fingerprinting measures [XXX].


Tom Lowenthal submitted his monthly status report for August [XXX].



XXX: Reported vulnerabilities [XXX].

 [XXX] vulnerability report source

Upcoming events

Sep 29    | Colin at the Winnipeg Cryptoparty
          | Winnipeg, Manitoba, Canada
Sep 29-01 | Tor at OpenITP Circumvention Tech Summit IV
          | Berlin, Germany
Oct 09-10 | Andrew speaking at Secure Poland 2013
          | Warszawa, Poland

This issue of Tor Weekly News has been assembled by harmony, Lunar, dope457,
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!


Possible items: