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 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.
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.
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:
- Running your own measurements with ooni-probe (Note that in some countries collecting measurements could get you into trouble – If you're unsure, contact firstname.lastname@example.org)
- Exploring OONI Explorer's measurements (Help us find more highlights!)
- Contributing code to the open source software tool
- Participating in the community and providing feedback:
Happy OONI exploring!
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.
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
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
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 5.5.4. The Graphite font rendering library was already disabled for users on the security level "High" or "Medium-High".
The full changelog since 5.5.3 is:
Tor Browser 5.5.4 -- March 18 2016
We are pleased to announce another public beta release of Tor Messenger. This release features important security updates to libotr, and addresses a number of stability and usability issues. All users are highly encouraged to upgrade.
The initial public release was a success in that it garnered a lot of useful feedback. We tried to respond to all your concerns in the comments of the blog post but also collected and aggregated a FAQ of the most common questions.
OTR over Twitter DMs
Tor Messenger now supports OTR conversations over Twitter DMs (direct messages). Simply configure your Twitter account with Tor Messenger and add the Twitter account you want as a contact. Any (direct) message you send to another Twitter contact will be sent over OTR provided that both contacts are running Tor Messenger (or another client that supports Twitter DMs and OTR).
Facebook support dropped
Facebook has long officially deprecated their XMPP gateway, and it doesn't appear to work anymore. We had multiple reports from users about this issue and decided that it was best to remove support for Facebook from Tor Messenger.
We hear that an implementation of the new mqtt based protocol is in the works, so we hope to restore this functionality in the future.
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.
In the future, we plan to port Tor Browser's updater patches (#14388) so that keeping Tor Messenger up to date is seamless and automatic. We also plan to add a UI to make importing OTR keys and accounts from Pidgin, and other clients, as easy as possible (#16526).
The secure updater will likely be a part of the next release of Tor Messenger.
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.
sha256sums.txt file containing hashes of the bundles is signed with the key
3A0B 3D84 3708 9613 6B84 5E82 6887 935A B297 B391).
Here is the complete changelog since v0.1.0b4:
Tor Messenger 0.1.0b5 -- March 09, 2016
- All Platforms
- Bug 13795: Remove SPI root certificate because Debian no longer ships it
- Bug 18094: Remove references to torbutton from start-tor-messenger script
- Bug 18235: Disable Facebook as they no longer support XMPP
- Bug 17494: Better error reporting for failed outgoing messages
- Bug 17749: Show version information in the "About" window
- Bug 13312: Add support for OTR over Twitter DMs
- Bump libotr to 4.1.1
- Bug 17896: Add Edit menu to the conversation window on OS X
- GH 65: Support Unicode paths on Windows