Blogs

Tor Browser 3.6.4 and 4.0-alpha-1 are released

The fourth pointfix release of the 3.6 series is available from the Tor Browser Project page and also from our distribution directory.

This release features an update to OpenSSL to address the latest round of OpenSSL security issues. Tor Browser should only be vulnerable to one of these issues - the null pointer dereference. As this issue is only a DoS, we are not considering this a critical security update, but users are advised to upgrade anyway. This release also features an update to Tor to alert users of the RELAY_EARLY attack via a log message, and a fix for a hang that was happening to some users at startup/Tor network bootstrap.

Here is the complete changelog for 3.6.4:

  • Tor Browser 3.6.4 -- All Platforms
    • Update Tor to 0.2.4.23
    • Update Tor launcher to 0.2.5.6
    • Update OpenSSL to 1.0.1i
    • Backported Tor Patches:
      • Bug 11654: Properly apply the fix for malformed bug11156 log message
      • Bug 11200: Fix a hang during bootstrap introduced in the initial
        bug11200 patch.
    • Update NoScript to 2.6.8.36
      • Bug 9516: Send Tor Launcher log messages to Browser Console
    • Update Torbutton to 1.6.11.1
      • Bug 11472: Adjust about:tor font and logo positioning to avoid overlap
      • Bug 12680: Fix Torbutton about url.

In addition, we are also releasing the first alpha of the 4.0 series, available for download on the extended downloads page.

This alpha paves the way to our upcoming autoupdater by reorganizing the directory structure of the browser. This means that in-place upgrades from Tor Browser 3.6 (by extracting/copying over the old directory) will not work.

This release also features Tor 0.2.5.6, and some new defaults for NoScript to make the script permissions for a given url bar domain automatically cascade to all third parties by default (though this may be changed in the NoScript configuration).

  • Tor Browser 4.0-alpha-1 -- All Platforms
    • Ticket 10935: Include the Meek Pluggable Transport (version 0.10)
      • Two modes of Meek are provided: Meek over Google and Meek over Amazon
    • Update Firefox to 24.7.0esr
    • Update Tor to 0.2.5.6-alpha
    • Update OpenSSL to 1.0.1i
    • Update NoScript to 2.6.8.36
      • Script permissions now apply based on URL bar
    • Update HTTPS Everywhere to 5.0development.0
    • Update Torbutton to 1.6.12.0
      • Bug 12221: Remove obsolete Javascript components from the toggle era
      • Bug 10819: Bind new third party isolation pref to Torbutton security UI
      • Bug 9268: Fix some window resizing corner cases with DPI and taskbar size.
      • Bug 12680: Change Torbutton URL in about dialog.
      • Bug 11472: Adjust about:tor font and logo positioning to avoid overlap
      • Bug 9531: Workaround to avoid rare hangs during New Identity
    • Update Tor Launcher to 0.2.6.2
      • Bug 11199: Improve behavior if tor exits
      • Bug 12451: Add option to hide TBB's logo
      • Bug 11193: Change "Tor Browser Bundle" to "Tor Browser"
      • Bug 11471: Ensure text fits the initial configuration dialog
      • Bug 9516: Send Tor Launcher log messages to Browser Console
    • Bug 11641: Reorganize bundle directory structure to mimic Firefox
    • Bug 10819: Create a preference to enable/disable third party isolation
    • Backported Tor Patches:
      • Bug 11200: Fix a hang during bootstrap introduced in the initial
        bug11200 patch.
  • Tor Browser 4.0-alpha-1 -- Linux Changes
    • Bug 10178: Make it easier to set an alternate Tor control port and password
    • Bug 11102: Set Window Class to "Tor Browser" to aid in Desktop navigation
    • Bug 12249: Don't create PT debug files anymore

The list of frequently encountered known issues is also available in our bug tracker.

Tor Weekly News — August 6th, 2014

Welcome to the thirty-first issue of Tor Weekly News in 2014, the weekly newsletter that covers what is happening in the Tor community.

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 and the Tor blog.

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, 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. There 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 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 will offer the same fixes to ordinary users. Nusenu suggested 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.

Why is bad-relays a closed mailing list?

Damian Johnson and Philipp Winter have been working on improving the process of reporting bad relays. The process starts by having users report odd behaviors to the bad-relays mailing list.

Only a few trusted volunteers receive and review these reports. Nusenu started a discussion on tor-talk advocating for more transparency. Nusenu argues that an open list would “likely get more confirm/can’t confirm feedback for a given badexit candidate”, and that it would allow worried users to act faster than operators of directory authorities.

Despite being “usually on the side of transparency”, Roger Dingledine described 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. 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.”

A better future and more transparency probably lies in adaptive test systems run by multiple volunteer groups. Until they come to existence, as a small improvement, Philipp Winter wrote it was probably safe to publish why relays were disabled, through “short sentence along the lines of ‘running HTTPS MitM’ or ‘running sslstrip’”.

Monthly status reports for July 2014

Time for monthly reports from Tor project members. The July 2014 round was opened by Georg Koppen, followed by Philipp Winter, Sherief Alaa, Lunar, Nick Mathewson, Pearl Crescent, George Kadianakis, Matt Pagan, Isis Lovecruft, Griffin Boyce, Arthur Edelstein, and Karsten Loesing.

Lunar reported on behalf of the help desk and Mike Perry for the Tor Browser team.

Miscellaneous news

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 updates Tor to version 0.2.4.23, and the kernel to 3.15.7 with Gentoo’s hardened patches.

meejah has announced a new command-line application. carml is a versatile set of tools to “query and control a running Tor”. It can do things like “list and remove streams and circuits; monitor stream, circuit and address-map events; watch for any Tor event and print it (or many) out; monitor bandwidth; run any Tor control-protocol command; pipe through common Unix tools like grep, 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. meejah describes it as early-alpha and warns that it might contain “serious, anonymity-destroying bugs”. Watch out!

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, Marc Juarez on website fingerprinting defenses, Amogh Pradeep on Orbot and Orfox improvements, Zack Mullaly on the HTTPS Everywhere secure ruleset update mechanism, Israel Leiva on the GetTor revamp, Quinn Jarrell on the pluggable transport combiner, Daniel Martí on incremental updates to consensus documents, Noah Rahman on Stegotorus enhancements, and Sreenatha Bhatlapenumarthi on the Tor Weather rewrite.

The Tails team is looking for testers to solve a possible incompatibility in one of the recommended installation procedures. If you have a running Tails system, a spare USB stick and some time, please help. Don’t miss the recommended command-line options!

The Citizen Lab Summer Institute took place at the University of Toronto from July 28 to 31. The event brought together policy and technology researchers who focus on Internet censorship and measurement. A lot of great work was presented including but not limited to a proposal to measure the chilling effect, ongoing work to deploy Telex, and several projects to measure censorship in different countries. Some Tor-related work was also presented: Researchers are working on understanding how the Tor network is used for political purposes. Another project makes use of TCP/IP side channels to measure the reachability of Tor relays from within China.

The Electronic Frontier Foundation wrote two blog posts to show why Tor is important for universities and how universities can help the Tor network. The first part explains why Tor matters, gives several examples of universities already contributing to the Tor network, and outlines a few reasons for hosting new Tor nodes. The second part gives actual tips on where to start, and how to do it best.

Tor help desk roundup

Users occasionally ask if there is any way to set Tor Browser as the default browser on their system. Currently this is not possible, although it may be possible in a future Tor Browser release. In the mean time, Tails provides another way to prevent accidentally opening hyperlinks in a non-Tor browser.

Easy development tasks to get involved with

Tor Launcher is the Tor controller shipped with Tor Browser written in JavaScript. Starting with Firefox 14 the “nsILocalFile” interface has been deprecated and replaced with the “nsIFile” interface. What we should do is replace all instances of “nsILocalFile” with “nsIFile” and see if anything else needs fixing to make Tor Launcher still work as expected. If you know a little bit about Firefox extensions and want to give this a try, clone the repository, make the necessary changes, run “make package”, and tell us whether something broke in interesting ways.


This issue of Tor Weekly News has been assembled by Lunar, harmony, Matt Pagan, Philipp Winter, David Fifield, Karsten Loesing, and Roger Dingledine.

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 security advisory: "relay early" traffic confirmation attack

This advisory was posted on the tor-announce mailing list.

SUMMARY:

On July 4 2014 we found a group of relays that we assume were trying to deanonymize users. They appear to have been targeting people who operate or access Tor hidden services. The attack involved modifying Tor protocol headers to do traffic confirmation attacks.

The attacking relays joined the network on January 30 2014, and we removed them from the network on July 4. While we don't know when they started doing the attack, users who operated or accessed hidden services from early February through July 4 should assume they were affected.

Unfortunately, it's still unclear what "affected" includes. We know the attack looked for users who fetched hidden service descriptors, but the attackers likely were not able to see any application-level traffic (e.g. what pages were loaded or even whether users visited the hidden service they looked up). The attack probably also tried to learn who published hidden service descriptors, which would allow the attackers to learn the location of that hidden service. In theory the attack could also be used to link users to their destinations on normal Tor circuits too, but we found no evidence that the attackers operated any exit relays, making this attack less likely. And finally, we don't know how much data the attackers kept, and due to the way the attack was deployed (more details below), their protocol header modifications might have aided other attackers in deanonymizing users too.

Relays should upgrade to a recent Tor release (0.2.4.23 or 0.2.5.6-alpha), to close the particular protocol vulnerability the attackers used — but remember that preventing traffic confirmation in general remains an open research problem. Clients that upgrade (once new Tor Browser releases are ready) will take another step towards limiting the number of entry guards that are in a position to see their traffic, thus reducing the damage from future attacks like this one. Hidden service operators should consider changing the location of their hidden service.

THE TECHNICAL DETAILS:

We believe they used a combination of two classes of attacks: a traffic confirmation attack and a Sybil attack.

A traffic confirmation attack is possible when the attacker controls or observes the relays on both ends of a Tor circuit and then compares traffic timing, volume, or other characteristics to conclude that the two relays are indeed on the same circuit. If the first relay in the circuit (called the "entry guard") knows the IP address of the user, and the last relay in the circuit knows the resource or destination she is accessing, then together they can deanonymize her. You can read more about traffic confirmation attacks, including pointers to many research papers, at this blog post from 2009:
https://blog.torproject.org/blog/one-cell-enough

The particular confirmation attack they used was an active attack where the relay on one end injects a signal into the Tor protocol headers, and then the relay on the other end reads the signal. These attacking relays were stable enough to get the HSDir ("suitable for hidden service directory") and Guard ("suitable for being an entry guard") consensus flags. Then they injected the signal whenever they were used as a hidden service directory, and looked for an injected signal whenever they were used as an entry guard.

The way they injected the signal was by sending sequences of "relay" vs "relay early" commands down the circuit, to encode the message they want to send. For background, Tor has two types of cells: link cells, which are intended for the adjacent relay in the circuit, and relay cells, which are passed to the other end of the circuit. In 2008 we added a new kind of relay cell, called a "relay early" cell, which is used to prevent people from building very long paths in the Tor network. (Very long paths can be used to induce congestion and aid in breaking anonymity). But the fix for infinite-length paths introduced a problem with accessing hidden services, and one of the side effects of our fix for bug 1038 was that while we limit the number of outbound (away from the client) "relay early" cells on a circuit, we don't limit the number of inbound (towards the client) relay early cells.

So in summary, when Tor clients contacted an attacking relay in its role as a Hidden Service Directory to publish or retrieve a hidden service descriptor (steps 2 and 3 on the hidden service protocol diagrams), that relay would send the hidden service name (encoded as a pattern of relay and relay-early cells) back down the circuit. Other attacking relays, when they get chosen for the first hop of a circuit, would look for inbound relay-early cells (since nobody else sends them) and would thus learn which clients requested information about a hidden service.

There are three important points about this attack:

A) 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). The encoded signal is encrypted as it is sent over the TLS channel between relays. However, this signal would be easy to read and interpret by anybody who runs a relay and receives the encoded traffic. And we might also worry about a global adversary (e.g. a large intelligence agency) that records Internet traffic at the entry guards and then tries to break Tor's link encryption. The way this attack was performed weakens Tor's anonymity against these other potential attackers too — either while it was happening or after the fact if they have traffic logs. So if the attack was a research project (i.e. not intentionally malicious), it was deployed in an irresponsible way because it puts users at risk indefinitely into the future.

(This concern is in addition to the general issue that it's probably unwise from a legal perspective for researchers to attack real users by modifying their traffic on one end and wiretapping it on the other. Tools like Shadow are great for testing Tor research ideas out in the lab.)

B) This protocol header signal injection attack is actually pretty neat from a research perspective, in that it's a bit different from previous tagging attacks which targeted the application-level payload. Previous tagging attacks modified the payload at the entry guard, and then looked for a modified payload at the exit relay (which can see the decrypted payload). Those attacks don't work in the other direction (from the exit relay back towards the client), because the payload is still encrypted at the entry guard. But because this new approach modifies ("tags") the cell headers rather than the payload, every relay in the path can see the tag.

C) We should remind readers 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. So the good news is traffic confirmation attacks aren't new or surprising, but the bad news is that they still work. See https://blog.torproject.org/blog/one-cell-enough for more discussion.

Then the second class of attack they used, in conjunction with their traffic confirmation attack, was a standard Sybil attack — they signed up around 115 fast non-exit relays, all running on 50.7.0.0/16 or 204.45.0.0/16. Together these relays summed to about 6.4% of the Guard capacity in the network. Then, in part because of our current guard rotation parameters, these relays became entry guards for a significant chunk of users over their five months of operation.

We actually noticed these relays when they joined the network, since the DocTor scanner reported them. We considered the set of new relays at the time, and made a decision that it wasn't that large a fraction of the network. It's clear there's room for improvement in terms of how to let the Tor network grow while also ensuring we maintain social connections with the operators of all large groups of relays. (In general having a widely diverse set of relay locations and relay operators, yet not allowing any bad relays in, seems like a hard problem; on the other hand our detection scripts did notice them in this case, so there's hope for a better solution here.)

In response, we've taken the following short-term steps:

1) Removed the attacking relays from the network.

2) Put out a software update for relays to prevent "relay early" cells from being used this way.

3) Put out a software update that will (once enough clients have upgraded) let us tell clients to move to using one entry guard rather than three, to reduce exposure to relays over time.

4) Clients can tell whether they've received a relay or relay-cell. For expert users, the new Tor version warns you in your logs if a relay on your path injects any relay-early cells: look for the phrase "Received an inbound RELAY_EARLY cell".

The following longer-term research areas remain:

5) Further growing the Tor network and diversity of relay operators, which will reduce the impact from an adversary of a given size.

6) Exploring better mechanisms, e.g. social connections, to limit the impact from a malicious set of relays. We've also formed a group to pay more attention to suspicious relays in the network:
https://blog.torproject.org/blog/how-report-bad-relays

7) Further reducing exposure to guards over time, perhaps by extending the guard rotation lifetime:
https://blog.torproject.org/blog/lifecycle-of-a-new-relay
https://blog.torproject.org/blog/improving-tors-anonymity-changing-guard...

8) Better understanding statistical traffic correlation attacks and whether padding or other approaches can mitigate them.

9) Improving the hidden service design, including making it harder for relays serving as hidden service directory points to learn what hidden service address they're handling:
https://blog.torproject.org/blog/hidden-services-need-some-love

OPEN QUESTIONS:

Q1) Was this the Black Hat 2014 talk that got canceled recently?
Q2) Did we find all the malicious relays?
Q3) Did the malicious relays inject the signal at any points besides the HSDir position?
Q4) What data did the attackers keep, and are they going to destroy it? How have they protected the data (if any) while storing it?

Great questions. We spent several months trying to extract information from the researchers who were going to give the Black Hat talk, and eventually we did get some hints from them about how "relay early" cells could be used for traffic confirmation attacks, which is how we started looking for the attacks in the wild. They haven't answered our emails lately, so we don't know for sure, but it seems likely that the answer to Q1 is "yes". In fact, we hope they *were* the ones doing the attacks, since otherwise it means somebody else was. We don't yet know the answers to Q2, Q3, or Q4.

Tor Weekly News — July 30th, 2014

Welcome to the thirtieth issue of Tor Weekly News in 2014, the weekly newsletter that covers what is happening in the Tor community.

Tor Browser 3.6.3 is out

A new pointfix release for the 3.6 series of the Tor Browser is out. Most components have been updated and a couple of small issues fixed. Details are available in the release announcement.

The release fixes import security updates from Firefox. Be sure to upgrade! Users of the experimental meek bundles have not been forgotten.

New Tor stable and alpha releases

Two new releases of Tor are out. The new 0.2.5.6-alpha release “brings us a big step closer to slowing down the risk from guard rotation, and fixes a variety of other issues to get us closer to a release candidate”.

Once directory authorities have upgraded, they will “assign the Guard flag to the fastest 25% of the network”. Some experiments showed that “for the current network, this results in about 1100 guards, down from 2500.”

The complementary change to moving the number of entry guards down to one is the introduction of two new consensus parameters. NumEntryGuards and NumDirectoryGuards will respectively set the number of entry guards and directory guards that clients will use. The default for NumEntryGuards is currently three, but this will allow a reversible switch to one in a near future.

Several important fixes have been backported to the stable branch in the 0.2.4.23 release. Source packages are available at the regular location . Binary packages have already landed in Debian (unstable, experimental) and the rest should follow shortly.

Security issue in Tails 1.1 and earlier

Several vulnerabilities have been discovered in I2P which is shipped in Tails 1.1 and earlier. I2P is an anonymous overlay network with many similarities to Tor. There was quite some confusion around the disclosure process of this vulnerability. Readers are encouraged to read what the Tails team has written about it.

Starting I2P in Tails normally requires a click on the relevant menu entry. Once started, the security issues can lead to the deanonymization of a Tails user who visits a malicious web page. As a matter of precaution, the Tails team recommends removing the “i2p” package each time Tails is started.

I2P has fixed the issue in version 0.9.14. It is likely to be included in the next Tails release, but the team is also discussing implementing more in-depth protections that would be required in order to keep I2P in Tails.

Reporting bad relays

“Bad” relays are malicious, misconfigured, or otherwise broken Tor relays. As anyone is free to volunteer bandwidth and processing power to spin up a new relay, users can encounter such bad relays once in a while. Getting them out of everyone’s circuits is thus important.

Damian Johnson and Philipp Winter have been working on improving and documenting the process of reporting bad relays. “While we do regularly scan the network for bad relays, we are also dependent on the wider community to help us spot relays which don’t act as they should” wrote Philipp.

When observing unusual behaviors, one way to learn about the current exit relay before reporting it is to use the Check service. This method can be inaccurate and tends to be a little bit cumbersome. The good news is that Arthur Edelstein is busy integrating more feedback on Tor circuits being used directly into the Tor Browser.

Miscellaneous news

The Tor Project, Inc. has completed its standard financial audit for the year 2013. IRS Form 990, Massachusetts Form PC, and the Financial Statements are now available for anyone to review. Andrew Lewman explained: “we publish all of our related tax documents because we believe in transparency. All US non-profit organizations are required by law to make their tax filings available to the public on request by US citizens. We want to make them available for all.”

CJ announced the release of orWall (previously named Torrific), a new Android application that “will force applications selected through Orbot while preventing unchecked applications to have network access”.

The Thali project aims to use hidden services to host web content. As part of the effort, they have written a cross-platform Java library. “The code handles running the binary, configuring it, managing it, starting a hidden service, etc.” wrote Yaron Goland.

Gareth Owen released a Java-based Tor research framework . The goal is to enable researchers to try things out without having to deal with the full tor source. “At present, it is a fully functional client with a number of examples for hidden services and SOCKS. You can build arbitrary circuits, build streams, send junk cells, etc.” wrote Gareth.

Version 0.2.3 of BridgeDB has been deployed. Among other changes, owners of riseup.net email accounts can now request bridges through email.

The first candidate for Orbot 14.0.5 has been released. “This update includes improved management of the background processes, the ability to easily change the local SOCKS port (to avoid conflicts on some Samsung Galaxy and Note devices), and the fancy new notification dialog, showing your current exit IPs and country” wrote Nathan Freitas.

While working on guard nodes, George Kadianakis realized that “the data structures and methods of the guard nodes code are not very robust”. Nick Mathewson and George have been busy trying to come up with better abstractions. More brains working on the problem would be welcome!

Mike Perry posted “a summary of the primitives that Marc Juarez aims to implement for his Google Summer of Code project on prototyping defenses for Website Traffic Fingerprinting and follow-on research”. Be sure to have a look if you want to help prevent website fingerprint attacks.

A new draft proposal “for making all relays also be directory servers (by default)” has been submitted by Matthew Finkel. Among the motivations, Matthew wrote: “In a network where every router is a
directory server, the profiling and partitioning attack vector is reduced to the guard (for clients who use them), which is already in a privileged position for this. In addition, with the increased set size, relay descriptors and documents are more readily available and it diversifies the providers.” This change might make the transition to a single guard safer. Feedback welcome!

Noah Rahman reported on the progress of the Stegotorus Google Summer of Code project.

Tor help desk roundup

A number of Iranian Tor users have reported that Tor no longer works out of the box in Iran, and the Tor Metrics portal shows a corresponding drop in the number of directly-connecting users there. Collin Anderson investigated the situation and reported that the Telecommunication Company of Iran had begun blocking the Tor network by blacklisting connections to Tor’s directory authorities. Tor users can circumvent this block by getting bridges from BridgeDB and entering the bridge addresses they receive into their Tor Browser.


This issue of Tor Weekly News has been assembled by Lunar, Matt Pagan, harmony, and Philipp Winter.

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!

How to report bad relays

We now have a wiki page which explains how bad relays should be reported to the Tor Project. A bad relay can be malicious, misconfigured, or otherwise broken. Once such a relay is reported, a subset of vigilant Tor developers (currently Roger, Peter, Damian, Karsten, and I) first tries to reproduce the issue. If it's reproducible, we attempt to get in touch with the relay operator and work on the issue together. However, if the relay has no contact information or we cannot reach the operator, we will resort to assigning flags (such as BadExit) to the reported relay which instructs clients to no longer use the relay in the future. In severe cases, we are also able to remove the relay descriptor from the network consensus which effectively makes the relay disappear. To get an idea of what bad behavior was documented in the past, have a look at this (no longer maintained) wiki page or these research papers.

We regularly scan the network for bad relays using exitmap but there are several other great tools such as Snakes on a Tor, torscanner, tortunnel, and DetecTor. We are also dependent on the wider community to help us spot relays which don't act as they should. So if you think that you stumbled upon a bad relay while using Tor, please report it to us by sending an email to bad-relays@lists.torproject.org. To find out which relay is currently being used as your exit relay, please visit our Check service. Just tell us the relay's IP address (Check tells you what your IP address appears to be) and the behavior you observed. Then, we can begin to investigate!

Transparency, Openness, and our 2013 Financials

2013 was a great year for Tor. The increasing awareness of the lack of privacy online, increasing Internet censorship around the world, and general interest in encryption has helped continue to keep us in the public mind. As a result, our supporters have increased our funding to keep us on the leading edge of our field, this of course, means you. We're happy to have more developers, advocates, and support volunteers. We're encouraged as the general public talks about Tor to their friends and neighbors. Join us as we continue to fight for your privacy and freedom on the Internet!

After completing the standard audit, our 2013 state and federal tax filings are available. We publish all of our related tax documents because we believe in transparency. All US non-profit organizations are required by law to make their tax filings available to the public on request by US citizens. We want to make them available for all.

Part of our transparency is simply publishing the tax documents for your review. The other part is publishing what we're working on in detail. We hope you'll join us in furthering our mission (a) to develop, improve and distribute free, publicly available tools and programs that promote free speech, free expression, civic engagement and privacy rights online; (b) to conduct scientific research regarding, and to promote the use of and knowledge about, such tools, programs and related issues around the world; (c) to educate the general public around the world about privacy rights and anonymity issues connected to Internet use.

All of this means you can look through our source code, including our design documents, and all open tasks, enhancements, and bugs available on our tracking system. Our research reports are available as well. From a technical perspective, all of this free software, documentation, and code allows you and others to assess the safety and trustworthiness of our research and development. On another level, we have a 10 year track record of doing high quality work, saying what we're going to do, and doing what we said.

Internet privacy and anonymity is more important and rare than ever. Please help keep us going through getting involved, donations, or advocating for a free Internet with privacy, anonymity, and keeping control of your identity.

Tor Browser 3.6.3 is released

The third pointfix release of the 3.6 series is available from the Tor Browser Project page and also from our distribution directory.

This release features important security updates to Firefox.

Here is the complete changelog:

  • All Platforms
    • Update Firefox to 24.7.0esr
    • Update obfsproxy to 0.2.12
    • Update FTE to 0.2.17
    • Update NoScript to 2.6.8.33
    • Update HTTPS Everywhere to 3.5.3
    • Bug 12673: Update FTE bridges
    • Update Torbutton to 1.6.11.0
      • Bug 12221: Remove obsolete Javascript components from the toggle era
      • Bug 10819: Bind new third party isolation pref to Torbutton security UI
      • Bug 9268: Fix some window resizing corner cases with DPI and taskbar size.
  • Linux:
    • Bug 11102: Set Window Class to "Tor Browser" to aid in Desktop navigation
    • Bug 12249: Don't create PT debug files anymore

The list of frequently encountered known issues is also available in our bug tracker.

Tor Weekly News — July 23rd, 2014

Welcome to the twenty-ninth issue of Tor Weekly News in 2014, the weekly newsletter that covers what is happening in the Tor community.

Tails 1.1 is out!

Tails, the Debian-based live system that protects its users’ communications by ensuring they are all sent through the Tor network, has been updated. This new 1.1 release reminds Tails users of the distribution’s roots in Debian: Tails is now based on the current stable version of Debian, dubbed “Wheezy”.

This means that almost all software components have been updated. One noticeable example is the desktop environment. The user experience of the GNOME 3 in fallback mode should be similar to previous Tails versions, but things will look a bit differently than they used to.

One of the most keenly-awaited features of this new version is the support for UEFI firmware. Mac users now have only to press the Alt key while booting their computer to start Tails from a DVD or USB stick. The same goes for owners of computers displaying “Windows 8” stickers. And, talking of Windows 8, the camouflage mode has been updated to look more like it, instead of the now discontinued XP.

This new release also contains security fixes, and minor tweaks over the previous versions.

Because of the newly-introduced support for UEFI and the amount of upgraded software, incremental upgrades will not be offered for Tails 1.1. A full upgrade is needed through the Tails Installer. The safest method for upgrading Tails sticks is to go through a freshly burned DVD. Be sure to have a look at the list of known issues to learn about other oddities that might happen in the process.

PETS 2014

The fourteenth Privacy Enhancing Technologies Symposium was held in Amsterdam, Netherlands, July 16-18, 2014. A wide range of research in privacy enhancing technologies was presented, with many of relevance to Tor. Keynotes were given by Martin Ortlieb, Senior User Experience Researcher in Privacy at Google, and William Binney, a former NSA employee.

Some papers focusing on Tor include:

Also announced at PETS was the 2014 PET Award for Outstanding Research in Privacy Enhancing Technologies, for A Scanner Darkly: Protecting User Privacy From Perceptual Applications by Suman Jana, Arvind Narayanan†, and Vitaly Shmatikov. The winner of the best student paper at PETS was I Know Why You Went to the Clinic: Risks and Realization of HTTPS Traffic Analysis by Brad Miller, Ling Huang, A. D. Joseph and J. D. Tygar .

Prior to PETS, there was a Tor meet-up which Moritz Bartl reported as a great success. Hopefully there will also be such an event at the 2015 PETS, to be held in Philadelphia, US, in the week of June 29, 2015.

Miscellaneous news

txtorcon, the Tor control protocol implementation for the Twisted framework, received a new minor release. Version 0.10.1 fixes “a couple bugs introduced along with the endpoints feature in 0.10.0”.

Roger Dingledine posted an official reaction to the cancellation of a proposed talk at the upcoming Blackhat2014 conference dealing with possible deanonymization attacks on Tor users and hidden services.

Tor ships with a sample webpage that can be used by exit node operators to identify their system as such to anyone wishing to identify the source of Tor traffic. Operators most often copy and adapt this template to the local situation. Mick Morgan discovered than his version was out of sync and contained broken links. “If other operators are similarly using a page based on the old template, they may wish to update”, Mick advised.

Michael Rogers, one of the developers of Briar, announced a new mailing list for discussing peer-to-peer-based communication systems based on Tor hidden services. As Briar and other systems might be “running into similar issues”, a shared place to discuss them seemed worthwhile.

Karsten Loesing and Philipp Winter are looking for front-end web developers: “We are looking for somebody to fork and extend one of the two main Tor network status websites Atlas or Globe” writes Karsten. Both websites currently need love and new maintainers. Please reach out if you want to help!

The database which holds Tor bridges, usually called BridgeDB, is able to give out bridge addresses through email. This feature was recently extended to make the email autoresponder support more bridge types, which required introducing new keywords that must be used in the initial request. Matthew Finkel is looking for feedback on the current set of commands and how they could be improved.

Lunar wrote a detailed report on his week at the Libre Software Meeting in Montpellier, France. The report covers the booth jointly held with Nos Oignons, his talk in the security track, and several contacts made with other free software projects.

Here’s another round of reports from Google Summer of Code students: the mid-term: Amogh Pradeep on Orbot and Orfox improvements, Israel Leiva on the GetTor revamp, Quinn Jarrell on the pluggable transport combiner, Juha Nurmi on the ahmia.fi project, Marc Juarez on website fingerprinting defenses, and Daniel Martí on incremental updates to consensus documents.

Tim Retout announced that apt-transport-tor 0.2.1 has entered Debian unstable. This package enables APT to download Debian packages through Tor.

Atlas can now also be used to search for Tor bridges. In the past, Atlas was only able to search for relays. This was made possible thanks to a patch developed by Dmitry Eremin-Solenikov.

Thanks to Tim Semeijn and Tobias Bauer for setting up new mirrors of the Tor Project’s website and its software.

Tor help desk roundup

Some Linux users have experienced missing dependency errors when trying to install Tor Browser from their operating system’s software repositories. Tor Browser should only be installed from the Tor Project’s website, and never from a software repository. In other words, using apt-get or yum to install Tor Browser is discouraged. Downloading and verifying Tor Browser from the Tor Project website allows users to keep up with important security updates as they are released.

News from Tor StackExchange

user3224 wants to log in to its Google, Microsoft etc. accounts and wonders if they will know the real name and other personal information. Roya and mirimir explained that if someone logs into an already personalized account Tor can’t anonymize this user. Instead it might be wise to use Tor to register a pseudonym and also use an anonymous operating system like Tails or Whonix.

escapologybb has set up a Raspberry Pi. It serves as SOCKS proxy for the internal network. While everyone can use it, escapologybb asks what the security implications are and if this lowers the overall anonymity. If you know a good answer please share your knowledge with the users of Tor StackExchange.


This issue of Tor Weekly News has been assembled by Lunar, Steven Murdoch, harmony, Philipp Winter, Matt Pagan, qbi, 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!

Syndicate content Syndicate content