Blogs

Tor Open Hack Day in Berlin (for everyone)

Hello!

We are very happy to tell you that the Tor meeting in Berlin is currently underway!

During the past days we've been busy discussing the future of Tor as an organization and designing the protocols and features that we want to see in the future.

We would like to inform you that tomorrow (Thursday, October 1st) we will be
having an open day where everyone is welcome to come and discuss Tor
with us. People interested in Tor are welcome regardless of their
background or skills.

The meeting is taking place at Betahaus in Berlin all day, and you can find more information in the wiki.

Looking forward to see you here!

Thank you!

Tor 0.2.7.3-rc is released

Tor 0.2.7.3-rc is the first release candidate in the 0.2.7 series. It contains numerous usability fixes for Ed25519 keys, safeguards against several misconfiguration problems, significant simplifications to Tor's callgraph, and numerous bugfixes and small features.

This is the most tested release of Tor to date. The unit tests cover 39.40% of the code, and the integration tests (accessible with "make test-full-online", requiring stem and chutney and a network connection) raise the coverage to 64.49%.

NOTE: This is a release candidate. We think we've squashed most of the bugs, but there are probably a few more left over.

Changes in version 0.2.7.3-rc - 2015-09-25

  • Major features (security, hidden services):
    • Hidden services, if using the EntryNodes option, are required to use more than one EntryNode, in order to avoid a guard discovery attack. (This would only affect people who had configured hidden services and manually specified the EntryNodes option with a single entry-node. The impact was that it would be easy to remotely identify the guard node used by such a hidden service. See ticket for more information.) Fixes ticket 14917.
  • Major features (Ed25519 keys, keypinning):
    • The key-pinning option on directory authorities is now advisory- only by default. In a future version, or when the AuthDirPinKeys option is set, pins are enforced again. Disabling key-pinning seemed like a good idea so that we can survive the fallout of any usability problems associated with Ed25519 keys. Closes ticket 17135.

  read more »

Tor Browser 5.5a3 is released

A new alpha Tor Browser release is available for download in the 5.5a3 distribution directory and on the alpha download page.

This release features important security updates to Firefox.

Beginning with this alpha version Tor Browser is available in Japanese as well. In addition to that it contains usability improvements for our font fingerprinting defense, a better notification of Tor Browser changes after an update and regression fixes that were caused by our switch to ESR 38 back in August.

Here is the complete changelog since 5.5a2:

  • All Platforms
    • Update Firefox to 38.3.0esr
    • Update Torbutton to 1.9.4
      • Bug 16937: Don't translate the hompepage/spellchecker dictionary string
      • Bug 16735: about:tor should accommodate different fonts/font sizes
      • Bug 16887: Update intl.accept_languages value
      • Bug 15493: Update circuit display on new circuit info
      • Bug 16797: brandShorterName is missing from brand.properties
      • Translation updates
    • Bug 10140: Add new Tor Browser locale (Japanese)
    • Bug 17102: Don't crash while opening a second Tor Browser
    • Bug 16983: Isolate favicon requests caused by the tab list dropdown
    • Bug 13512: Load a static tab with change notes after an update
    • Bug 16937: Remove the en-US dictionary from non en-US Tor Browser bundles
    • Bug 7446: Tor Browser should not "fix up" .onion domains (or any domains)
    • Bug 16837: Disable Firefox Hotfix updates
    • Bug 16855: Allow blobs to be downloaded on first-party pages (fixes mega.nz)
    • Bug 16781: Allow saving pdf files in built-in pdf viewer
    • Bug 16842: Restore Media tab on Page information dialog
    • Bug 16727: Disable about:healthreport page
    • Bug 16783: Normalize NoScript default whitelist
    • Bug 16775: Fix preferences dialog with security slider set to "High"
    • Bug 13579: Update download progress bar automatically
    • Bug 15646: Reduce keyboard layout fingerprinting in KeyboardEvent
    • Bug 17046: Event.timeStamp should not reveal startup time
    • Bug 16872: Fix warnings when opening about:downloads
    • Bug 17097: Fix intermittent crashes when using the print dialog
  • Windows
    • Bug 16906: Fix Mingw-w64 compilation breakage
    • Bug 16707: Allow more system fonts to get used on Windows
  • OS X
    • Bug 16910: Update copyright year in OS X bundles
    • Bug 16707: Allow more system fonts to get used on OS X
  • Linux
    • Bug 16672: Don't use font whitelisting for Linux users

Update: It seems claiming that our builds are reproducible with LXC as well now was a bit premature (see bug 12240 for details). Thus, this part got removed from the changelog.

Tor Browser 5.0.3 is released

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

This release features important security updates to Firefox.

We fixed a number of regressions from our switch to ESR 38 back in August and reduced keyboard layout fingerprinting to mention just some highlights.

These and all the other changes can be found in the complete changelog since 5.0.2:

  • All Platforms
    • Update Firefox to 38.3.0esr
    • Update Torbutton to 1.9.3.4
      • Bug 16887: Update intl.accept_languages value
      • Bug 15493: Update circuit display on new circuit info
      • Bug 16797: brandShorterName is missing from brand.properties
      • Bug 14429: Make sure the automatic resizing is disabled
      • Translation updates
    • Bug 7446: Tor Browser should not "fix up" .onion domains (or any domains)
    • Bug 16837: Disable Firefox Hotfix updates
    • Bug 16855: Allow blobs to be downloaded on first-party pages (fixes mega.nz)
    • Bug 16781: Allow saving pdf files in built-in pdf viewer
    • Bug 16842: Restore Media tab on Page information dialog
    • Bug 16727: Disable about:healthreport page
    • Bug 16783: Normalize NoScript default whitelist
    • Bug 16775: Fix preferences dialog with security slider set to "High"
    • Bug 13579: Update download progress bar automatically
    • Bug 15646: Reduce keyboard layout fingerprinting in KeyboardEvent
    • Bug 17046: Event.timeStamp should not reveal startup time
    • Bug 16872: Fix warnings when opening about:downloads
    • Bug 17097: Fix intermittent crashes when using the print dialog
  • Windows
    • Bug 16906: Fix Mingw-w64 compilation breakage
  • OS X
    • Bug 16910: Update copyright year in OS X bundles

Learning more about the GFW's active probing system

This blog post is also available in Chinese, translated by our friends from GreatFire.org.

Roya, David, Nick, nweaver, Vern, and I just finished a research project in which we revisited the Great Firewall of China's (GFW) active probing system. This system was brought to life several years ago to reactively probe and block circumvention proxies, including Tor. You might remember an earlier blog post that gave us some first insight into how the active probing system works. Several questions, however, remained. For example, we were left wondering what the system's physical infrastructure looked like. Is the GFW using dedicated machines behind their thousands of probing IP addresses? Does the GFW even "own" all these IP addresses? Rumour had it that the GFW was hijacking IP addresses for a short period of time, but there was no conclusive proof. As a result, we teamed up and set out to answer these, and other questions.

Because this was a network measurement project, we started by compiling datasets. We created three datasets, comprising hours (a Sybil-like experiment to attract many probes), months (an experiment to measure reachability for clients in China), and even years (log files of a long-established server) worth of active probing data. Together, these datasets allow us to look at the GFW's active probing system from different angles, illuminating aspects we wouldn't be able to observe with just a single dataset. We are able to share two of our datasets, so you are very welcome to reproduce our work, or do your own analysis.

We now want to give you an overview of our most interesting findings.

  • Generally, once a bridge is detected and blocked by the GFW, it remains blocked. But does this mean that the bridge is entirely unreachable? We measured the blocking effectiveness by continuously making a set of virtual private systems in China connect to a set of bridges under our control. We found that every 25 hours, for a short period of time, our Tor clients in China were able to connect to our bridges. This is illustrated in the diagram shown below. Every point represents one connection attempt, meaning that our client in China was trying to connect to our bridge outside of China. Note the curious periodic availability pattern for both Unicom and CERNET (the two ISPs in China we measured from). Sometimes, network security equipment goes into "fail open" mode while it updates its rule set, but it is not clear if this is happening here.

  • We were able to find patterns in the TCP headers of active probes that suggest that all these thousands of IP addresses are, in fact, controlled by a single source. Check out the initial sequence number (ISN) pattern in the diagram below. It shows the value of ISNs (y-axis) over time (x-axis). Every point in the graph represents the SYN segment of one active probing connection. If all probing connections would have come from independent computers, we would have expected a random distribution of points. That's because ISNs are typically chosen randomly to protect against off-path attackers. Instead, we see a clear linear pattern across IP addresses. We believe that active probes derive their ISN from the current time.

  • We discovered that Tor is not the only victim of active probing attacks; the GFW is targeting other circumvention systems, namely SoftEther and GoAgent. This highlights the modular nature of the active probing system. It appears to be easy for GFW engineers to add new probing modules to react to emerging, proxy-based circumvention tools.
  • The GFW is able to (partially) speak the vanilla Tor protocol, obfs2, and obfs3 to probe bridges. Interestingly, node-Tor—a JavaScript implementation of the Tor protocol—is immune to active probing because it implements the Tor protocol differently, which seems to confuse active probes. We were also able to resist active probes by modifying a bridge of ours to ignore old VERSIONS Tor cells. This is unlikely to be a sustainable circumvention technique, though.
  • Back in 2012, the system worked in 15-minute-queues. These days, it seems to be able to scan bridges in real-time. On average, it takes only half a second after a bridge connection for an active probe to show up.
  • Using a number of traceroute experiments, we could show that the GFW's sensor is stateful and seems unable to reassemble TCP streams.

Luckily, we now have several pluggable transports that can defend against active probing. ScrambleSuit and its successor, obfs4, defend against probing attacks by relying on a shared secret that is distributed out of band. Meek tunnels traffic over cloud infrastructure, which does not prevent active probing, but greatly increases collateral damage when blocked. While we keep developing and maintaining circumvention tools, we need to focus more on usability. A powerful and carefully-engineered circumvention tool is of little use if folks find it too hard to use. That's why projects like the UX sprint are so important.

Finally, you can find our research paper as well as our datasets and code on our project page. And don't hesitate to get in touch with us if you have any questions or feedback!

Tor Weekly News — September 10th, 2015

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

Introducing the tor-teachers list

Just as the the Tor network itself grows and evolves through the efforts of volunteer relay operators in numerous countries, information about how and why users should make use of the protections that Tor offers is also spread by an informal network of teachers and activists working in many different communities around the world. Tor talks and trainings are often a feature of free public privacy events like cryptoparties, as well as Internet security workshops put on by groups and organizations especially in need of online privacy in their activities.

Until now, Tor teachers have had no central meeting-place to share advice, compare experiences, or make future plans, so Alison Macrina and Nima Fatemi this week announced the creation of the tor-teachers mailing list. According to Alison, whose Library Freedom Project is itself engaged in teaching Tor and other online privacy tools to librarians and library patrons across America (and beyond), “this list is for all the awesome people around the world who are teaching Tor to their communities, who want to work collectively with other teachers of Tor to support each other, build community, and make our work even better”. Topics of discussion will range from “visionary stuff” like the philosophical underpinnings of the right to free expression and inquiry, to more prosaic Tor-related questions such as “how to use the darn thing” and how best to convey this to users from all backgrounds.

If this sounds like the sort of thing you either would like to be doing or are already an old hand at, you are most welcome to join! Visit the list-info page to sign up. As with almost all of Tor’s mailing lists, messages are publicly visible and archived, so you can take a look at current discussions to see if you want to get involved. Good luck!

Miscellaneous news

Luke Millanta announced the launch of OnionView, a web service which utilizes Tor relay data, gathered using the Onionoo network status protocol, to plot the location of active Tor nodes onto an interactive map of the world. Created in collaboration with Tor’s Measurement team, OnionView’s relay database is updated every thirty minutes to help ensure map accuracy. Join the developers in the #tor-dev IRC channel to become involved in future work on OnionView.


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

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 Weekly News — September 4th, 2015

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

Tor Browser 5.0.2 and 5.5a2 are out

The Tor Browser team announced new stable and alpha releases of the privacy-preserving web browser. Version 5.0.2 fixes a bug that was causing the browser’s launcher icons in the Ubuntu Unity and GNOME desktops to be duplicated, and includes a newer version of the NoScript add-on. Version 5.5a2 incorporates these updates along with another small crash bug fix from the stable series.

Both new releases include important security updates to their respective Firefox versions, so please ensure you upgrade as soon as possible. If you are already running a recent Tor Browser, it has probably updated itself already; if not, head to the project page to download your copy now.

Final reports from two Summer of Privacy students

Two of the developers participating in Tor’s first-ever Summer of Privacy coding season, Jesse Victors and Donncha O’Cearbhaill, submitted their final progress reports after months of intensive development.

Jesse’s DNS-like naming system for onion services is already in a testable state. “All of the infrastructure for OnioNS is in place”, and while a few protocols are still to be finished, “the client-side and HS-side software is pretty reliable and stable at this point”, with support for Debian, Ubuntu, Mint, and Fedora. Development will continue into the future, and “once the OnioNS software is fully ready, no modifications to Tor should be necessary to merge OnioNS into the Tor network”.

Donncha’s project, the onion service load-balancing manager OnionBalance, has also seen one testing release, and the next steps in development are to package the software for Debian, clarify the documentation, and implement “smartcard / HSM support master service key storage and signing”. “I’ll continue developing OnionBalance so that if possible, it can facilitate some form of load balancing and redundancy with next-gen hidden services”.

Congratulations to Jesse and Donncha on getting their innovative projects to this stage, and thanks to the mentors and coordinators who have made the Summer of Privacy a success. The southern-hemisphere development timetable is still ongoing, however, so stay tuned for updates from Israel and Cristóbal Leiva on their TSoP projects.

Should cloud-based Tor relays be rejected?

Observing that “we sometimes see attacks from relays that are hosted on cloud platforms”, Philipp Winter investigated the actual benefit to the Tor network that these relays provide. He found that in an average consensus from July 2015, “cloud-hosted relays contributed only around 0.8% of bandwidth” (with the caveat that “this is just a lower bound”). Rejecting such relays from the consensus might force attackers to jump through more hoops, but would mean “obtaining the netblocks that are periodically published by all three (and perhaps more) cloud providers”.

Tim Wilson-Brown (teor) wondered about the effect this might have on Tor developers and researchers who would like to use cloud-based relays, while nusenu requested that any rejection be publicly documented “so volunteers don’t waste their time and money setting up blacklisted relays”.

Miscellaneous news

Karsten Loesing announced version 2.6 of Onionoo, the Tor network data observatory. This release adds two new relay family-related fields to details documents that, together with the “effective_family” field introduced in version 2.4, replace the older “family” field, which is now deprecated. These new fields support different family-mapping use-cases that may be required by Tor network tools such as Atlas, Globe, and Roster. “The current ‘family’ field will stay available until Atlas and Globe are updated. If I should also wait for other clients to be updated, please let me know.”

After several television appearances over the past few years, Tor made its literary debut last month in the fourth installment of the late Stieg Larsson’s Millennium series. A warm Tor community welcome to Lisbeth Salander — though a subscription to Tor Weekly News might clear up some of her misconceptions


This issue of Tor Weekly News has been assembled by 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 Weekly News — August 30th, 2015

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

Hash visualizations to protect against onion phishing

Unlike URLs on the non-private web, the .onion addresses used by Tor hidden services are not handed out by any central authority — instead, they are derived by the hidden services themselves based on their cryptographic key information. This means that they are typically quite hard for humans to remember, unless the hidden service operator — whether by chance or by making repeated attempts — hits upon a memorable string, as in the case of Facebook’s hidden service.

“The problem”, writes George Kadianakis, is that due to these user-unfriendly strings, “many people don’t verify the whole onion address, they just trust the onion link or verify the first few characters. This is bad since an attacker can create a hidden service with a similar onion address very easily”, then trick users into visiting that address instead for a variety of malicious purposes. This species of attack that has already been seen in the wild. After discussions with other researchers in this area, George drew up a proposal to incorporate visual information into the verification process: “So when TBB connects to a hidden service, it uses the onion address to generate a randomart or key poem and makes them available for the user to examine.”

As with all new development proposals, however, there are many unanswered questions. What kind of visualization would work best? Should there also be an auditory component, like a randomly-generated tune? How should the feature be made available to users without confusing those who have no idea what it is or why it’s needed? In short, “Some real UX research needs to be done here, before we decide something terrible.”

If you have clear and constructive feedback to offer on this unusual but important proposal, please send it to the tor-dev mailing list.

Tor-enabled Debian mirrors

Richard Hartmann, Peter Palfrader, and Jonathan McDowell have set up the first official onion service mirrors of the Debian operating system’s software package infrastructure. This means that it is now possible to update your Debian system without the update information or downloaded packages leaving the Tor network at all, preventing a network adversary from discovering information about your system. A follow-up post by Richard includes guidance on using apt-transport-tor with the new mirrors.

These services are only the first in what should hopefully become a fully Tor-enabled system mirroring “the complete package lifecycle, package information, and the website”. “This service is not redundant, it uses a key which is stored on the local drive, the .onion will change, and things are expected to break”, wrote Richard, but if you are interested in trying out the new infrastructure, see the write-ups for further information.

Miscellaneous news

David Fifield announced that his 17-minute PETS talk on the theory and practice of “domain fronting”, which is the basis for Tor’s innovative and successful meek pluggable transport, is now available to view online.

Arturo Filastò announced that registration for ADINA15, the upcoming OONI hackathon at the Italian Parliament in Rome, is now open. If you’re interested in hacking on internet censorship data in this rarified location, with the possibility of “interesting prizes” for the winning teams, see Arturo’s mail for the full details.

Arturo also sent out the OONI team’s July status report, while Tor Summer of Privacy progress updates were submitted by Israel Leiva, Cristobal Leiva, and Jesse Victors.

Fabio Pietrosanti issued an open call for developers interested in working on GlobaLeaks, the open-source anonymous whistleblowing software. “Are you interested in making the world a better place by putting your development skills to use in a globally used free software project? Do you feel passionate about using web technologies for developing highly usable web applications?” If so, please see Fabio’s message for more information.

News from Tor StackExchange

saurav created a network using the Shadow simulator and started with 40 guard and 40 exit nodes. After a simulation was performed, another 40/40 nodes were added. saurav then noticed that the more recent nodes had a higher probability of being selected. Can you explain why this is the case? The users of Tor’s Q&A page will be happy to know.


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

Syndicate content Syndicate content