Archive

Tor Browser 4.0.1 is released

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

Most notably, Tor Browser 4.0.1 fixes a crash bug affecting many users on Windows (see: bug 13443 for the details). Furthermore, the latest stable version of Tor (0.2.5.10) is included and a bug in our updater code got fixed.

This is not a security update, and we will not be deploying update notification or automatic upgrades for all platforms for this release. We may provide automatic updates just for Windows users later in the week, but we are hesitant to do this immediately due to Bug 13594.

Here is the changelog since 4.0:

  • All Platforms
    • Update Tor to 0.2.5.10
    • Update NoScript to 2.6.9.3
      • Bug 13301: Prevent extensions incompatibility error after upgrades
      • Bug 13460: Fix MSVC compilation issue
  • Windows
    • Bug 13443: Disable DirectShow to prevent crashes on many sites
    • Bug 13091: Make app name "Tor Browser" instead of "Tor"

Facebook, hidden services, and https certs

Today Facebook unveiled its hidden service that lets users access their website more safely. Users and journalists have been asking for our response; here are some points to help you understand our thinking.

Part one: yes, visiting Facebook over Tor is not a contradiction

I didn't even realize I should include this section, until I heard from a journalist today who hoped to get a quote from me about why Tor users wouldn't ever use Facebook. Putting aside the (still very important) questions of Facebook's privacy habits, their harmful real-name policies, and whether you should or shouldn't tell them anything about you, the key point here is that anonymity isn't just about hiding from your destination.

There's no reason to let your ISP know when or whether you're visiting Facebook. There's no reason for Facebook's upstream ISP, or some agency that surveils the Internet, to learn when and whether you use Facebook. And if you do choose to tell Facebook something about you, there's still no reason to let them automatically discover what city you're in today while you do it.

Also, we should remember that there are some places in the world that can't reach Facebook. Long ago I talked to a Facebook security person who told me a fun story. When he first learned about Tor, he hated and feared it because it "clearly" intended to undermine their business model of learning everything about all their users. Then suddenly Iran blocked Facebook, a good chunk of the Persian Facebook population switched over to reaching Facebook via Tor, and he became a huge Tor fan because otherwise those users would have been cut off. Other countries like China followed a similar pattern after that. This switch in his mind between "Tor as a privacy tool to let users control their own data" to "Tor as a communications tool to give users freedom to choose what sites they visit" is a great example of the diversity of uses for Tor: whatever it is you think Tor is for, I guarantee there's a person out there who uses it for something you haven't considered.

Part two: we're happy to see broader adoption of hidden services

I think it is great for Tor that Facebook has added a .onion address. There are some compelling use cases for hidden services: see for example the ones described at using Tor hidden services for good, as well as upcoming decentralized chat tools like Ricochet where every user is a hidden service, so there's no central point to tap or lean on to retain data. But we haven't really publicized these examples much, especially compared to the publicity that the "I have a website that the man wants to shut down" examples have gotten in recent years.

Hidden services provide a variety of useful security properties. First — and the one that most people think of — because the design uses Tor circuits, it's hard to discover where the service is located in the world. But second, because the address of the service is the hash of its key, they are self-authenticating: if you type in a given .onion address, your Tor client guarantees that it really is talking to the service that knows the private key that corresponds to the address. A third nice feature is that the rendezvous process provides end-to-end encryption, even when the application-level traffic is unencrypted.

So I am excited that this move by Facebook will help to continue opening people's minds about why they might want to offer a hidden service, and help other people think of further novel uses for hidden services.

Another really nice implication here is that Facebook is committing to taking its Tor users seriously. Hundreds of thousands of people have been successfully using Facebook over Tor for years, but in today's era of services like Wikipedia choosing not to accept contributions from users who care about privacy, it is refreshing and heartening to see a large website decide that it's ok for their users to want more safety.

As an addendum to that optimism, I would be really sad if Facebook added a hidden service, had a few problems with trolls, and decided that they should prevent Tor users from using their old https://www.facebook.com/ address. So we should be vigilant in helping Facebook continue to allow Tor users to reach them through either address.

Part three: their vanity address doesn't mean the world has ended

Their hidden service name is "facebookcorewwwi.onion". For a hash of a public key, that sure doesn't look random. Many people have been wondering how they brute forced the entire name.

The short answer is that for the first half of it ("facebook"), which is only 40 bits, they generated keys over and over until they got some keys whose first 40 bits of the hash matched the string they wanted.

Then they had some keys whose name started with "facebook", and they looked at the second half of each of them to pick out the ones with pronouncable and thus memorable syllables. The "corewwwi" one looked best to them — meaning they could come up with a story about why that's a reasonable name for Facebook to use — so they went with it.

So to be clear, they would not be able to produce exactly this name again if they wanted to. They could produce other hashes that start with "facebook" and end with pronouncable syllables, but that's not brute forcing all of the hidden service name (all 80 bits).

For those who want to explore the math more, read about the "birthday attack". And for those who want to learn more (please help!) about the improvements we'd like to make for hidden services, including stronger keys and stronger names, see hidden services need some love and Tor proposal 224.

Part four: what do we think about an https cert for a .onion address?

Facebook didn't just set up a hidden service. They also got an https certificate for their hidden service, and it's signed by Digicert so your browser will accept it. This choice has produced some feisty discussions in the CA/Browser community, which decides what kinds of names can get official certificates. That discussion is still ongoing, but here are my early thoughts on it.

In favor: we, the Internet security community, have taught people that https is necessary and http is scary. So it makes sense that users want to see the string "https" in front of them.

Against: Tor's .onion handshake basically gives you all of that for free, so by encouraging people to pay Digicert we're reinforcing the CA business model when maybe we should be continuing to demonstrate an alternative.

In favor: Actually https does give you a little bit more, in the case where the service (Facebook's webserver farm) isn't in the same location as the Tor program. Remember that there's no requirement for the webserver and the Tor process to be on the same machine, and in a complicated set-up like Facebook's they probably shouldn't be. One could argue that this last mile is inside their corporate network, so who cares if it's unencrypted, but I think the simple phrase "ssl added and removed here" will kill that argument.

Against: if one site gets a cert, it will further reinforce to users that it's "needed", and then the users will start asking other sites why they don't have one. I worry about starting a trend where you need to pay Digicert money to have a hidden service or your users think it's sketchy — especially since hidden services that value their anonymity could have a hard time getting a certificate.

One alternative would be to teach Tor Browser that https .onion addresses don't deserve a scary pop-up warning. A more thorough approach in that direction is to have a way for a hidden service to generate its own signed https cert using its onion private key, and teach Tor Browser how to verify them — basically a decentralized CA for .onion addresses, since they are self-authenticating anyway. Then you don't have to go through the nonsense of pretending to see if they could read email at the domain, and generally furthering the current CA model.

We could also imagine a pet name model where the user can tell her Tor Browser that this .onion address "is" Facebook. Or the more direct approach would be to ship a bookmark list of "known" hidden services in Tor Browser — like being our own CA, using the old-fashioned /etc/hosts model. That approach would raise the political question though of which sites we should endorse in this way.

So I haven't made up my mind yet about which direction I think this discussion should go. I'm sympathetic to "we've taught the users to check for https, so let's not confuse them", but I also worry about the slippery slope where getting a cert becomes a required step to having a reputable service. Let us know if you have other compelling arguments for or against.

Part five: what remains to be done?

In terms of both design and security, hidden services still need some love. We have plans for improved designs (see Tor proposal 224) but we don't have enough funding and developers to make it happen. We've been talking to some Facebook engineers this week about hidden service reliability and scalability, and we're excited that Facebook is thinking of putting development effort into helping improve hidden services.

And finally, speaking of teaching people about the security features of .onion sites, I wonder if "hidden services" is no longer the best phrase here. Originally we called them "location-hidden services", which was quickly shortened in practice to just "hidden services". But protecting the location of the service is just one of the security features you get. Maybe we should hold a contest to come up with a new name for these protected services? Even something like "onion services" might be better if it forces people to learn what it is.

A new alpha series begins: Tor 0.2.6.1-alpha is released

Tor 0.2.6.1-alpha is the first release in the Tor 0.2.6.x series. It includes numerous code cleanups and new tests, and fixes a large number of annoying bugs. Out-of-memory conditions are handled better than in 0.2.5, pluggable transports have improved proxy support, and clients now use optimistic data for contacting hidden services. Also, we are now more robust to changes in what we consider a parseable directory object, so that tightening restrictions does not have a risk of introducing infinite download loops.

This is the first alpha release in a new series, so expect there to be bugs. Users who would rather test out a more stable branch should stay with 0.2.5.x for now.

This announcement is for the source release only; I'd expect that compiled packages for several platforms should be available over the next several days.

Changes in version 0.2.6.1-alpha - 2014-10-30
  • New compiler and system requirements:
    • Tor 0.2.6.x requires that your compiler support more of the C99 language standard than before. The 'configure' script now detects whether your compiler supports C99 mid-block declarations and designated initializers. If it does not, Tor will not compile.

      We may revisit this requirement if it turns out that a significant number of people need to build Tor with compilers that don't bother implementing a 15-year-old standard. Closes ticket 13233.

    • Tor no longer supports systems without threading support. When we began working on Tor, there were several systems that didn't have threads, or where the thread support wasn't able to run the threads of a single process on multiple CPUs. That no longer holds: every system where Tor needs to run well now has threading support. Resolves ticket 12439.

  read more »

Tor Weekly News — October 29th, 2014

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

Tor 0.2.5.10 is out

The 0.2.5.x branch of the core Tor software hit stable, with the release of 0.2.5.10. As Nick Mathewson explained, there have been no changes since last week’s 0.2.5.9-rc release, and the new features will be familiar to readers of Tor Weekly News over the past year of development, but highlights include “improved denial-of-service resistance for relays, new compiler hardening options, and a system-call sandbox for hardened installations on Linux”, as well as improvements to transparent proxying, building and testing, pluggable transport usability, and much more.

This release means that Tor versions in the 0.2.3.x series, which has “received no patches or attention for some while” and “accumulated many known flaws”, are now deprecated. Relay operators running these versions must upgrade as soon as possible, or risk having their relays rejected from the network in the near future.

Please see Nick’s release announcement for the full changelog, and download your copy of the 0.2.5.10 source code from the distribution directory or a prebuilt package from your usual repositories.

Miscellaneous news

Jacob Appelbaum announced version 0.1.3 of TorBirdy, a torifying extension for the Thunderbird email client. Among other things, this release fixes the recently-reported “wrote:” bug, disables the automatic downloading of messages from POP3 accounts, and ensures that draft messages for IMAP accounts are stored on the local system rather than sent over the network. However, as Jacob wrote, “it’s still experimental”, so “use at your own risk”. See the release announcement for a full changelog.

Anthony G. Basile announced version 20141022 of tor-ramdisk, the micro Linux distribution whose only purpose is to host a Tor server in an environment that maximizes security and privacy. This release addresses the recent POODLE attack with updates to Tor and OpenSSL, and also upgrades the Linux kernel.

Yawning Angel called for testing of the revamped tor-fw-helper, a tool that automates the port forwarding required (for example) by the flash proxy pluggable transport. Please see Yawning’s message for full testing instructions and other important information: “Questions, Comments, Feedback appreciated”.

On the Tor blog, Andrew Lewman responded to the abuse of Tor by creators of so-called “ransomware”, or malware that tries to restrict access to users’ files unless a ransom is paid; these extortionists sometimes ask their victims to install Tor software in order to communicate with them over a hidden service, leading users to the mistaken belief that The Tor Project is somehow involved. As Andrew wrote, this software “is unrelated to The Tor Project. We didn’t produce it, and we didn’t ask to be included in the criminal infection of any computer.” Users may find the information provided by the BBC and Bleeping Computer to be helpful in resolving the problem.

Josh Pitts posted an analysis of apparently malicious behavior by a Tor relay that was modifying binary files downloaded over Tor circuits in which it was the exit node. As Roger Dingledine responded, “we’ve now set the BadExit flag on this relay, so others won’t accidentally run across it”.

David Fifield pointed out “an apparent negative correlation between obfs3 users and vanilla users” in the Tor Metrics portal’s bridge user graphs and wondered what might be causing it.

News from Tor StackExchange

Dodo wants to run several hidden services (HTTP, XMPP, SSH etc.), but use just one onion address. Jobiwan explained that one can forward each port to a different service. Further information can be found at the configuration page for hidden services.

Rodney Hester proxies the DirPort of his relay and saw lots of requests to nonexistent URLs, of which the most prominent is the URL /tor/status/all.z, and asks where they are coming from. Do you have an answer? If so, please share it at Tor’s StackExchange site.


This issue of Tor Weekly News has been assembled by Lunar, qbi, Roger Dingledine, and Harmony.

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

Tor 0.2.5.10 is released! (and Tor 0.2.3.x is deprecated)

Tor 0.2.5.10 is the first stable release in the 0.2.5 series.

It adds several new security features, including improved denial-of-service resistance for relays, new compiler hardening options, and a system-call sandbox for hardened installations on Linux (requires seccomp2). The controller protocol has several new features, resolving IPv6 addresses should work better than before, and relays should be a little more CPU-efficient. We've added support for more OpenBSD and FreeBSD transparent proxy types. We've improved the build system and testing infrastructure to allow unit testing of more parts of the Tor codebase. Finally, we've addressed several nagging pluggable transport usability issues, and included numerous other small bugfixes and features mentioned below.

This release marks end-of-life for Tor 0.2.3.x; those Tor versions have accumulated many known flaws; everyone should upgrade.

Below we list all changes in 0.2.5.10 since the 0.2.4.x series; for a list of changes in individual alpha releases, see the ChangeLog. read more »

Changes in version 0.2.5.10 - 2014-10-24

TorBirdy 0.1.3 -- Our fourth beta release!

We are happy to announce the fourth beta release of TorBirdy: 0.1.3. All users are encouraged to upgrade as soon as possible, especially if you are using Thunderbird 31.

Notable changes in this release include:

0.1.3, 23 Oct 2014

* The default keyserver (hidden service) has been updated:
- hkp://qdigse2yzvuglcix.onion
* Show the Sender header in message pane (closes #10226)
* Draft messages on IMAP accounts are now saved locally (closes #10309)
* Restore preferences to the user's own defaults instead of Thunderbird's
(closes #10588)
* network.proxy.no_proxies_on is no longer set to "localhost, 127.0.0.1"
(thanks to Carsten N.)
* Disable automatic downloading of new messages for POP3 accounts
(closes #11188)
* Update the reply_header author behaviour (closes #13480)
* TorBirdy is now available in 31 languages:
- Arabic
- Catalan
- Czech
- Danish
- German
- Greek
- English (US)
- English (Great Britain)
- Spanish
- Basque
- French
- Hebrew
- Hungarian
- Indonesian
- Italian
- Korean
- Latvian
- Norwegian Bokmål
- Norwegian Nynorsk
- Punjabi
- Polish
- Portuguese
- Portuguese (Brazil)
- Romanian
- Russian
- Slovak
- Slovenian
- Serbian
- Swedish
- Turkish
- Ukrainian

We offer two ways of installing TorBirdy -- either by visiting our website (sig) or by visiting the Mozilla Add-ons page for TorBirdy. Please note that there may be a delay -- which can range from a few hours to days -- before the extension is reviewed by Mozilla and updated on the Add-ons page.

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 — October 22nd, 2014

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

Tor 0.2.5.9-rc is out

Nick Mathewson announced what is hopefully the final release candidate in the Tor 0.2.5 series. It contains two enhancements in response to the recent POODLE attack on OpenSSL, “even though POODLE does not affect Tor”, as well as a number of other miscellaneous improvements.

Upgrading is especially important for relay operators, as a remote crash is possible when older Tor versions are used with a version of OpenSSL released last week that was built with the “no-ssl3” flag.

As ever, you can download the source code from the distribution directory and packages should follow shortly.

Tor Browser 4.0 is out

Mike Perry announced a major release by the Tor Browser team. Version 4.0 of the secure and anonymous web browser brings several exciting new features to the stable series, including the meek censorship-circumvention tool, the secure updater, and a simplified Javascript enabling/disabling process in NoScript, all based on a customized Firefox ESR31. SSLv3 is also disabled, in response to the recent POODLE attack.

This release contains important security fixes, and all users should upgrade as soon as possible. Please note that the new directory structure means users cannot simply extract the new Tor Browser over their existing 3.6.6 directory, and must instead delete the old version entirely. The secure updater still requires manual activation in the “About Tor Browser” menu option, as its security will depend “on the specific CA that issued the www.torproject.org HTTPS certificate (Digicert)” until site-specific certificate pinning and signed update files are implemented. Furthermore, “we still need to improve meek’s performance to match other transports”, wrote Mike, “so adjust your expectations accordingly”.

See Mike’s post for further details and a full changelog, and get your copy of Tor Browser 4.0 from the distribution directory or the download page.

Tails 1.2 is out

The Tails team put out version 1.2 of the anonymizing live operating system. This release replaces the Iceweasel browser with “most of” the regular Tor Browser, and confines several important applications with AppArmor.

I2P will now, like Tor, be started upon network connection if activated with the “i2p” boot parameter, and must be used with the new dedicated I2P Browser. This is also the last Tails release to ship with the now-unmaintained TrueCrypt tool, but the Tails team has already documented the method for opening TrueCrypt volumes with cryptsetup. See the team’s announcement for a full list of changes in the new version.

This is an important security release and all users should upgrade as soon as possible. If you have a running Tails, you should be able to use the incremental updater; if your Tails drive was manually created, or you are a new user, head to the download page for more information.

Miscellaneous news

tagnaq warned users of TorBirdy, the torifying extension for the Thunderbird mail client, that a change in Thunderbird 31’s handling of the “reply_header_authorwrote” header means that the word “wrote”, translated into the user’s system language, may be inserted before quoted text when replying to emails, leaking the system language to recipients of replies if not removed. Jacob Appelbaum responded that a new release of TorBirdy addressing this and other issues was imminent.

Arturo Filastò announced the release of ooniprobe 1.1.2, containing “two new report entry keys, test_start_time and test_runtime”, and a fix for a bug that “led to ooniresources not working properly”.

evilaliv3 announced version 3.1.20 of tor2web, an HTTP proxy that enables access to hidden services without a Tor client, for users who do not require strong anonymity. As well as “some networking bugfixing and optimizations”, this release adds a “replace” mode for remotely-fetched blocklists in addition to “merge”, and a feature that allows different hostnames to be mapped to specific hidden services.

Karsten Loesing gave users of Onionoo a “one-month heads-up” that on or after November 15th, a change to the protocol will let the search parameter “accept base64-encoded fingerprints in addition to hex-encoded fingerprints, nicknames, and IP addresses.” These searches will also return relays whose base64-encoded fingerprints are a partial match for the search string. “If you’re fine with that, feel free to ignore this message and do nothing”, but if not, “you’ll have to filter out those relays locally”.

Following updates to the Tor Project’s website, Sebastian Hahn drew attention to a change in the steps necessary to run a website mirror. “Please ask if you run into any trouble, and thanks for providing a mirror!”

Inspired by “the Directory Authorities, the crappy experiment leading up to Black Hat, and the promise that one can recreate the Tor network in the event of some catastrophe”, Tom Ritter sent out a detailed report of issues he encountered while setting up his own Tor network using “full-featured independent tor daemons”, rather than a network simulator like Shadow or Chutney.

Cthulhu asked for assistance in overhauling the GoodBadISP page, which is the starting point for many relay operators around the world. If you have some time to spare, or know some ISPs not yet on the list, it would be greatly appreciated if they could be added to the page. This new effort to reach out to hosting providers could be of great value after years of what Roger Dingledine has described as a “slash and burn” agriculture model of operating Tor nodes.

Vladimir Martyanov started a discussion on the question of whether Tor developers should ensure that tor can still be built using compilers that do not support the C99 programming language standard, such as older versions of Microsoft Visual Studio.


This issue of Tor Weekly News has been assembled by Lunar, Cthulhu, Roger Dingledine, Karsten Loesing, 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 misused by criminals

Tor misused by criminals

Several people contacted The Tor Project recently because some software told them to install the Tor Browser to access a website. There is no affiliation between the criminals who wrote this software and Tor.

What happened here?

The computer is probably infected with what's called ransomware. This is a kind of malicious software which restricts access to the files and demands a ransom. In this case the authors of the ransomware CryptoLocker set up a website which is only reachable by using Tor. That is why people are thinking that the software is somehow related to The Tor Project.

In fact, CryptoLocker is unrelated to The Tor Project. We didn't produce it, and we didn't ask to be included in the criminal infection of any computer. We cannot help you with your infection. However, according to the BBC you may be able to decrypt your files for free. If not, Bleeping Computer can provide more information.

We, the people of Tor, are very sorry to hear that some individual misused the anonymity granted by our service. The vast majority of our users use Tor in a responsible way. Thank you for your understanding.

Syndicate content