Blogs

TorBirdy 0.1.4: Fifth Beta and Bug Fix Release

We are happy to announce the release of TorBirdy 0.1.4, our fifth beta release. This is a bug-fix release, which fixes an issue with TorBirdy 0.1.3 that prevents Thunderbird from starting if three or more than three IMAP accounts are configured. This was reported by users in several tickets (#14099, #13982, #13722, #14007, #14130) and affects all platforms.

Changes in TorBirdy 0.1.4

0.1.4, 09 March 2015
* Fix bug that prevented Thunderbird with TorBirdy 0.1.3 from starting
in profiles with more than three IMAP accounts (closes #14099, #13982,
#13722, #14007, #14130)

Technical Explanation

This bug was due to a variable in a for lop that was declared twice and was affecting the enumeration of an outer loop (lines 521 and 531 in components/torbirdy.js) used to iterate over IMAP accounts. Please see commit 625f80e in the TorBirdy repository for the fix.

Users who are not affected by this issue (less than three IMAP accounts configured) may also upgrade but note that this release does not introduce any new features.

We offer two ways of installing TorBirdy -- either by visiting our website (GPG signature) or by visiting the Mozilla Add-ons page for TorBirdy. (TorBirdy 0.1.4 has been fully reviewed by Mozilla.)

Using TorBirdy for the First Time?

As a general anonymity and security note: we are still working on two known anonymity issues with Mozilla. Please make sure that you read the Before Using TorBirdy and Known TorBirdy Issues sections on the wiki before using TorBirdy.

We had love help with getting our patches accepted, or anything that you think will help improve TorBirdy!

Feel free to follow along with the release on the tor-talk mailing list.

Tor Weekly News — March 11th, 2015

Welcome to the tenth issue in 2015 of Tor Weekly News, the weekly newsletter that covers what’s happening in the Tor community.

Tor 0.2.6.4-rc is out

Nick Mathewson announced the first release candidate in the Tor 0.2.6 series; the next release will hopefully be the stable version.

This update “fixes an issue in the directory code that an attacker might be able to use in order to crash certain Tor directories”, as well as various other bugfixes and improvements. See Nick’s announcement for a full changelog, and get your copy of the source code from the distribution directory.

More monthly status reports for February 2015

The wave of regular monthly reports from Tor project members for the month of February continued, with reports from Sebastian Hahn, Arlo Breault, Karsten Loesing, and George Kadianakis.

Israel Leiva reported on behalf of the GetTor project, while the Tails team also resumed publishing status reports, with one report for the second half of 2014 and one for the beginning of this year.

Miscellaneous news

Ximin Luo announced preliminary Debian packages for the meek pluggable transport. See Ximin’s message for installation instructions.

Sukhbir Singh announced a second alpha version of Tor Messenger, the torified instant-messaging client with multi-protocol support and Off-the-Record encryption. While not yet ready for public use, Linux bundles are available for developers and advanced users who want to try out this exciting new software and provide feedback; if you run into any new issues, open a ticket on the bug tracker and select the “Tor Messenger” component.

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

For the past few years, Tor has taken part in Google’s Summer of Code mentoring program, with many positive contributions made and several projects launched or redeveloped as a result; this year, however, the program has been scaled back somewhat, and longstanding participants like the Tor Project, Mozilla, and the Linux Foundation have been “dropped to make way for newcomers”, as Damian Johnson noted in his monthly report [see above]. If you’d still like to join the community of Tor developers, don’t be deterred: see the Volunteer page for a wealth of ideas for getting started.

The British Parliamentary Office of Science and Technology, “charged with providing independent and balanced analysis of policy issues that have a basis in science and technology”, issued a briefing paper on the subject of “the darknet and online anonymity”.

arm is the status monitor of choice for Tor relay operators everywhere; unfortunately, the name is easily confused with that of the ARM processor family, so lead developer Damian Johnson is poised to change the program’s name to “Seth”: “Any strong reasons to pick something else? Nothing is set in stone yet so still open to alternatives.”

Tor developer and Nos Oignons member Lunar gave a lengthy and detailed interview to France Culture’s “Les Nouvelles vagues”, offering an introduction to Tor and online privacy.


This issue of Tor Weekly News has been assembled by Karsten Loesing, the Tails team, 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!

Tor 0.2.6.4-rc is released

Tor 0.2.6.4-rc fixes an issue in the directory code that an attacker might be able to use in order to crash certain Tor directories. It also resolves some minor issues left over from, or introduced in, Tor 0.2.6.3-alpha or earlier.

If no serious issues are found in this release, the next 0.2.6 release will make 0.2.6 the officially stable branch of Tor.

You can download the source from the usual place on the website. Packages should be up in a few days.

NOTE: This is an alpha release. Please expect bugs.

Changes in version 0.2.6.4-rc - 2015-03-09
  • Major bugfixes (crash, OSX, security):
    • Fix a remote denial-of-service opportunity caused by a bug in OSX's _strlcat_chk() function. Fixes bug 15205; bug first appeared in OSX 10.9.
  • Major bugfixes (relay, stability, possible security):
    • Fix a bug that could lead to a relay crashing with an assertion failure if a buffer of exactly the wrong layout is passed to buf_pullup() at exactly the wrong time. Fixes bug 15083; bugfix on 0.2.0.10-alpha. Patch from "cypherpunks".
    • Do not assert if the 'data' pointer on a buffer is advanced to the very end of the buffer; log a BUG message instead. Only assert if it is past that point. Fixes bug 15083; bugfix on 0.2.0.10-alpha.

  read more »

Tor Weekly News — March 4th, 2015

Welcome to the ninth issue in 2015 of Tor Weekly News, the weekly newsletter that covers what’s happening in the Tor community.

Tor Browser 4.0.4 and 4.5-alpha-4 are out

The Tor Browser team announced new releases in the stable and alpha branches of the privacy-preserving browser. Version 4.0.4 contains updates to the bundled versions of Firefox, OpenSSL, HTTPS-Everywhere and NoScript (disabling the new NoScript option to make temporary permissions permanent); it also prevents meek from issuing a second update notification.

Meanwhile, following on from the recent Tor UX sprint, version 4.5-alpha-4 incorporates many interface improvements designed to make life easier for Tor users. The connection configuration wizard has been reordered to avoid confusion between network proxies and bridge relays, while a reorganized Torbutton menu now offers a “New circuit for this site” option that removes the need for the user to close all open pages in order to change circuits for one destination. If users do decide to use the “New identity” option, they will now be warned that this involves losing currently-open tabs and windows.

Please see the announcements for full details of the changes, as well as instructions for download and verification.

Reddit donates $82,765.95 to The Tor Project, Inc.

One year ago, the online community Reddit announced that it would be donating 10% of its advertising revenue in 2014 to ten non-profits, to be selected by the Reddit community. Voting took place over the last week, and The Tor Project, Inc. placed tenth in the final ranking, in good company with other charities like the Electronic Frontier Foundation, Wikimedia Foundation, and the Free Software Foundation, each of which being eligible for a $82,765.95 donation.

Community donations like this are a big step on the way to solving the problem of overreliance on single funding streams — often from national governments — that affects open-source security projects, as recently discussed by Jillian York of the Electronic Frontier Foundation (who came first in Reddit’s donation drive). Many thanks to Reddit (the company) and Reddit (the community) for their magnificent gesture of support for privacy and anonymity online — and if you’d like to join them, please take a look at the Tor Project website for ways to contribute!

2015 Winter Tor meeting

A group of around 70 dedicated Tor contributors is meeting this week in Valencia, Spain to discuss plans, milestones, deadlines, and other important matters.

This meeting is kindly hosted together with the OpenITP circumvention tech festival with public outreach and community events joined or co-hosted by Tor members.

Notes are available from the sessions happening on Monday and Tuesday for those who couldn’t make it this time.

Monthly status reports for February 2015

The wave of regular monthly reports from Tor project members for the month of February has begun. Juha Nurmi released his report first, followed by reports from Nick Mathewson, Philipp Winter, Georg Koppen, Sherief Alaa, Pearl Crescent, and Damian Johnson.

Mike Perry reported on behalf of the Tor Browser team.

Miscellaneous news

George Kadianakis reports preliminary results from "a project to study and quantify hidden services traffic." George emphasizes that they "are collecting data from just a few volunteer relays" and that "extrapolating from such a small sample is difficult." Taken with a grain of salt, they "estimate that about 30,000 hidden services announce themselves to the Tor network every day, using about 5 terabytes of data daily." They "also found that hidden service traffic is about 3.4% of total Tor traffic." George, together with Karsten Loesing, wrote a short technical report with more details on their results and methods.

Nick Mathewson announces an important step in stabilizing the Tor 0.2.6.x release series: all work on that series will proceed on the “maint-0.2.6” branch, while work on the next release series 0.2.7.x will happen on the “master” branch. This step allows developers to focus on one branch for fixing bugs and another branch for developing new features.


This issue of Tor Weekly News has been assembled by Harmony, Karsten Loesing, and qbi.

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!

Coming up in Tor 0.2.6...

Hi, all! We've begun the feature-freeze for Tor 0.2.6, so we know with pretty high probability what new features and changes will be in the next stable release. The ChangeLog and ReleaseNotes files will have a pretty comprehensive overview of what changed since 0.2.5, but I thought I'd like to write up some better descriptions of the major changes.

AF_UNIX socket support for clients and hidden services

This is going to help developers of applications that use Tor make their designs more secure. On Unix and OS X, applications can bind to objects in the file namespace and use them as if they were network connections. Now, Tor can receive connections and make connections to local hidden service applications over this mechanism. That's pretty cool, because it means that integrators can prevent other applications from using the network at all, to ensure that they never make connections that don't go through Tor. Maybe we could use this eventually to turn off networking in Tor Browser entirely on OSX and Unix.

(Sorry, no Windows NamedPipe support yet. That would be cool for a future version, but it'll require some major hacks in our network stack.)

Jake, Andrea, David and I have all worked on the implementation here; it ended up being pretty elegant.

More info: #12585, #11485, #14451.

Faster cpuworker design

We want to use multithreading to spread Tor's cryptography across more cores, but one challenge in doing so has been that our old code for dividing work across multiple cores was written 12 years ago, and designed to accommodate systems that didn't support threading at all. To support no-threading builds, we allowed the CPU workers to be processes instead of threads, and we always communicated with workers over a socket pair. read more »

Some statistics about onions

Non-technical abstract:


We are starting a project to study and quantify hidden services traffic. As part of this project, we are collecting data from just a few volunteer relays which only allow us to see a small portion of hidden service activity (between 2% and 5%). Extrapolating from such a small sample is difficult, and our data are preliminary.

We've been working on methods to improve our calculations, but with our current methodology, we estimate that about 30,000 hidden services announce themselves to the Tor network every day, using about 5 terabytes of data daily. We also found that hidden service traffic is about 3.4% of total Tor traffic, which means that, at least according to our early calculations, 96.6% of Tor traffic is *not* hidden services. We invite people to join us in working to research methodologies and develop systems for better understanding Tor hidden services.



Hello,

Over the past months we've been working on hidden service statistics. Our goal has been to answer the following questions:

  • "Approximately how many hidden services are there?"
  • "Approximately how much traffic of the Tor network is going to hidden services?"


We chose the above two questions because even though we want to understand hidden services, we really don't want to harm the privacy of Tor users. From a privacy perspective, the above two questions are relatively easy questions to answer because we don't need data from clients or the hidden services themselves; we just need data from hidden service directories and rendezvous points. Furthermore, the measurements reported by each relay cannot be linked back to specific hidden services or their clients.

Our first move was to research various ways we could collect these statistics in a privacy-preserving manner. After days of discussions on obfuscating statistics, we began writing a Tor proposal with our design, as well as code that implements the proposal. The code has since been reviewed and merged to Tor! The statistics are currently disabled by default so we asked volunteer relay operators to explicitly turn them on. Currently there are about 70 relays publishing measurements to us every 24 hours:


Number of relays reporting stats


So as of now we've been receiving these measurements for over a month, and we have thought a lot about how to best use the reported measurements to derive interesting results. We finally have some preliminary results we would like to share with you:

How many hidden services are there?

All in all, it seems that every day about 30000 hidden services announce themselves to the hidden service directories. Graphically:


Number of hidden services


By counting the number of unique hidden service addresses seen by HSDirs, we can get the approximate number of hidden services. Keep in mind that we can only see between 2% and 5% of the total HSDir space, so the extrapolation is, naturally, messy.

How much traffic do hidden services cause?

Our preliminary results show that hidden services cause somewhere between 400 to 600 Mbit of traffic per second, or equivalently about 4.9 terabytes a day. Here is a graph:


Hidden services traffic volume


We learned this by getting rendezvous points to publish the total number of cells transferred over rendezvous circuits, which allows us to learn the approximate volume of hidden service traffic. Notice that our coverage here is not very good either, with a probability of about 5% that a hidden service circuit will use a relay that reports these statistics as a rendezvous point.

A related statistic here is "How much of the Tor network is actually hidden service usage?". There are two different ways to answer this question, depending on whether we want to understand what clients are doing or what the network is doing. The fraction of hidden-service traffic at Tor clients differs from the fraction at Tor relays because connections to hidden services use 6-hop circuits while connections to the regular Internet use 3-hop circuits. As a result, the fraction of hidden-service traffic entering or leaving Tor is about half of the fraction of hidden-service traffic inside of Tor. Our conclusion is that about 3.4% of client traffic is hidden-service traffic, and 6.1% of traffic seen at a relay is hidden-service traffic.

Conclusion and future work

In this blog post we presented some preliminary results that could be extracted from these new hidden service statistics. We hope that this data can help us better gauge the future development and maturity of the onion space as well as detect potential incidents and bugs on the network. To better present our results and methods, we wrote a short technical report that outlines the exact process we followed. We invite you to read it if you are curious about the methodology or the results.

Finally, this project is only a few months old, and there are various plans for the future. For example:

  • There are more interesting questions that we could examine in this area. For example: "How many people are using hidden services every day?" and "How many times does someone try to visit a hidden service that does not exist anymore?."

    Unfortunately, some of these questions are not easy to answer with the current statistics reporting infrastructure, mainly because collecting them in this way could reveal information about specific hidden services but also because the results of the current system contain too much obfuscating data (each reporting relay randomizes its numbers a little bit before publishing them, so we can learn about totals but not about specific events).

    For this reason, we've been analyzing various statistics aggregation protocols that could be used in place of the current system, allowing us to safely collect other kinds of statistics.


  • We need to incorporate these statistics in our Metrics portal so that they are updated regularly and so that everyone can follow them.

  • Currently, these hidden service statistics are not collected in relays by default. Unfortunately, that gives us very small coverage of the network, which in turn makes our extrapolations very noisy. The main reason that these statistics are disabled by default is that similar statistics are also disabled (e.g. CellStatistics). Also, this allows us more time to consider privacy consequences. As we analyze more of these statistics and think more about statistics privacy, we should decide whether to turn these statistics on by default.

    It's worth repeating that the current results are preliminary and should be digested with a grain of salt. We invite statistically-inclined people to review our code, methods, and results. If you are a researcher interested in digging into the measurements themselves, you can find them in the extra-info descriptors of Tor relays.

    Over the next months, we will also be thinking more about these problems to figure out proper ways to analyze and safely measure private ecosystems like the onion space.


Till then, take care, and enjoy Tor!

Tor Browser 4.0.4 is released

A new release for the stable Tor Browser is available from the Tor Browser Project page and also from our distribution directory.

Note: The individual bundles of the stable series are signed by one of the subkeys of the Tor Browser Developers signing key from now on, too. You can find its fingerprint on the Signing Keys page. It is:

pub   4096R/0x4E2C6E8793298290 2014-12-15
      Key fingerprint = EF6E 286D DA85 EA2A 4BA7
                        DE68 4E2C 6E87 9329 8290


Tor Browser 4.0.4 is based on Firefox ESR 31.5.0, which features important security updates to Firefox. Additionally, it contains updates to NoScript, HTTPS-Everywhere, and OpenSSL (none of the OpenSSL advisories since OpenSSL 1.0.1i have affected Tor, but we decided to update to the latest 1.0.1 release anyway).

Here is the changelog since 4.0.3:

  • All Platforms
    • Update Firefox to 31.5.0esr
    • Update OpenSSL to 1.0.1l
    • Update NoScript to 2.6.9.15
    • Update HTTPS-Everywhere to 4.0.3
    • Bug 14203: Prevent meek from displaying an extra update notification
    • Bug 14849: Remove new NoScript menu option to make permissions permanent
    • Bug 14851: Set NoScript pref to disable permanent permissions

Tor Browser 4.5a4 is released

The Tor Browser team is proud to announce the release of the fourth alpha of the 4.5 series of Tor Browser. The release is available from the extended downloads page and also from our distribution directory.

Tor Browser 4.5a4 is based on Firefox ESR 31.5.0, which features important security updates to Firefox. Moreover, this release includes an updated Tor, 0.2.6.3-alpha, and switches Scramblesuit and obfs3 bridge support to a new golang-based implementation. We are especially interested in hearing any issues with using obfs3, obfs4, and Scramblesuit in this release.

The release also features several improvements to usability, following the results of the usability sprint at the end of last month. In particular, the Torbutton onion menu and related preference windows have been overhauled to provide more simplicity and more focus. The onion menu now features a much requested "New Circuit for this site" option, and the security and privacy settings window have been simplified. For censored users, the first run configuration wizard was also improved to present the choice of Pluggable Transport before the local proxy information, in an effort to avoid confusion between Pluggable Transports and local proxies. As can be seen from the changelog below, the release contains several other usability tweaks and enhancements as well.

Here is the full changelog for changes since 4.5-alpha-3:

  • All Platforms
    • Update Firefox to 31.5.0esr
    • Update Tor to 0.2.6.3-alpha
    • Update OpenSSL to 1.0.1l
    • Update NoScript to 2.6.9.15
    • Update obfs4proxy to 0.0.4
      • Use obfs4proxy for ScrambleSuit bridges
    • Update Torbutton to 1.9.0.0
      • Bug 13882: Fix display of bridges after bridge settings have been changed
      • Bug 5698: Use "Tor Browser" branding in "About Tor Browser" dialog
      • Bug 10280: Strings and pref for preventing plugin initialization.
      • Bug 14866: Show correct circuit when more than one exists for a given domain
      • Bug 9442: Add New Circuit button to Torbutton menu
      • Bug 9906: Warn users before closing all windows and performing new identity.
      • Bug 8400: Prompt for restart if disk records are enabled/disabled.
      • Bug 14630: Hide Torbutton's proxy settings tab.
      • Bug 14632: Disable Cookie Manager until we get it working.
      • Bug 11175: Remove "About Torbutton" from onion menu.
      • Bug 13900: Remove remaining SafeCache code in favor of C++ patch
      • Bug 14490: Use Disconnect search in about:tor search box
      • Bug 14392: Don't steal input focus in about:tor search box
      • Bug 11236: Don't set omnibox order in Torbutton (to prevent translation)
      • Bug 13406: Stop directing users to download-easy.html.en on update
      • Bug 9387: Handle "custom" mode better in Security Slider
      • Bug 12430: Bind jar: pref to Security Slider
      • Bug 14448: Restore Torbutton menu operation on non-English localizations
      • Translation updates
    • Update Tor Launcher to 0.2.7.2
      • Bug 13271: Display Bridge Configuration wizard pane before Proxy pane
      • Bug 14336: Fix navigation button display issues on some wizard panes
      • Translation updates
    • Bug 14203: Prevent meek from displaying an extra update notification
    • Bug 14849: Remove new NoScript menu option to make permissions permanent
    • Bug 14851: Set NoScript pref to disable permanent permissions
    • Bug 14490: Make Disconnect the default omnibox search engine
    • Bug 11236: Fix omnibox order for non-English builds
      • Also remove Amazon, eBay and bing; add Youtube and Twitter
    • Bug 10280: Don't load any plugins into the address space.
    • Bug 14392: Make about:tor hide itself from the URL bar
    • Bug 12430: Provide a preference to disable remote jar: urls
    • Bug 13900: Remove 3rd party HTTP auth tokens via Firefox patch
    • Bug 5698: Fix branding in "About Torbrowser" window
  • Windows:
    • Bug 13169: Don't use /dev/random on Windows for SSP
  • Linux:
    • Bug 13717: Make sure we use the bash shell on Linux

Note: Once again, the individual bundles of both Tor Browser series are signed by one of the subkeys of the Tor Browser Developers signing key from now on. You can find its fingerprint on the Signing Keys page. It is:

pub   4096R/0x4E2C6E8793298290 2014-12-15
      Key fingerprint = EF6E 286D DA85 EA2A 4BA7
                        DE68 4E2C 6E87 9329 8290
Syndicate content Syndicate content