Blogs

Tor Messenger 0.1.0b6 is released

We are pleased to announce another public beta release of Tor Messenger. This release features important security updates to Instantbird. All users are highly encouraged to upgrade.

Mozilla's ESR cycle

This release of Tor Messenger is the first release based on Mozilla's ESR cycle. As with Tor Browser, all future releases will continue to pair with this cycle.

Secure Updater

We are well aware of the current pain in upgrading Tor Messenger and are actively working towards porting Tor Browser's updater patches (#14388) so that keeping Tor Messenger up to date is as seamless and easy as possible. We continue to apologize for the inconvenience.

Before upgrading, back up your OTR keys

Before upgrading to the new release, you will need to back up your OTR keys or simply generate new ones. Please see the following steps to back them up.

Downloads

Please note that Tor Messenger is still in beta. The purpose of this release is to help test the application and provide feedback. At-risk users should not depend on it for their privacy and safety.

Linux (32-bit)

Linux (64-bit)

Windows

OS X (Mac)

sha256sums.txt
sha256sums.txt.asc

The sha256sums.txt file containing hashes of the bundles is signed with the key 0x6887935AB297B391 (fingerprint: 3A0B 3D84 3708 9613 6B84 5E82 6887 935A B297 B391).

Changelog

Here is the complete changelog since v0.1.0b5:

Tor Messenger 0.1.0b6 -- April 06, 2016

  • All Platforms
    • Use the THUNDERBIRD_45_0b3_RELEASE tag on mozilla-esr45
    • Use the THUNDERBIRD_45_0b3_RELEASE tag on comm-esr45
    • Bug 18533: Disable sending fonts or colors as part of messages
    • ctypes-otr
      • GH 68: Don't close notification bar until verification succeeds (patch by Elias Rohrer)
      • GH 71: Improve verifying from the fingerprint manager (patch by Vu Quoc Huy)
      • GH 72: Generate keys automatically after account creation (patch by Vu Quoc Huy)

Q and A with An East African Human Rights Activist

Can you tell us about your work?



I'm from East Africa. My background is in political science and I focus on the idea that consent in political systems helps build stability. I've been thinking about how to help communities circumvent or push back against information controls. When whistleblowers talk about corruption, there should be safe avenues of sharing that information without threatening their lives or their families.

How did you learn about Tor?

I didn't know that a web site could be blocked--I thought it was a problem with my computer--but then I saw in the comments section of a subreddit on Africa--it's mostly political--that some people could access a political web site. You want to know how they do it--you don't want to ask right there on reddit--so you research "access" "blocked" "website" as the key words.

This took me to Wikipedia and the article about circumvention tools. Then I learned about the routing through different servers to hide the source of a request.

I downloaded and installed Tor and it is slow--I thought it was a problem with my connection. But it worked! I could access websites that I could not access otherwise. Ethsat was blocked--a political and alternative media site that critiques the Ethiopian government and publishes info that is critical of government corruption.

[Ethsat is now blocked by CloudFlare and the site prohibits Firefox, which also means that it prohibits Tor. To circumvent this: Using the Tor browser, go to StartPage.com. Search for http://ethsat.com/, and click on the “proxy” link next to the search result. The disadvantage of this approach is that StartPage can see that a Tor IP address is visiting the website--but they won't know it's you. If you were to write your name on that website, you would de-anonymize yourself both to the website--and to StartPage. Thanks to Samdney for sharing this hack!
]

What was your reaction to CloudFlare CAPTCHAs when you first saw them?

You think the government is interfering or someone is playing around with it. You can't keep doing CAPTCHAs and they aren't working--you think something is broken here.

Doing one CAPTCHA is enough to identify if I'm human or not. [With repeated CAPTCHAs] I will run away from Tor. I won't use it. If CloudFlare really cares for security, then they should let people use Tor. Treat Tor like any other browser traffic.

What is your advice to other people in your country?

Use Tor -- For hundreds of thousands of people, it's the only way to access critical news.

Advice to other people like yourself?

You cannot purport to be fighting for society if you yourself are not secure. If you are not secure, you cannot secure others. The cobbler has no shoes. You are only as secure as your weakest browser. I most definitely would recommend Tor to frontline human rights defenders and journalists.

Any final thoughts?

Some people take it for granted that you can access any web site on the open Internet, but an Internet in which some web sites are blocked is not complete.

Other people are not as privileged--and Tor is giving them a fighting chance.

The Trouble with CloudFlare

Wednesday, CloudFlare blogged that 94% of the requests it sees from Tor are "malicious." We find that unlikely, and we've asked CloudFlare to provide justification to back up this claim. We suspect this figure is based on a flawed methodology by which CloudFlare labels all traffic from an IP address that has ever sent spam as "malicious." Tor IP addresses are conduits for millions of people who are then blocked from reaching websites under CloudFlare's system.

We're interested in hearing CloudFlare's explanation of how they arrived at the 94% figure and why they choose to block so much legitimate Tor traffic. While we wait to hear from CloudFlare, here's what we know:

1) CloudFlare uses an IP reputation system to assign scores to IP addresses that generate malicious traffic. In their blog post, they mentioned obtaining data from Project Honey Pot, in addition to their own systems. Project Honey Pot has an IP reputation system that causes IP addresses to be labeled as "malicious" if they ever send spam to a select set of diagnostic machines that are not normally in use. CloudFlare has not described the nature of the IP reputation systems they use in any detail.

2) External research has found that CloudFlare blocks at least 80% of Tor IP addresses, and this number has been steadily increasing over time.

3) That same study found that it typically took 30 days for an event to happen that caused a Tor IP address to acquire a bad reputation and become blocked, but once it happens, innocent users continued to be punished for it for the duration of the study.

4) That study also showed a disturbing increase over time in how many IP addresses CloudFlare blocked without removal. CloudFlare's approach to blocking abusive traffic is incurring a large amount of false positives in the form of impeding normal traffic, thereby damaging the experience of many innocent Tor and non-Tor Internet users, as well as impacting the revenue streams of CloudFlare's own customers by causing frustrated or blocked users to go elsewhere.

5) A report by CloudFlare competitor Akamai found that the percentage of legitimate e-commerce traffic originating from Tor IP addresses is nearly identical to that originating from the Internet at large. (Specifically, Akamai found that the "conversion rate" of Tor IP addresses clicking on ads and performing commercial activity was "virtually equal" to that of non-Tor IP addresses).

CloudFlare disagrees with our use of the word "block" when describing its treatment of Tor traffic, but that's exactly what their system ultimately does in many cases. Users are either blocked outright with CAPTCHA server failure messages, or prevented from reaching websites with a long (and sometimes endless) loop of CAPTCHAs, many of which require the user to understand English in order to solve correctly. For users in developing nations who pay for Internet service by the minute, the problem is even worse as the CAPTCHAs load slowly and users may have to solve dozens each day with no guarantee of reaching a particular site. Rather than waste their limited Internet time, such users will either navigate away, or choose not to use Tor and put themselves at risk.

Also see our new fact sheet about CloudFlare and Tor: https://people.torproject.org/~lunar/20160331-CloudFlare_Fact_Sheet.pdf

Tor 0.2.8.2-alpha is released

Tor 0.2.8.2-alpha has been released! You can download the source from the Tor website. Packages should be available over the next week or so.

Tor 0.2.8.2-alpha is the second alpha in its series. It fixes numerous bugs in earlier versions of Tor, including some that prevented authorities using Tor 0.2.7.x from running correctly. IPv6 and directory support should also be much improved.

REMEMBER: This is an alpha release. Expect a lot of bugs. You should only run this release if you're willing to find bugs and report them.

Changes in version 0.2.8.2-alpha - 2016-03-28

  • New system requirements:
    • Tor no longer supports versions of OpenSSL with a broken implementation of counter mode. (This bug was present in OpenSSL 1.0.0, and was fixed in OpenSSL 1.0.0a.) Tor still detects, but no longer runs with, these versions.
    • Tor no longer attempts to support platforms where the "time_t" type is unsigned. (To the best of our knowledge, only OpenVMS does this, and Tor has never actually built on OpenVMS.) Closes ticket 18184.
    • Tor now uses Autoconf version 2.63 or later, and Automake 1.11 or later (released in 2008 and 2009 respectively). If you are building Tor from the git repository instead of from the source distribution, and your tools are older than this, you will need to upgrade. Closes ticket 17732.
  • Major bugfixes (security, pointers):
    • Avoid a difficult-to-trigger heap corruption attack when extending a smartlist to contain over 16GB of pointers. Fixes bug 18162; bugfix on 0.1.1.11-alpha, which fixed a related bug incompletely. Reported by Guido Vranken.

  read more »

OONI Explorer: Censorship and other Network Anomalies Around the World

Today the Open Observatory of Network Interference (OONI) team is pleased to announce the public beta release of OONI Explorer: a global map of more than 8.5 million network measurements which have been collected across 91 countries around the world over the last 3 years.

OONI is based on 15 free software tests which are designed to measure the following:

  • Blocking of websites
  • Detection of systems responsible for censorship, surveillance and manipulation
  • Reachability of Tor, proxies, VPNs, and sensitive domains

These tests have been run across 398 different vantage points by volunteers around the world since 2012. The OONI Explorer announced today provides a location to interact and - dare we say - explore all of the collected measurements.

Key Findings

Some of the highlights in the data:

1. Confirmed cases of censorship in 9 countries

Multiple HTTP request tests were run around the world and based on our heuristics, we were able to detect block pages in 9 countries: Iran, Saudi Arabia, Turkey, Greece, China, Russia, India, Indonesia and Sudan.

Blocked websites include media, gambling and over-the-counter money exchanges. In Greece, for example, all of the tested ISPs employed DNS hijacking to block such websites, with the exception of Vodafone that also used Deep Packet Inspection. OONI tests in Turkey illustrate that 62 websites were blocked, including piratebay.com, livescore.com and 4shared.com, possibly under Law No. 5651 on the ‘Regulation of Publications on the Internet and Suppression of Crimes Committed by means of Such Publication’. Notably, 362 blocked websites were detected as blocked in Iran and 50 in Saudi Arabia, including arabtimes.com, mossad.gov.il and anonym.to, a URL shortening service with privacy properties.

Some of our tests for domains were focused on specific websites which were rumored or reported to be blocked. In January 2015, for example, the Government of India ordered the blocking of 32 websites under Section 69A of the Information Technology Act, 2000, and under the Information Technology (Procedures and Safeguards for Blocking of Access of Information by Public) Rules, 2009. Following these reports, OONI tests run on those websites were able to confirm that 23 of those websites were in fact blocked in the network that was tested, including websites such as pastebin.com, dailymotion.com and archive.org.

Leading up to the 2016 general elections in Uganda, OONI volunteers ran HTTP request tests in response to reports that Facebook and Twitter were being blocked. We did not detect block pages, but we did detect general network anomalies which indicate that it's likely the case that Ugandan ISPs were blocking some requests, but not others. It is also possible that Facebook and Twitter were only blocked in specific networks, and not countrywide.

2. Network anomalies in 71 countries

Out of the 91 countries with reported data, network anomalies were detected in 71 of them.

“Network anomalies” and “network interferences” are broad terms that we use to describe symptoms of censorship through the manipulation of internet traffic. These anomalies can take many forms, including connectivity failures, timeouts and unusual slowness, or unexpected error messages.

Not all HTTP request tests allow us to conclusively know that interference has occurred, because not all interference looks like a clear block page. Sometimes, censorship is hidden as connection failures instead. To gain confidence in detecting this type of interference, we can look at repeated failures to websites that are known to be operating normally. In Cuba, for example, it is interesting to see that while no block pages were detected, HTTP requests to cubafreepress.org failed multiple times.

Symptoms of traffic manipulation were detected in multiple countries around the world through HTTP invalid request line and HTTP header field manipulation tests, which look for middle boxes: network equipment that intercept and sometimes alter the traffic passing through them. Multiple HTTP invalid request line tests run in Vietnam from 2013 to 2015 triggered errors and indicate that middle boxes were regularly observing the traffic in the country. Similarly, many HTTP invalid request line tests in Pakistan and elsewhere indicate the presence of software which is capable of traffic manipulation.

3. Blue Coat, Squid and Privoxy detected in 11 countries

Transparent HTTP proxies can be used inside of small and large networks for various purposes: to intercept the web traffic of users, to implement caching or to speed up requests for commonly visited websites.

Through OONI tests we detected 3 different types of proxy technology: Blue Coat, Squid and Privoxy. Blue Coat Systems is a US security and networking solutions provider which has been called out for selling network appliances capable of filtering, censorship, and surveillance to governments with poor human rights records. Its presence, along with Squid and Privoxy, has been reported in the networks of 11 countries: USA, Canada, Portugal, Spain, Italy, the Netherlands, Switzerland, Moldova, Iraq, Myanmar and Uganda. It remains unclear though whether such middle boxes were actually used for online censorship, surveillance and traffic manipulation, or if they were merely used for caching purposes.

Furthermore, not all the detected instances of proxy technologies are necessarily deployed country-wide or even on an ISP level, but in some cases they might simply be running inside of the local network of the OONI user. It is interesting to note that the use of Blue Coat was first detected in Myanmar in 2012, but when another measurement was run from the same network in 2014 it was no longer detectable in the same way. This can either mean that it was removed or that it is no longer detectable.

Contribute to OONI Explorer

OONI Explorer was made possible by the growing community of volunteers around the world who have contributed to the project. You can contribute too by:

Happy OONI exploring!

A Statement from The Tor Project on Software Integrity and Apple

The Tor Project exists to provide privacy and anonymity for millions of people, including human rights defenders across the globe whose lives depend on it. The strong encryption built into our software is essential for their safety.

In an age when people have so little control over the information recorded about their lives, we believe that privacy is worth fighting for.

We therefore stand with Apple to defend strong encryption and to oppose government pressure to weaken it. We will never backdoor our software.

Our users face very serious threats. These users include bloggers reporting on drug violence in Latin America; dissidents in China, Russia, and the Middle East; police and military officers who use our software to keep themselves safe on the job; and LGBTI individuals who face persecution nearly everywhere. Even in Western societies, studies demonstrate that intelligence agencies such as the NSA are chilling dissent and silencing political discourse merely through the threat of pervasive surveillance.

For all of our users, their privacy is their security. And for all of them, that privacy depends upon the integrity of our software, and on strong cryptography. Any weakness introduced to help a particular government would inevitably be discovered and could be used against all of our users.

The Tor Project employs several mechanisms to ensure the security and integrity of our software. Our primary product, the Tor Browser, is fully open source. Moreover, anyone can obtain our source code and produce bit-for-bit identical copies of the programs we distribute using Reproducible Builds, eliminating the possibility of single points of compromise or coercion in our software build process. The Tor Browser downloads its software updates anonymously using the Tor network, and update requests contain no identifying information that could be used to deliver targeted malicious updates to specific users. These requests also use HTTPS encryption and pinned HTTPS certificates (a security mechanism that allows HTTPS websites to resist being impersonated by an attacker by specifying exact cryptographic keys for sites). Finally, the updates themselves are also protected by strong cryptography, in the form of package-level cryptographic signatures (the Tor Project signs the update files themselves). This use of multiple independent cryptographic mechanisms and independent keys reduces the risk of single points of failure.

The Tor Project has never received a legal demand to place a backdoor in its programs or source code, nor have we received any requests to hand over cryptographic signing material. This isn't surprising: we've been public about our "no backdoors, ever" stance, we've had clear public support from our friends at EFF and ACLU, and it's well-known that our open source engineering processes and distributed architecture make it hard to add a backdoor quietly.

From an engineering perspective, our code review and open source development processes make it likely that such a backdoor would be quickly discovered. We are also currently accelerating the development of a vulnerability-reporting reward program to encourage external software developers to look for and report any vulnerabilities that affect our primary software products.

The threats that Apple faces to hand over its cryptographic signing keys to the US government (or to sign alternate versions of its software for the US government) are no different than threats of force or compromise that any of our developers or our volunteer network operators may face from any actor, governmental or not. For this reason, regardless of the outcome of the Apple decision, we are exploring further ways to eliminate single points of failure, so that even if a government or a criminal obtains our cryptographic keys, our distributed network and its users would be able to detect this fact and report it to us as a security issue.

Like those at Apple, several of our developers have already stated that they would rather resign than honor any request to introduce a backdoor or vulnerability into our software that could be used to harm our users. We look forward to making an official public statement on this commitment as the situation unfolds. However, since requests for backdoors or cryptographic key material so closely resemble many other forms of security failure, we remain committed to researching and developing engineering solutions to further mitigate these risks, regardless of their origin.

We congratulate Apple on their commitment to the privacy and security of their users, and we admire their efforts to advance the debate over the right to privacy and security for all.

Tor Browser 6.0a4-hardened is released

A new hardened Tor Browser release is available. It can be found in the 6.0a4-hardened distribution directory and on the download page for hardened builds.

This release updates firefox to 38.7.1. Mozilla decided to disable the Graphite library in this release and we are taking the same action: irrespective of the security slider settings the Graphite library won't be used for rendering fonts in Tor Browser 6.0a4-hardened. The Graphite font rendering library was already disabled for users on the security level "High" or "Medium-High".

Note: There is no incremental update from 6.0a3-hardened available due to bug 17858. The internal updater should work, though, doing a complete update.

Here is the complete changelog since 6.0a3-hardened:

Tor Browser 6.0a4-hardened -- March 18 2016

  • All Platforms

    • Update Firefox to 38.7.1esr
    • Update Torbutton to 1.9.5.2

      • Bug 18557: Exempt Graphite from the Security Slider
    • Bug 18536: Make Mosaddegh and MaBishomarim available on port 80 and 443

Tor Browser 6.0a4 is released

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

This release updates firefox to 38.7.1. Mozilla decided to disable the Graphite library in this release and we are taking the same action: irrespective of the security slider settings the Graphite library won't be used for rendering fonts in Tor Browser 6.0a4. The Graphite font rendering library was already disabled for users on the security level "High" or "Medium-High".

The full changelog since 6.0a3 is:

Tor Browser 6.0a4 -- March 18 2016

  • All Platforms

    • Update Firefox to 38.7.1esr
    • Update Torbutton to 1.9.5.2

      • Bug 18557: Exempt Graphite from the Security Slider
    • Bug 18536: Make Mosaddegh and MaBishomarim available on port 80 and 443
Syndicate content Syndicate content