Tor Weekly News — December 3rd, 2014

Welcome to the forty-eighth issue in 2014 of Tor Weekly News, the weekly newsletter that covers what’s happening in the Tor community.

GetTor is back

Some Tor users need to access the Internet from networks so heavily censored that they cannot reach the Tor Project website, or any of its mirrors, to download Tor in the first place; with these users in mind, GetTor, an alternative software distribution system for Tor Browser, was created.

After a period of neglect, GetTor has been revamped and redeployed: users can now email the name of their operating system to, and in return they will receive Dropbox download links for the latest Tor Browser and the package signature, as well as a checksum and the fingerprint of the key used to make the signature.

The lead developer on this project is Israel Leiva, who did most of the work on it during this year’s Google Summer of Code. Israel took to the Tor blog to explain the background and outcome of the redevelopment work; please see that post for more information, or put GetTor to the test yourself and send your comments to the community!

Monthly status reports for November 2014

The wave of regular monthly reports from Tor project members for the month of November has begun. Damian Johnson released his report first, followed by reports from Juha Nurmi, George Kadianakis, David Goulet, Philipp Winter, Sherief Alaa, Tom Ritter, Nick Mathewson, Georg Koppen, Griffin Boyce, Karsten Loesing, Andrew Lewman (for both October and November), Noel Torres, and Harmony.

George Kadianakis also sent out the SponsorR report, while Colin C. reported on behalf of the help desk, and Mike Perry for the Tor Browser team.

Miscellaneous news

Nathan Freitas announced version 14.1.4 of Orbot, the Tor client for Android, which brings with it further improvements to background service operation, as well as theme and layout tweaks.

After much back-and-forth, work by Andrea Shepard to make Tor’s cell scheduling mechanism more efficient was finally merged. Although performance is not yet affected, these changes could form the basis of other improvements to managing congestion caused by “mismanaged socket output” in the Tor network, as discussed by Jansen et al. in “Never Been KIST”.

Following a discussion with David Goulet, Nick Mathewson posted a draft proposal of possible improvements to integration testing for Tor.

Sebastian Hahn informed users of the Tor Project’s git repositories that cloning via the unauthenticated git:// protocol is no longer supported — secure https:// access has been and still is the preferred method for retrieving code.

Gareth Owen started a discussion of suspicious relay behaviors that automated Tor network tests could scan for, in addition to those that are already monitored.

Tor help desk roundup

The help desk has been asked how to set up a relay on a Windows laptop. We don’t recommend running a relay on a laptop: the relays that are most useful to the network have faster bandwidth than most home internet connections can offer. Relays also need to have as much uptime as possible, and a laptop that gets put to sleep and woken up once a week or more is not a good computing environment for a relay that should serve the network in a consistent way.

We are not able to provide much help to users who report errors when using any of the Vidalia bundles, as Vidalia is no longer maintained.

This issue of Tor Weekly News has been assembled by Matt Pagan, Nick Mathewson, Roger Dingledine, and Harmony.

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

Say hi to the new GetTor

Hello people. It's been a while since Google Summer of Code 2014 ended, but I wanted to give you a brief review of the work done on GetTor.

What is GetTor?

GetTor is a program that serves Tor Browser over email. In the past, people would make requests by sending emails to GetTor, which would send back Tor Browser as email attachments. In highly censored countries (and places) where the Tor Project website is blocked, GetTor would be a convenient way for people to get access to Tor Browser.

There were lots of nice features incorporated in GetTor, such as specifying the operating system and language for the package wanted, or sending delay messages to let people know the package was on its way. But Tor Browser started to get larger in size (over 25 MB), to the point where it wasn't longer possible to send it via most email providers.


It wasn't long until a solution for this problem came up. The idea consisted on uploading Tor Browser to the cloud (Dropbox) and when someone asked for it via GetTor, a reply with the links for download was sent. This worked quite well, but the fix was far from being complete and at that point the whole GetTor was in need of some love to get back to its shiny days.

Google Summer of Code

All of what I mentioned was listed on the Volunteer page of the Tor Project website, so when I got there looking for a project to work on for the Google Summer of Code, I immediatly considered it into my options, because of the social impact of GetTor as for the technical skills required. I was happy to learn that my proposal got accepted and I was one of the fourteen students selected to work on the Tor Project during the northern hemisphere summer (actually, it was winter here in Chile).

First, I started to work on the design, making sure that when I started to code, most of the ideas I would be implementing were carefully described and discussed. Of course, a lot of things did change over the coding period, some of them small stuff like how the links would be internally stored by GetTor, and some of them not so small, like changing one of the distribution modules.

Anyhow, I don't want to bore you with technical details here, but if you're interested, please read my biweekly reports and check the code repository.


The coding period lasted a little more than three months, and I managed to pass both mid-term and final evaluations. But more importantly, the status of GetTor improved significantly during that time. I did a full rewrite of it, focusing on having clean and readable code, and on making it easy to add new distribution modules and cloud providers for storing Tor Browser. Two distribution modules were successfully finished: SMTP, for asking via email; and XMPP, for asking via Jabber (you know, chat style).

Even though the new GetTor is able to manage requests in multiple locales, for now the SMTP module has been deployed with support for English requests only; other locales and modules will eventually/gradually be supported. We will let you know when that happens (soon we hope!).

Almost all of the testing and other minor fixes were done after the Google Summer of Code ended, and this is because I explicitly mentioned to my mentors that I have the intention to keep working on it and to continue as the lead developer if needed. It's not just for the work I did, but more importantly for the possibility of helping other people, specially those that have the bad fortune to live under regimes and/or organizations which think they can impose control on the information you can access, spy on what you do and chase you for what you think. If I have the chance to help avoiding this dystopia, as little as I can, I would certainly do whatever is in my hands, and I invite you to do the same.

Great, but how do I use it?

You can reach GetTor by sending emails to To ask for Tor Browser, you just have to send an email with the word windows in the body to get it for Windows, osx to get it for Mac OSX, or linux to get it for Linux. The options are case insentitive, so it doesn't matter if you send Linux, or linux, or LiNuX, as long as it describes one of the options mentioned before; if you send anything different from that, you will receive a help message with detailed instructions on how to interact with it. Once you ask for Tor Browser, GetTor will reply to you with Dropbox links to download the required package for your architecture (32/64 bit) and operating system, along with some extra information to help you verify the integrity of the downloaded files. Please note that you can reach GetTor from any email address: gmail, yahoo, hotmail, riseup, etc. The only restriction is that you can do a maximum of three requests in a row, after that you'll have to wait 20 minutes to reach GetTor again. You can find out more about its purpose and how it works here.


The main way to collaborate is to use GetTor and provide feedback! Please tell us what you like, what you don't like, what works smoothly and what doesn't work or could work better; after all, GetTor is here for you, so you should tell us what we need to do :) For this, please open a ticket on the trac system under the GetTor component. You can file anything from usability suggestions/bugs to new development ideas.

On the other hand, I've read lots of people who are interested to collaborate with the Tor Project and they just don't know where to start or they are looking for something easy to collaborate with. The code and work on GetTor is quite straightforward, so if you know some Python and have some free time that you feel you want to give to an awesome open source organization, check the git repository and the tickets and you might find something easy to start with. There are various ideas and things left to do in GetTor, so please join us!

Other options

It's important to note that there are a couple more options to obtain Tor Browser when you cannot access Tor Project's website. The first and easiest is to access the official mirrors: EFF and If those sites are blocked too, you can try using Satori, an app for Google Chrome that distributes various circumvention tools in a difficult-to-block way, making it easy for users to check if the software has been tampered. If after all, you manage to get the Tor Browser but you are not able to reach the Tor network, you might want to use bridges or the pluggable transports. You can read more about that here, here and here.


I want to end this blog post by thanking to the Tor Project organization in general for letting me be part of it during the summer and kindly answer any doubt that came up, and to Sukhbir and Nima in particular for their awesome job as mentors, I couldn't have done it without you, thanks a lot guys!

Tor Weekly News — November 26th, 2014

Welcome to the forty-seventh issue in 2014 of Tor Weekly News, the weekly newsletter that covers what’s happening in the Tor community.

A new Tor directory authority

Tor, being free software, can be used by anyone to set up their own anonymity network, as Tom Ritter demonstrated last month; but “the Tor network” as we know it today consists of the 6500+ relays voted on by nine “directory authorities” (or “dirauths”), operated by trusted members of the Tor development team and community.

As Mike Perry, a longtime directory authority operator, wished to retire his machine, “turtles”, without unbalancing the number of authorities producing the consensus, a new authority named “longclaw” was brought online by the autonomous tech collective Riseup, which has been offering free and secure methods of communication (most of them now available as hidden services) since 1999.

Thanks to Riseup for playing this key role in the operation of the Tor network!

Miscellaneous news

Nathan Freitas announced the release of Orbot 14.1.3, which includes improved handling of background processes; it builds on the earlier 14.1.0, which brought with it support for Android 5.0 Lollipop, as well as stability fixes. Orweb was brought up to version 0.7, also introducing support for the new Android release.

George Kadianakis sent out a co-authored draft of a proposal for statistics concerning hidden service activity that relays could collect and publish without harming the anonymity or security of users and hidden services, and which might “be useful to Tor developers and to people who want to understand hidden services and the onionspace better.”

Tom Ritter drafted a proposal exploring methods a hidden service operator might use to prove to certificate authorities that they control the service’s private key when requesting SSL certificates.

Karsten Loesing spruced up the documentation on the Tor Metrics portal, including a handy glossary of frequently-used Tor-specific terms.

Damian Johnson sketched out a roadmap for further development of Stem, the Tor controller library in Python, welcoming “more general ideas on directions to take Stem, the tor-prompt, and this whole space”.

Andrew Lewman reported on his experiments in mirroring the Tor Project website using the Fastly CDN as well as the BitTorrent Sync application.

Following a suggestion that a guide to server hardening should be distributed with the tor software package, Libertas drafted a sample document and asked for reviews. “Please share any opinions or contributions you have. This was written in a little more than an hour, so it’s still a work in progress.”

Libertas also scanned a large number of currently-running Tor relays to check which ssh access authentication methods their servers supported, finding 2051 relays that still permitted password-based ssh authentication. “Generally, it is far more secure to allow only public key auth. The Ubuntu help pages have a good guide on setting up key-based auth”.

SiNA Rabbani noted that a large proportion of Tor exit relays are located in Europe, and called for relay operators to consider running nodes with US hosts. “I am not sure if the reason is lack of Tor-friendly ISPs or people are just too freaked out about the summer of Snowden. I think it’s very wrong to assume that EU countries are not part of the world-wide-wiretap, packets are going through a few internet exchanges anyways.”

Thanks to Andy Weber, Matt Kraai, Alexander Dietrich, James Murphy, Jesse Victors, Lucid Networks,, NTU Open Source Society, and Justaguy for running mirrors of the Tor Project’s website and software!

Tor help desk roundup

The help desk commonly sees questions from users who get error messages when using Vidalia, the graphical Tor controller. Vidalia is unmaintained and many of its features simply do not work any more, so it has been deprecated. For web browsing, only the latest version of Tor Browser should be used. If you were trying to use the (now also defunct) Vidalia Bridge or Relay Bundles, documentation for how to set up bridges and regular relays more effectively without Vidalia can be found on the website.

This issue of Tor Weekly News has been assembled by Harmony, Matt Pagan, Roger Dingledine, and Karsten Loesing.

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

Quick Summary of recent traffic correlation using netflows

Here’s what you need to know about the recent research study on traffic correlation attacks:

While it’s great to see more research on traffic correlation attacks, this is not a new area of research. This is one study on the subject in a controlled environment using one readily available traffic monitoring technology to analyze Tor traffic. The researcher has clarified in the media that it was only 81.4 percent of their experiments not “81 percent of all Tor traffic” as has been reported elsewhere.

The Tor network provides anonymity by routing the user’s information through multiple servers (usually three) so that it is hard to detect the person’s physical location.

Tor protects users by:
1) encryption to ensure privacy of data within the Tor network,
2) authentication so clients know they're talking to the relays they meant to talk to, and
3) signatures to make sure all clients know the same set of relays.

In theory it may be possible to track Tor users by linking up their entry and exit points on the network but it is generally very difficult to do so. The Tor network design, however, does not protect against a targeted attack by a global passive adversary (such as the NSA) intent on figuring out whom to investigate through watching and measuring Tor traffic going into and out of the network and correlating the information on both sides. We encourage you to learn more about what Tor does provide.

Tor is used by 2.5 million people a day including the general public, journalists, companies, activists, military, and law enforcement and is a very safe, reliable way to protect your privacy on the Internet.

Tor Weekly News — November 19th, 2014

Welcome to the forty-sixth issue in 2014 of Tor Weekly News, the weekly newsletter that covers what’s happening in the Tor community.

Tor Browser 4.5-alpha-1 is out

Mike Perry announced the first alpha release in the Tor Browser 4.5 series. This version goes some way to restoring one of the features most missed by users following the removal of the now-defunct Vidalia interface from Tor Browser — the ability to quickly visualize the Tor circuit that the current page is using. Clicking on the green Torbutton icon in the Tor Browser window now brings up a small diagram showing the IP addresses of all relays in a circuit, and the states in which they are located; this may help users evaluate the suitability of the circuits their Tor has selected, and also to quickly identify a malicious exit relay if they notice unusual behavior in downloaded pages and files.

Another key user-facing innovation in this release is the “security slider”. Users can now choose from four security settings in Torbutton’s “Preferences” window — “low (default)”, “medium-low”, “medium-high”, and “high” — that allow them to customize their Tor Browser based on their own security and usability needs, while still working to prevent “partitioning” attacks, which try to identify users based on their unusual browser configuration.

For other important additions in this series, please see the full changelog in Mike’s post. If you want to try out this alpha version, you can find it on the Tor Browser project page or in the distribution directory; please report any bugs you find!

Tor Browser on 32-bit Macs approaches end-of-life

Now that Apple has discontinued support for the last remaining 32-bit Mac systems, Mike Perry announced that the Tor Browser team will soon stop distributing 32-bit builds of its software. This week’s 4.5-alpha-1, like all future releases in the 4.5 series, is only available in a 64-bit build, and all support for 32-bit systems will end once 4.5 supersedes 4.0.

“32-bit Mac users likely have a month or two to decide what to do”, wrote Mike. “If your actual Mac hardware is 64-bit capable, you can upgrade to either the 64-bit edition of OSX 10.6 (which we will continue to support for a bit longer), or use the app store to upgrade to 10.9 or 10.10. If your hardware is not 64-bit capable and won’t run these newer Mac operating systems, you should still be able to use Tails, which contains the Tor Browser.”

As a side effect of this transition, Tor Browser 4.0’s experimental in-browser secure updater will not handle the upgrade to the 64-bit build correctly for any Mac user; the old version must instead be replaced manually with the new one.

Miscellaneous news

Roger Dingledine and Sambuddho Chakravarty responded on the Tor blog to inaccurate reports of a new attack against Tor, based on a recent study co-authored by Sambuddho. “It’s great to see more research on traffic correlation attacks, especially on attacks that don’t need to see the whole flow on each side. But it’s also important to realize that traffic correlation attacks are not a new area”, wrote Roger.

The Tails team set out the December release schedule for version 1.2.1 of the anonymous live operating system.

Giovanni Pellerano announced version 3.1.30 of Tor2web, which now supports web access to Tor hidden services over TLS. Access to the Facebook hidden service, the most high-profile instance of an HTTPS-enabled .onion site, is blocked in this version, as Tor2web offers no benefit in cases where there exists an identical service on the regular or “naked” web, and may actually present additional risk of compromise.

Griffin Boyce requested feedback on a “very rough” version of Stormy, the simple hidden service setup wizard. “I’d love to get feedback on places where it breaks and where it could use a major structural change […] the current setup is entirely for development and should not be used as-is.”

Virgil Griffith started a discussion on the suitability of the name “hidden services” as opposed to other possible terms like “onion service” or “onion site”. Among the many responses, Roger Dingledine suggested that an alternative name like “onion service” “makes people have to learn what it is rather than guessing (and often guessing wrong)”, while Nathan Freitas pointed out that as “typical users don’t talk about web services, they talk about web sites or pages”, “onion site” might be a term worth adopting.

Tom Ritter put forward a number of improvements to the integration of HTTPS certificates and hidden services, following “a spirited debate on IRC”.

The Wikimedia Foundation is the latest high-profile organization to set up a non-exit Tor relay. “It’s just a small contribution to the network. Really — anyone can do it.”

This issue of Tor Weekly News has been assembled by Harmony and Lunar.

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

Tor Browser 4.5-alpha-1 is released

The first alpha release of the 4.5 series is available from the extended downloads page and also from our distribution directory.

This release features a circuit status reporting UI (visible on the green Tor onion button menu), as well as isolation for circuit use. All content elements for a website will use a single circuit, and different websites should use different circuits, even when viewed at the same time. The Security Slider is also present in this release, and can be configured from the green Tor onion's Preferences menu, under the Privacy and Security settings tab. It also features HTTPS certificate pinning for selected sites (including our updater), which was backported from Firefox 32.

This release also features a rewrite of the obfs3 pluggable transport, and the introduction of the new obfs4 transport. Please test these transports and report any issues!

Note to Mac users: As part of our planned end-of-life for supporting 32 bit Macs, the Mac edition of this release is 64 bit only, which also means that the updater will not work for Mac users on the alpha series release channel for this release. Once you transition to this 64 bit release, the updater should function correctly after that.

Here is the complete changelog since 4.0.1:

  • All Platforms
    • Bug 3455: Patch Firefox SOCKS and proxy filters to allow user+pass isolation
    • Bug 11955: Backport HTTPS Certificate Pinning patches from Firefox 32
    • Bug 13684: Backport Mozilla bug #1066190 (pinning issue fixed in Firefox 33)
    • Bug 13019: Make JS engine use English locale if a pref is set by Torbutton
    • Bug 13301: Prevent extensions incompatibility error after upgrades
    • Bug 13460: Fix MSVC compilation issue
    • Bug 13504: Remove stale bridges from default bridge set
    • Bug 13742: Fix domain isolation for content cache and disk-enabled browsing mode
    • Update Tor to
    • Update NoScript to
    • Bug 13586: Make meek use TLS session tickets (to look like stock Firefox).
    • Bug 12903: Include obfs4proxy pluggable transport
    • Update Torbutton to
      • Bug 9387: Provide a "Security Slider" for vulnerability surface reduction
      • Bug 13019: Synchronize locale spoofing pref with our Firefox patch
      • Bug 3455: Use SOCKS user+pass to isolate all requests from the same url domain
      • Bug 8641: Create browser UI to indicate current tab's Tor circuit IPs
      • Bug 13651: Prevent circuit-status related UI hang.
      • Bug 13666: Various circuit status UI fixes
      • Bug 13742+13751: Remove cache isolation code in favor of direct C++ patch
      • Bug 13746: Properly update third party isolation pref if disabled from UI
  • Windows
    • Bug 13443: Re-enable DirectShow; fix crash with mingw patch.
    • Bug 13558: Fix crash on Windows XP during download folder changing
    • Bug 13091: Make app name "Tor Browser" instead of "Tor"
    • Bug 13594: Fix update failure for Windows XP users
  • Mac
    • Bug 10138: Switch to 64bit builds for MacOS

End of life plan for Tor Browser on 32 bit Macs

Updated on March 31, 2015: Clarify 4.5 release timeframe and manual update section

We are planning to discontinue support for 32 bit Macs for Tor Browser.

We're doing this for two main reasons. First, Apple itself no longer supports 32 bit Macs. The only remaining 32 bit Mac users are on OSX 10.6, which Apple ended support for in February 2014. Second, 64 bit software has improved security properties by way of improved address space layout randomization (ASLR), which makes exploitation more difficult.

This transition will happen in phases: First, the upcoming 4.5-alpha series will only be available as 64 bit builds. We will continue releasing 32 bit versions of the 4.0 series until the 4.5 series is declared stable. When the 4.5 release stabilizes, all support for 32 bit Macs will end. The 4.5 release series will become stable in mid-April of 2015. This means that 32 bit Mac users should begin investigating their options now.

Not all 10.6 Mac OS users are on 32 bit systems. According to Apple's support website, only two CPU models (the Intel Core Solo and the Intel Core Duo) were released that can not run 64 bit code. As long as you do not have those processors, your Mac should be able to run the 64 bit Tor Browser 4.5 just fine. However, we strongly encourage you to upgrade to a newer version of Mac OS even so, as you are not receiving security updates.

If your hardware is not 64 bit capable or your system won't run Tor Browser 4.5, you should still be able to use Tails, which contains the Tor Browser. You can run Tails in a virtual machine such as VirtualBox, or you can manually install it to a USB disk from the Mac OS Terminal. If you install Tails to a USB stick, you will need to reboot your Mac in order to use it.

10.6 and 10.7 Mac Users: Manual Update Required

Most Mac users should should be updated to the new 4.5 series automatically by the in-browser updater in mid-May 2015. However, due to technical limitations with determining the ability of early Mac systems to properly run 64 bit programs, we are unable to safely and reliably determine if Snow Leopard (10.6) or Lion (10.7) Mac users will successfully be able to run a 64 bit Tor Browser update, and so we have disabled the in-browser updater for those versions.

This means that you must perform this update manually, as you had to do prior to the 4.0 series. To do this, download the 4.5 DMG and drag the new 64 bit Tor Browser 4.5 over your old Tor Browser 4.0, and replace the application. Again, if the new 64 bit Tor Browser does not function on your system, we recommend using Tails, as described above.

Once you are running the 64 bit version, updates should function correctly again.

Traffic correlation using netflows

People are starting to ask us about a recent tech report from Sambuddho's group about how an attacker with access to many routers around the Internet could gather the netflow logs from these routers and match up Tor flows. It's great to see more research on traffic correlation attacks, especially on attacks that don't need to see the whole flow on each side. But it's also important to realize that traffic correlation attacks are not a new area.

This blog post aims to give you some background to get you up to speed on the topic.

First, you should read the first few paragraphs of the One cell is enough to break Tor's anonymity analysis:

First, remember the basics of how Tor provides anonymity. Tor clients route their traffic over several (usually three) relays, with the goal that no single relay gets to learn both where the user is (call her Alice) and what site she's reaching (call it Bob).

The Tor design doesn't try to protect against an attacker who can see or measure both traffic going into the Tor network and also traffic coming out of the Tor network. That's because if you can see both flows, some simple statistics let you decide whether they match up.

Because we aim to let people browse the web, we can't afford the extra overhead and hours of additional delay that are used in high-latency mix networks like Mixmaster or Mixminion to slow this attack. That's why Tor's security is all about trying to decrease the chances that an adversary will end up in the right positions to see the traffic flows.

The way we generally explain it is that Tor tries to protect against traffic analysis, where an attacker tries to learn whom to investigate, but Tor can't protect against traffic confirmation (also known as end-to-end correlation), where an attacker tries to confirm a hypothesis by monitoring the right locations in the network and then doing the math.

And the math is really effective. There are simple packet counting attacks (Passive Attack Analysis for Connection-Based Anonymity Systems) and moving window averages (Timing Attacks in Low-Latency Mix-Based Systems), but the more recent stuff is downright scary, like Steven Murdoch's PET 2007 paper about achieving high confidence in a correlation attack despite seeing only 1 in 2000 packets on each side (Sampled Traffic Analysis by Internet-Exchange-Level Adversaries).

Second, there's some further discussion about the efficacy of traffic correlation attacks at scale in the Improving Tor's anonymity by changing guard parameters analysis:

Tariq's paper makes two simplifying assumptions when calling an attack successful [...] 2) He assumes that the end-to-end correlation attack (matching up the incoming flow to the outgoing flow) is instantaneous and perfect. [...] The second one ("how successful is the correlation attack at scale?" or maybe better, "how do the false positives in the correlation attack compare to the false negatives?") remains an open research question.

Researchers generally agree that given a handful of traffic flows, it's easy to match them up. But what about the millions of traffic flows we have now? What levels of false positives (algorithm says "match!" when it's wrong) are acceptable to this attacker? Are there some simple, not too burdensome, tricks we can do to drive up the false positives rates, even if we all agree that those tricks wouldn't work in the "just looking at a handful of flows" case?

More precisely, it's possible that correlation attacks don't scale well because as the number of Tor clients grows, the chance that the exit stream actually came from a different Tor client (not the one you're watching) grows. So the confidence in your match needs to grow along with that or your false positive rate will explode. The people who say that correlation attacks don't scale use phrases like "say your correlation attack is 99.9% accurate" when arguing it. The folks who think it does scale use phrases like "I can easily make my correlation attack arbitrarily accurate." My hope is that the reality is somewhere in between — correlation attacks in the current Tor network can probably be made plenty accurate, but perhaps with some simple design changes we can improve the situation.

The discussion of false positives is key to this new paper too: Sambuddho's paper mentions a false positive rate of 6%. That sounds like it means if you see a traffic flow at one side of the Tor network, and you have a set of 100000 flows on the other side and you're trying to find the match, then 6000 of those flows will look like a match. It's easy to see how at scale, this "base rate fallacy" problem could make the attack effectively useless.

And that high false positive rate is not at all surprising, since he is trying to capture only a summary of the flows at each side and then do the correlation using only those summaries. It would be neat (in a theoretical sense) to learn that it works, but it seems to me that there's a lot of work left here in showing that it would work in practice. It also seems likely that his definition of false positive rate and my use of it above don't line up completely: it would be great if somebody here could work on reconciling them.

For a possibly related case where a series of academic research papers misunderstood the base rate fallacy and came to bad conclusions, see Mike's critique of website fingerprinting attacks plus the follow-up paper from CCS this year confirming that he's right.

I should also emphasize that whether this attack can be performed at all has to do with how much of the Internet the adversary is able to measure or control. This diversity question is a large and important one, with lots of attention already. See more discussion here.

In summary, it's great to see more research on traffic confirmation attacks, but a) traffic confirmation attacks are not a new area so don't freak out without actually reading the papers, and b) this particular one, while kind of neat, doesn't supercede all the previous papers.

(I should put in an addendum here for the people who are wondering if everything they read on the Internet in a given week is surely all tied together: we don't have any reason to think that this attack, or one like it, is related to the recent arrests of a few dozen people around the world. So far, all indications are that those arrests are best explained by bad opsec for a few of them, and then those few pointed to the others when they were questioned.)

[Edit: be sure to read Sambuddho's comment below, too. -RD]

Syndicate content Syndicate content