Support all your favorite nonprofits with a single donation.

Donate safely, anonymously & monthly, in any amount. It's a smarter way to give online. Learn more
The Tor Project
Dedham, MA
givvers: jason, emerssso + 4 others

Tor is free software and an open network that helps you defend against a form of network surveillance that threatens personal freedom and privacy, confidential business activities and relationships, and state security known as traffic analysis.

The Tor Project is a 501(c)3 organization.

Latest News

Sep 12, 2014

Tor 0.2.5.7-rc fixes several regressions from earlier in the 0.2.5.x release series, and some long-standing bugs related to ORPort reachability testing and failure to send CREATE cells. It is the first release candidate for the Tor 0.2.5.x series.

The tarball and signature file are currently available from
https://www.torproject.org/dist/
and packages and bundles will be available soon.

Changes in version 0.2.5.7-rc - 2014-09-11

  • Major bugfixes (client, startup):
    • Start making circuits as soon as DisabledNetwork is turned off.
      When Tor started with DisabledNetwork set, it would correctly
      conclude that it shouldn't build circuits, but it would mistakenly
      cache this conclusion, and continue believing it even when
      DisableNetwork is set to 0. Fixes the bug introduced by the fix
      for bug 11200; bugfix on 0.2.5.4-alpha.

    • Resume expanding abbreviations for command-line options. The fix
      for bug 4647 accidentally removed our hack from bug 586 that
      rewrote HashedControlPassword to __HashedControlSessionPassword
      when it appears on the commandline (which allowed the user to set
      her own HashedControlPassword in the torrc file while the
      controller generates a fresh session password for each run). Fixes
      bug 12948; bugfix on 0.2.5.1-alpha.

    • Warn about attempts to run hidden services and relays in the same
      process: that's probably not a good idea. Closes ticket 12908.
  • Major bugfixes (relay):
    • Avoid queuing or sending destroy cells for circuit ID zero when we
      fail to send a CREATE cell. Fixes bug 12848; bugfix on 0.0.8pre1.
      Found and fixed by "cypherpunks".

    • Fix ORPort reachability detection on relays running behind a
      proxy, by correctly updating the "local" mark on the controlling
      channel when changing the address of an or_connection_t after the
      handshake. Fixes bug 12160; bugfix on 0.2.4.4-alpha.
  • Minor features (bridge):
    • Add an ExtORPortCookieAuthFileGroupReadable option to make the
      cookie file for the ExtORPort g+r by default.
  • Minor features (geoip):
    • Update geoip and geoip6 to the August 7 2014 Maxmind GeoLite2
      Country database.
  • Minor bugfixes (logging):
    • Reduce the log severity of the "Pluggable transport proxy does not
      provide any needed transports and will not be launched." message,
      since Tor Browser includes several ClientTransportPlugin lines in
      its torrc-defaults file, leading every Tor Browser user who looks
      at her logs to see these notices and wonder if they're dangerous.
      Resolves bug 13124; bugfix on 0.2.5.3-alpha.

    • Downgrade "Unexpected onionskin length after decryption" warning
      to a protocol-warn, since there's nothing relay operators can do
      about a client that sends them a malformed create cell. Resolves
      bug 12996; bugfix on 0.0.6rc1.

    • Log more specific warnings when we get an ESTABLISH_RENDEZVOUS
      cell on a cannibalized or non-OR circuit. Resolves ticket 12997.

    • When logging information about an EXTEND2 or EXTENDED2 cell, log
      their names correctly. Fixes part of bug 12700; bugfix
      on 0.2.4.8-alpha.

    • When logging information about a relay cell whose command we don't
      recognize, log its command as an integer. Fixes part of bug 12700;
      bugfix on 0.2.1.10-alpha.

    • Escape all strings from the directory connection before logging
      them. Fixes bug 13071; bugfix on 0.1.1.15. Patch from "teor".
  • Minor bugfixes (controller):
    • Restore the functionality of CookieAuthFileGroupReadable. Fixes
      bug 12864; bugfix on 0.2.5.1-alpha.

    • Actually send TRANSPORT_LAUNCHED and HS_DESC events to
      controllers. Fixes bug 13085; bugfix on 0.2.5.1-alpha. Patch
      by "teor".
  • Minor bugfixes (compilation):
    • Fix compilation of test.h with MSVC. Patch from Gisle Vanem;
      bugfix on 0.2.5.5-alpha.

    • Make the nmake make files work again. Fixes bug 13081. Bugfix on
      0.2.5.1-alpha. Patch from "NewEraCracker".

    • In routerlist_assert_ok(), don't take the address of a
      routerinfo's cache_info member unless that routerinfo is non-NULL.
      Fixes bug 13096; bugfix on 0.1.1.9-alpha. Patch by "teor".

    • Fix a large number of false positive warnings from the clang
      analyzer static analysis tool. This should make real warnings
      easier for clang analyzer to find. Patch from "teor". Closes
      ticket 13036.
  • Distribution (systemd):
    • Verify configuration file via ExecStartPre in the systemd unit
      file. Patch from intrigeri; resolves ticket 12730.

    • Explicitly disable RunAsDaemon in the systemd unit file. Our
      current systemd unit uses "Type = simple", so systemd does not
      expect tor to fork. If the user has "RunAsDaemon 1" in their
      torrc, then things won't work as expected. This is e.g. the case
      on Debian (and derivatives), since there we pass "--defaults-torrc
      /usr/share/tor/tor-service-defaults-torrc" (that contains
      "RunAsDaemon 1") by default. Patch by intrigeri; resolves
      ticket 12731.
  • Documentation:
    • Adjust the URLs in the README to refer to the new locations of
      several documents on the website. Fixes bug 12830. Patch from
      Matt Pagan.

    • Document 'reject6' and 'accept6' ExitPolicy entries. Resolves
      ticket 12878.

Sep 10, 2014

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

More monthly status reports for August 2014

The wave of regular monthly reports from Tor project members for the month of August continued, with reports from Yawning AngelGeorge KadianakisIsis LovecruftColin C., and Griffin Boyce.

Arturo Filastò reported on behalf of the OONI team.

Miscellaneous news

Nathan Freitas announced the release of Orbot 14.0.8, containing “some fixes for people who like to fiddle with transproxy/iptables settings, which can lead to the device getting into a bad network state”, as well as for “a common freak crash that was occuring on app exit in some cases.” See Nathan’s message for a full changelog and download links.

Mike Perry asked for comments on his proposal to drop Tor Browser support for Mac OS X 10.6, which is no longer receiving security updates from Apple. This means that the Tor Browser team would only have to distribute standard-sized 64-bit builds for Mac OS X rather than the oversized 32+64-bit set. Users who are unable to upgrade their operating system would still be able to use Tails for their Tor browsing needs.

Hartmut Haase reported that Tor Browser occasionally fails to open, despite a successful connection being made to the Tor network; several other users confirmed that they are also experiencing this problem. Georg Koppen suggested that the issue is the one covered by bug ticket #10804: “Solving this is high on the priority list, but alas not as high as getting everything ready for the switch to ESR31.”

Thanks to Peter Ludikovsky and goll for running mirrors of the Tor Project website and software archive!

Andrew Lewman published the results of a test he ran to answer the question “Why not just use CloudFlare for mirrors of the Tor Project website?”: “The results are that using CloudFlare doesn’t offload the binaries, which are what make up the bulk of traffic on the mirror […] I’ve started to look at CDN providers to see if there are affordable services which can offload the entire site itself.”

As part of an ongoing effort to rescue the Tor blog from rot and ruin caused by broken Drupal code, ultrasandwich set up an unofficial preview of a possible blog based on the Jekyll static site generator. If you want to contribute to the revamp of the Tor Project website, including the blog, the www-team mailing list awaits your comments and ideas!

Tor help desk roundup

Users want to know if their personal information is safe when they use Tor Browser. Personal accounts are no less secure using Tor Browser than they are using the web without Tor: the problem of authenticating websites and preventing eavesdropping has been addressed outside of the Tor context through HTTPS. That’s why the Tor Browser ships with the HTTPS-Everywhere browser extension — for every website you visit, HTTPS-Everywhere checks whether or not that website is known to have an HTTPS version, and if so it connects to the site using HTTPS instead of HTTP. Tor + HTTPS provides full end-to-end encryption when visiting any site that offers its content via HTTPS. Using HTTPS with Tor helps keep users’ web accounts secure.

Easy development tasks to get involved with

If a single human or organization runs more than one relay, they should configure all their relays to be in the same “family”, the goal being to prevent clients from using more than one of these relays in the same circuit. However, the config option used for this, MyFamily, only accepts relay fingerprints that are preceeded by $, unlike most other config options. It would be great if this option accepted fingerprints preceeded by $, as well as without it. Nick Mathewson says this ticket would be pretty easy, so why not give it a try? It does sound like some fun C hacking. Be sure to post your patch to the ticket.

Back in the day, the tor daemon, which is the core of the Tor network, compiled and ran on Windows 98. But that’s history, and aren’t we all glad? Somebody should identify and drop support code for all Windows versions prior to Windows XP. Nick says “this is mainly going to be a matter of identifying cases where we use LoadLibrary and GetProcAddress to find always-present-functions in always-present DLLs.” If the previous sentence made any sense to you, maybe you’re a good person to help with this! Be sure to comment on the ticket if you have a branch to review.


This issue of Tor Weekly News has been assembled by harmony, Matt Pagan, Karsten Loesing, 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!

Sep 08, 2014

The Google Summer of Code (GSoC) was an excellent opportunity to improve on the Ahmia search engine. With Google's stipend and friendly mentoring from The Tor Project, I was able to concentrate on development of my search engine project. Thank you all!

GSoC 2014 is over, but I am sticking around to continue developing and maintaining Ahmia.

Here is the current status of ahmia after GSoC development:

Introduction

Ahmia is open-source search engine software for Tor hidden service websites. You can test the running search engine at ahmia.fi.

Building a search engine for anonymous web sites running inside the Tor network is an interesting problem. Tor enables web servers to hide their location and Tor users can connect to these authenticated hidden services while the server and the user both stay anonymous. However, finding web content is hard without a good search engine and therefore a search engine is needed for the Tor network.

Web search engines are needed to navigate and search the web. There were no search engines for searching hidden service web content, so I decided to build a search engine specially for Tor. I registered ahmia.fi and started development on it as a side project in 2010.

This development involved programming and testing web crawlers, thinking of ways to find hidden service addresses (since the protocol does not allow enumeration), learning about the Tor community, and implementing a filtering policy. Moreover, I implemented an API that empowers other Tor services that publish content to integrate with Ahmia.

As a result, Ahmia is a working search engine that indexes, searches and catalogs content published on Tor Hidden Services. Furthermore, it is an environment to share meaningful statistics, insights and news about the Tor network itself.

Interesting Summer of Code

One of my best memories from the summer is the Tor Project's Summer 2014 Developers meeting that was hosted by Mozilla in Paris, France. I have always admired the people who are working on the Tor Project.

I also loved the coding itself. Finally I had time to improve the Ahmia search engine and its many features. I did a lot of work and liked it.

Some journalist were very interested in my work: Carola Frediani asked if I could analyze the content of hidden services. I coded a script that fetches every front page's HTML, I gathered all the keywords, headers and description texts and made a simple word cloud visualization.

Hidden website content visualization.

It is a simple way to glance what is published on the hidden websites.

Carola found this data useful and used it in her presentation at www.sotn.it on June 11th.

Technical design of ahmia

The Ahmia web service is written using the Django web framework. As a result, the server-side language is Python. On the client-side, most of the pages are plain HTML. There are some pages that require JavaScript, but the search itself works without client-side JavaScript.

The components of Ahmia are:

  • Django front-end site
  • PostgreSQL database for the site
  • Custom scripts to download data about hidden services
  • Django-Haystack connection to Solr database
  • Apache Solr for the crawled data
  • OnionBot crawler that gathers data to Solr database

Technical architecture.

See installation and developing tutorial

Search

The full-text search is implemented using Django-Haystack. The search is using crawled website data that is saved to Apache Solr.

OnionDir

OnionDir is a list of known online hidden service addresses. A separate script gathers this list and fetches information fields from the HTML (title, keywords, description etc.). Furthermore, users can freely edit these fields.

We've also started a convention where hidden service admins can add a file to their website, called description.json, to offer an official description of their site in Ahmia.

As a result, this information is shown in the OnionDir page and over 80 domains are already using this method.

Statistics

We are gathering statistics from hidden services. As a result, we can represent and share meaningful data about hidden services and visualize it.

We are gathering three types of popularity data:

  1. Tor2web nodes share their visiting statistics to Ahmia
  2. Number of public WWW backlinks to hidden services
  3. Number of clicks in the search results

The click counter tells the total number of clicks on a search result in ahmia.fi

Filtering

We have decided to filter any sites related to child porn from our search results. Ahmia is removing everything related to these websites. These websites may not be actual child porn sites. They are rather sites where users can post content (forums, file and image uploads etc.) and as the result there have been, momentarily at least, some suspicious content that has not been moderated in a reasonable period of time. Ahmia.fi does not have the time to monitor these sites carefully and we are banning sites from our public index if we see any evidence of child abuse. Of course, the ban is removed if the site itself contacts us and we review the website to be OK.

In practice, Ahmia calculates the MD5 sums of the banned domains for use as a filtering policy. Moreover, we are sharing this list and Tor2web nodes can use the list to filter out pages.

At the moment, there seems to be 1228 hidden website domains online and 7 of them has been filtered because they are possibly sharing child porn content.

OnionBot

OnionBot is a crawler for hidden service websites based on the Scrapy framework. It crawls the Tor network and passes data to the search database. OnionBot requires the Tor software (using Tor2web mode) and Polipo. The results are saved to Apache Solr.

Apache Solr

Apache Solr is a popular, open source enterprise search platform. Its major features include powerful full-text search, hit highlighting, faceted search, and near real-time indexing.

The schema.xml file contains all of the details about which fields your documents can contain, and how those fields should be dealt with when adding documents to the index, or when querying those fields.

Security measures for privacy

In the software

  • We do not log any IP addresses, see Apache configuration
  • We are gathering real-time clicks, however, this data is not shown accurately

In the host ahmia.fi

  • Backend servers are run separately and they do not have any knowledge about the end-users
  • All servers are hosted in countries with strong privacy laws. For example, Finland and the Netherlands
  • Communication between servers is encrypted
  • Only a few trustworthy people know the locations of the back-end servers and are able to access them

Future work

GSoC 2014 was fun and productive!

There is a lot more to do. However, I do not have time to do everything myself. Of course, I am coding when I have time and maintaining the search engine.

In addition, I am going to write a scientific article about the implementation.

Is there anyone who would be interested in developing Ahmia.fi?

Is anyone familiar with Solr and would know how to tweak it for full text search?

Furthermore, any kind of help would be most welcome. There are always Linux admin duties, HTML/CSS design, bug fixing, Django development, etc...

For further information, please don't hesitate to contact me by e-mail: juha.nurmi@ahmia.fi

Sep 03, 2014

Tor Browser 3.6.5

The fifth 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.

This release also features improvements to the canvas image extraction permissions prompt, and will now log offending script urls to the browser console. It also restores the missing RELRO hardening option to the Linux bundles, and disables NTLM and Negotiate HTTP auth (which can leak sensitive information about the computer). To avoid resolution fingerprinting, popups are also opened in new tabs by default.

Here is the complete changelog for 3.6.5:

  • All Platforms
    • Update Firefox to 24.8.0esr
    • Update NoScript to 2.6.8.39
    • Update HTTPS Everywhere to 4.0.0
    • Update Torbutton to 1.6.12.1
      • Bug 12684: New strings for canvas image extraction message
      • Bug 8940: Move RecommendedTBBVersions file to www.torproject.org
      • Bug 9531: Workaround to avoid rare hangs during New Identity
    • Bug 12684: Improve Canvas image extraction permissions prompt
    • Bug 7265: Only prompt for first party canvas access. Log all scripts
      that attempt to extract canvas images to Browser console.

    • Bug 12974: Disable NTLM and Negotiate HTTP Auth
    • Bug 2874: Remove Components.* from content access (regression)
    • Bug 9881: Open popups in new tabs by default
  • Linux:
    • Bug 12103: Adding RELRO hardening back to browser binaries.


Tor Browser 4.0-alpha-2

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

This release also includes important security updates to Firefox.

In addition to including the changes in 3.6.5, this release also is the first Tor Browser release to enable the in-browser Firefox-based updater. This means that if all goes well, 4.0-alpha-2 users will notified of an available update via a notification similar to that in Firefox. You will then be able to download and install it directly via the browser UI. By default, neither the download nor the update will happen automatically, so if you are not feeling adventurous, you need not allow it to update in this way. Even if you are feeling adventurous, you should probably back up your Tor Browser directory before updating.

In addition to the updater, this release should also re-enable the basic hardening features on Windows, including ASLR, DEP, and SSP.

Furthermore, the NoScript behavior in this release has changed. Selecting "Temporarily allow scripts" will now automatically allow all scripts in a page. This was done for usability reasons, to make it easier for novice users to run Tor Browser with scripting disabled most of the time. This will also hopefully make it possible for more people to use the "High Security" setting in our upcoming Security Slider, which will have Javascript disabled globally via NoScript by default.

Here is the complete changelog for 4.0-alpha-2:

  • All Platforms
    • Update Firefox to 24.8.0esr
    • Update NoScript to 2.6.8.39
    • Update Tor Launcher to 0.2.7.0
      • Bug 11405: Remove firewall prompt from wizard.
      • Bug 12895: Mention @riseup.net as a valid bridge request email address
      • Bug 12444: Provide feedback when “Copy Tor Log” is clicked.
      • Bug 11199: Improve error messages if Tor exits unexpectedly
    • Update Torbutton to 1.6.12.1
      • Bug 12684: New strings for canvas image extraction message
      • Bug 8940: Move RecommendedTBBVersions file to www.torproject.org
    • Bug 12684: Improve Canvas image extraction permissions prompt
    • Bug 7265: Only prompt for first party canvas access. Log all scripts
      that attempt to extract canvas images to Browser console.

    • Bug 12974: Disable NTLM and Negotiate HTTP Auth
    • Bug 2874: Remove Components.* from content access (regression)
    • Bug 4234: Automatic Update support (off by default)
    • Bug 9881: Open popups in new tabs by default
    • Meek Pluggable Transport:
      • Bug 12766: Use TLSv1.0 in meek-http-helper to blend in with Firefox 24
  • Windows:
    • Bug 10065: Enable DEP, ASLR, and SSP hardening options
  • Linux:
    • Bug 12103: Adding RELRO hardening back to browser binaries.



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

Sep 03, 2014

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

Tor Browser 3.6.5 and 4.0-alpha-2 are out

The Tor Browser team put out two new releases of the privacy-preserving web browser. Among the major changes, version 3.6.5 upgrades Firefox to 24.8.0esr, and includes an improved prompt to help users defend against HTML5 canvas image fingerprinting, following a patch by Isis Lovecruft. Version 4.0-alpha-2 additionally includes the code for the forthcoming Tor Browser auto-updater (switched off by default) and “better hardening for Windows and Linux builds”.

As ever, you can download the new releases along with their signature files from the Tor Project’s distribution directory. Please upgrade as soon as you can.

Tails 1.1.1 is out

The Tails team released version 1.1.1 of the Debian- and Tor-based live operating system. As well as upgrading key components like Tor, Iceweasel, and Linux, this release disables I2P by default when Tails is booted, in response to the vulnerability recently disclosed by Exodus Intelligence. Like Truecrypt, “i2p” must now be specified as a parameter on booting by users who wish to use it.

A number of other security fixes and routine improvements make this an important update for all Tails users. See the full changelog in the team’s announcement, then update from a running copy of Tails 1.1 if you have one, or head to the download page if you don’t.

Helping Internet services accept anonymous users

Without a large and diverse network, run by thousands of dedicated volunteers, Tor would be nowhere near as useful or popular as it currently is. Although the current situation might at times seem fragile, there are still many places where it is feasible to host Tor exit nodes.

However, Tor would become much less attractive to users if they found themselves unable to reach or interact with their favorite websites while using it, a situation that is unfortunately growing more common as site administrators and engineers react negatively to instances of abusive Tor traffic by banning anonymous connections outright. Tor users and developers, as well as members of other online communities (such as Wikimedia), have tried to address the issue before, but real progress has yet to be made.

Roger Dingledine wrote a “call to arms” explaining the problem in detail and exploring possible paths to a solution: “Step one is to enumerate the set of websites and other Internet services that handle Tor connections differently from normal connections […]. Step two is to sort the problem websites based on how amenable they would be to our help”.

Since the problem involves humans as much as it does machines, anyone working on it will have to be both “technical” but also ”good at activism”. If you fit that description, OTF has expressed interest in funding work on this issue through their Information Controls Fellowship Program. Please read Roger’s blog post in full for more details.

Monthly status reports for August 2014

The wave of regular monthly reports from Tor project members for the month of August has begun. Damian Johnson released his report first, followed by reports from Georg Koppen, Sherief Alaa, Noel Torres, Kevin P Dyer, Nick Mathewson, Lunar, Arthur D. Edelstein, Karsten Loesing, Andrew Lewman, Arlo Breault, Pearl Crescent, and Michael Schloh von Bennewitz.

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

Miscellaneous news

Yawning Angel released a new set of experimental Tor Browser builds containing the proposed obfs4 pluggable transport, along with a changelog; “questions, comments, feedback” are welcome on the email thread or the bug ticket tracking the deployment of obfs4.

Arturo Filastò announced the release of version 1.1.0 of oonibackend, the tool “used by ooniprobe to discover the addresses of test helpers (via the bouncer) to submit reports to (via the collector) and to perform some measurements that require a backend system to talk to (via test helpers)”.

meejah posted a list of tasks to be completed in order to bring Tor Weather to a deployable state, following the recent rewrite effort and the Google Summer of Code project by Sreenatha Bhatlapenumarthi.

Israel Leiva submitted a summary of work completed as part of the “Revamp GetTor” Google Summer of Code project: “The plan for now is to keep doing tests and deploy it asap (hopefully during September).”

Mike Perry posted an updated version of the proposal for website fingerprinting countermeasures which he co-authored with Marc Juarez as part of the latter’s Google Summer of Code project.

Lunar gave a talk at this year’s DebConf on the effort to build Debian packages deterministically, which is inspired in large part by Tor Browser’s use of the same technology. Major progress was achieved during the conference.

David Fifield submitted a breakdown of the costs incurred by the infrastructure that supports the meek pluggable transport since its introduction. The total to date from both the Google App Engine and Amazon AWS front domains? $6.56.

Thanks to P D and Daniel Pajonzeck for running mirrors of the Tor Project website and software!

Also on the subject of mirrors, Roger Dingledine alerted the tor-mirrors mailing list to the fact that the Tor Project website (specifically the distribution directory) will shortly be increasing in size to eight or nine gigabytes, as a result of the soon-to-be-implemented Tor Browser updater. Mirror operators will need to ensure that they can provide enough disk space to accommodate the change.

whonixqubes announced the release of an integrated version of the Whonix and Qubes operating systems: “I look forward to helping make Qubes + Whonix integration even tighter and more seamless throughout the future.”

Tor help desk roundup

The help desk has been asked if Tor can make a website visit appear to come from China. Tor connections appear to originate from the country where the exit relay in use is located; since Tor is blocked in China, there are zero exit relays in China. A visualization of the different country-locations of exit relays can be found on Tor’s metrics page.

News from Tor StackExchange

Anony Mouse wanted to know why Facebook shows the location of the user’s last login over Tor as Baghdad or Dhaka, instead of the real location of the exit relay. qbi posted a screenshot showing this issue. According to Facebook, this information is based on an approximation, but this approximation locates all Tor exit relays either in Baghdad or in Dhaka.

user3500 wants to contribute to Tor and asks how this can be done as an inexperienced developer. Jens Kubieziel replied with several possibilities, including reading the volunteer page and Tor Weekly News: in particular, the section containing easy development tasks might be a good start. Roya pointed out that any contribution is better than no contribution, and encouraged user3500 to just get started. Umut Seven recommended writing unit tests.

Kras wants to use FoxyProxy in connection with Tor Browser Bundle and asks if it is safe to do so. At the moment, there is only an answer saying “yes”, without any explanation. What is your experience? Is it safe for a user to install and use FoxyProxy?


This issue of Tor Weekly News has been assembled by harmony, Matt Pagan, Lunar, qbi, and Arlo Breault.

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!

Sep 02, 2014

Tails, The Amnesic Incognito Live System, version 1.1.1, is out.

All users must upgrade as soon as possible: this release fixes numerous security issues.

Download it now.

Changes

Notable user-visible changes include:

  • Security fixes
    • Upgrade the web browser to 24.8.0esr-0+tails1~bpo70+1 (Firefox 24.8.0esr + Iceweasel patches + Torbrowser patches).
    • Add an I2P boot parameter. Without adding "i2p" to the kernel command line, I2P will not be accessible for the Live user. I2P was also upgraded to 0.9.14.1-1~deb7u+1, and stricter firewall rules are applied to it, among other security enhancements.
    • Upgrade Tor to 0.2.4.23-2~d70.wheezy+1 (fixes CVE-2014-5117).
    • Upgrade Linux to 3.14.15-2 (fixes CVE-2014-3534, CVE-2014-4667 and CVE-2014-4943).
    • Prevent dhclient from sending the hostname over the network (ticket #7688).
    • Override the hostname provided by the DHCP server (ticket #7769).
  • Bugfixes
    • Don't ship OpenJDK 6: I2P prefers v7, and we don't need both (ticket #7807).
    • Prevent Tails Installer from updating the system partition properties on MBR partitions (ticket #7716).
  • Minor improvements
    • Upgrade to Torbutton 1.6.12.1.
    • Install gnome-user-guide (ticket #7618).
    • Install cups-pk-helper (ticket #7636).
    • Update the SquashFS sort file, which should speed up boot from DVD (ticket #6372).
    • Compress the SquashFS more aggressively (ticket #7706) which should make the Tails ISO image smaller.

See the online Changelog for technical details.

Known issues

Longstanding known issues.

I want to try it or to upgrade!

Go to the download page.

What's coming up?

The next Tails release is scheduled for October 14.

Have a look to our roadmap to see where we are heading to.

Do you want to help? There are many ways you can contribute to Tails. If you want to help, come talk to us!

Support and feedback

For support and feedback, visit the Support section on the Tails website.

Aug 29, 2014

Looking for a way to help the Internet stay open and free? This topic needs some dedicated people to give it more attention — it could easily grow to as large a project as Tor itself. In the short term, OTF's Information Controls Fellowship Program has expressed interest in funding somebody to get this project going, and EFF's Eva Galperin has said she'd be happy to manage the person as an OTF fellow at EFF, with mentorship from Tor people. The first round of those proposals has a deadline in a few days, but if that timeframe doesn't work for you, this problem isn't going away: let us know and we can work with you to help you coordinate other funding.

The problem

We used to think there are two main ways that the Tor network can fail. First, legal or policy pressure can make it so nobody is willing to run a relay. Second, pressure on or from Internet Service Providers can reduce the number of places willing to host exit relays, which in turn squeezes down the anonymity that the network can provide. Both of these threats are hard to solve, but they are challenges that we've known about for a decade, and due in large part to strong ongoing collaborations we have a pretty good handle on them.

We missed a third threat to Tor's success: a growing number of websites treat users from anonymity services differently. Slashdot doesn't let you post comments over Tor, Wikipedia won't let you edit over Tor, and Google sometimes gives you a captcha when you try to search (depending on what other activity they've seen from that exit relay lately). Some sites like Yelp go further and refuse to even serve pages to Tor users.

The result is that the Internet as we know it is siloing. Each website operator works by itself to figure out how to handle anonymous users, and generally neither side is happy with the solution. The problem isn't limited to just Tor users, since these websites face basically the same issue with users from open proxies, users from AOL, users from Africa, etc.

Two recent trends make the problem more urgent. First, sites like Cloudflare, Akamai, and Disqus create bottlenecks where their components are used by many websites. This centralization impacts many websites at once when e.g. Cloudflare changes its strategy for how to handle Tor users. Second, services increasingly outsource their blacklisting, such that e.g. Skype refuses connections from IP addresses that run Tor exit relays, not because they worry about abuse via Tor (it's hard to use Skype over Tor), but because their blacklist provider has an incentive to be overbroad in its blocking. (Blacklist providers compete in part by having "the most complete" list, and in many cases it's hard for services to notice that they're losing contributions from now-missing users.)

Technical mechanisms do exist to let anonymous users interact with websites in ways that control abuse better. Simple technical approaches include "you can read but you can't post" or "you have to log in to post". More complex approaches track reputation of users and give them access to site features based on past behavior of the user rather than on past behavior of their network address. Several research designs suggest using anonymous credentials, where users anonymously receive a cryptographic credential and then prove to the website that they possess a credential that hasn't been blacklisted — without revealing their credential, so the website can't link them to their past behavior.

Social mechanisms have also proven effective in some cases, ranging from community moderation (I hear Wikipedia Germany manually approves edits from users who don't have sufficiently reputable accounts), to flagging behavior from Tor users (even though you don't know *which* Tor user it is) so other participants can choose how to interact with them.

But applying these approaches to real-world websites has not gone well overall. Part of the challenge is that the success stories are not well-publicized, so each website feels like it's dealing with the question in isolation. Some sites do in fact face quite different problems, which require different solutions: Wikipedia doesn't want jerks to change the content of pages, whereas Yelp doesn't want competitors to scrape all its pages. We can also imagine that some companies, like ones that get their revenue from targeted advertising, are fundamentally uninterested in allowing anonymous users at all.

A way forward

The solution I envision is to get a person who is both technical and good at activism to focus on this topic. Step one is to enumerate the set of websites and other Internet services that handle Tor connections differently from normal connections, and look for patterns that help us identify the common (centralized) services that impact many sites. At the same time, we should make a list of solutions — technical and social — that are in use today. There are a few community-led starts on the Tor wiki already, like the DontBlockMe page and a List of Services Blocking Tor.

Step two is to sort the problem websites based on how amenable they would be to our help. Armed with the toolkit of options we found in step one, we should go to the first (most promising) site on the list and work with them to understand their problem. Ideally we can adapt one of the ideas from the toolkit; otherwise we'll need to invent and develop a new approach tailored to their situation and needs. Then we should go to the second site on the list with our (now bigger) toolkit, and so on down the list. Once we have some success stories, we can consider how to scale better, such as holding a conference where we invite the five best success cases plus the next five unsolved sites on our list.

A lot of the work will be building and maintaining social connections with engineers at the services, to help them understand what's possible and to track regressions (for example, every year or so Google gets a new engineer in charge of deciding when to give out Captchas, and they seem to have no institutional memory of how the previous one decided to handle Tor users). It might be that the centralization of Cloudflare et al can be turned around into an advantage, where making sure they have a good practices will scale to help many websites at once.

EFF is the perfect organization to lead this charge, given its community connections, its campaigns like Who has your back?, and its more (at least more than Tor ;) neutral perspective on the topic. And now, when everybody is sympathetic about the topic of surveillance, is a great time to try to take back some ground. We have a wide variety of people who want to help, from scientists and research groups who would help with technical solutions if only they understood the real problems these sites face, to users and activists who can help publicize both the successful cases and the not-yet-successful cases.

Looking ahead to the future, I'm also part of an upcoming research collaboration with Dan Boneh, Andrea Forte, Rachel Greenstadt, Ryan Henry, Benjamin Mako Hill, and Dan Wallach who will look both at the technical side of the problem (building more useful ideas for the toolkit) and also the social side of the problem: how can we quantify the loss to Wikipedia, and to society at large, from turning away anonymous contributors? Wikipedians say "we have to blacklist all these IP addresses because of trolls" and "Wikipedia is rotting because nobody wants to edit it anymore" in the same breath, and we believe these points are related. The group is at the "applying for an NSF grant" stage currently, so it will be a year or more before funding appears, but I mention it because we should get somebody to get the ball rolling now, and hopefully we can expect reinforcements to appear as momentum builds.

In summary, if this call to arms catches your eye, your next steps are to think about what you most want to work on to get started, and how you would go about doing it. You can apply for an OTF fellowship, or we can probably help you find other funding sources as needed too.

Aug 27, 2014

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

Orfox: a new Firefox-based secure browser for Android

With the growing popularity of pocket computers (also known as “phones”), users need to have access to censorship-circumvention and anonymity systems on these devices as well as on their desktop or laptop machines. While there is currently no supported implementation of Tor for Apple’s iOS, the Guardian Project works closely with the Tor Project to produce (amongst other software) a Tor client for Android named Orbot. Mobile applications can be proxied through Orbot just as they can through the Tor client on other operating systems, but mobile web browsing potentially suffers from the same issues that the Tor Browser was designed to protect against, such as disk leaks and a large attack surface. The Guardian Project has therefore also been maintaining a dedicated mobile browser for use with Orbot under the name Orweb.

Orweb is based on WebView, and is limited by that browser’s features; flaws such as the potential HTML5 IP leak, while possible to work around in the short term, have made it clear that the best future for secure mobile browsing lies in a switch to an application based on Firefox/Fennec/GeckoView.

Following a successful Google Summer of Code project by Amogh Pradeep and work by other Guardian Project members, Nathan Freitas announced that “a real working version” of Orfox, the new Orbot-compatible mobile browser, is now available. “All the necessary defaults [have been] changed to match Tor Browser’s defaults as closely as possible”; the developers also “remove the Android permissions for things like camera, mic, GPS” and “turn off webrtc.”

“We still need to figure out which preferences and features map between the desktop mobile browser and the Android version, so there is quite a bit of work to do”, but you can download and test this initial version by following the links in Nathan’s email. “Over the next few months we hope to launch this as our new official browser for Orbot, and deprecate Orweb as quickly as possible”, he concluded.

Miscellaneous news

A new release of ooniprobe, the network interference data collector for OONI, was announced by Arturo Filastò. Version 1.1.0 introduces a new command line tool “for listing the reports that have not been published to a collector and that allows the probe operator to choose which ones they would like to upload”. The new version also improves the privacy of the reports by sanitizing file paths.

Developers of applications using Onionoo — the web service to learn about currently running Tor relays and bridges — are invited to join the new onionoo-announce mailing list. Keeping the list low volume, Karsten Loesing plans on using it to announce major protocol changes, scheduled maintenance, major bug fixes, and other important news.

Yawning Angel has made available an experimental version of the Tor Browser that includes the latest version of the obfs4 pluggable transport. Testing on Windows and OS X would be particularly welcome.

Fabian Keil reported that FreeBSD now includes ports of liballium and obfsclient.

JusticeRage explained how relay operators who offer exiting on port 25 can protect the reputation of their domain name by using the Sender Policy Framework.

Sreenatha Bhatlapenumarthi sent the final GSoC report for the Tor Weather rewrite project. Juha Nurmi sent another report on the development of ahmia.fi.

Thanks to s7r for hosting a new mirror of the Tor Project’s website and software!

Tor help desk roundup

Users of different VPN (Virtual Private Network) services have told the help desk that Tor Browser has difficulty connecting to Tor when a VPN is in use. Using Tor with a VPN is not supported. For a trusted entry into the Tor network, bridges and pluggable transports are recommended, while for anonymizing all network traffic coming from a computer, Tails is recommended.

Easy development tasks to get involved with

The bandwidth authority scanners measure the actual bandwidth offered by Tor relays in order to get accurate information into the Tor consensus. The measurement process currently splits up the set of relays that are to be measured into 4 subsets, with the goal that measuring each of these subsets should take about the same time. However, this is not the case. Measuring subsets 2 and 3 is about twice as fast as measuring subset 1, and subset 4 is twice as fast as subset 2 and 3. If you're up for doing some experiments to split up the set into more equal subsets, please let us know about your findings on the ticket.


This issue of Tor Weekly News has been assembled by Lunar, harmony, Matt Pagan, Karsten Loesing, and dope457.

Want to continue reading TWN? Please help us create this newsletter. We still need more volunteers to watch the Tor community and report important news. Please see the project page, write down your name and subscribe to the team mailing list if you want to get involved!