mikeperry's blog

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

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.

This is What a Tor Supporter Looks Like: Edward Snowden

Edward Snowden


In mid-October, the Tor Project had an opportunity to interview Edward Snowden. Below are key excerpts from the conversation.


Tor: What would you say to a non-technical person about why they should support and care about Tor?

ES: Tor is a critical technology, not just in terms of privacy protection, but in defense of our publication right -- our ability to route around censorship and ensure that when people speak their voices can be heard.

The design of the Tor system is structured in such a way that even if the US Government wanted to subvert it, it couldn't because it's a decentralized authority. It's a volunteer based network. Nobody's getting paid to run Tor relays -- they're volunteers worldwide. And because of this, it provides a built-in structural defense against abuses and most types of adversaries.

Tor provides a level of safety, a level of guarantee, to the confidentiality, and in some cases anonymity of human communications. I think this is an incredible thing because it makes us more human. We are at the greatest peace with ourselves when nobody's watching.

Tor: Can you talk about how the world would be different if Tor did not exist?

ES: Without Tor, the streets of the Internet become like the streets of a very heavily surveilled city. There are surveillance cameras everywhere, and if the adversary simply takes enough time, they can follow the tapes back and see everything you've done.

With Tor, we have private spaces and private lives, where we can choose who we want to associate with and how, without the fear of what that is going to look like if it is abused.

What the Tor network allows is what's called a mixed routing experience where, due to a voluntary cooperation of peers around the Internet -- around the world, across borders, across jurisdictions -- you get individuals who are able to share traffic in ways that don't require them to be able to read the content of it. So you don't have to trust every participant of the Tor network to know who you are and what you're looking for.

Tor: Did you know that Tor is run by a non-profit organization?

ES: Yes, Tor has been extremely open. Almost everybody who is involved in development has an online presence; they're involved in online engagement. You can drop into the IRC and talk to these people directly and ask them questions, or criticize them (laughs). It's a very open and inclusive community, and I think that's incredibly valuable.

They also have a very rich and well-supported mailing list, which is very helpful for people who want to move beyond being a passive user of Tor and actually start being an active participant in expanding the network, in running a relay node from your home, or even starting to experiment with running an exit, which I think is one of the most interesting parts of the Tor experience.


Please join Ed in supporting Tor Today!

Tor Browser 5.0.1 is released

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

This release fixes a crash bug that caused Tor Browser to crash on certain sites (in particular, Google Maps and Tumblr). The crash bug was a NULL pointer dereference while handling blob URIs. The crash was not exploitable.

Here is the complete changelog since 5.0:

  • All Platforms
    • Bug 16771: Fix crash on some websites due to blob URIs

Tor Browser 5.5a1 is released

The Tor Browser Team is proud to announce the first alpha release in the 5.5 series. The release is available for download in the 5.5a1 distribution directory and on the alpha download page.

This release features important security updates to Firefox. In particular, while the recent PDF.js exploit did not affect 4.5 users, it does affect users of 5.0a3 and 5.0a4. Although the High security level of the Security Slider also prevented the exploit from working against even those users, all alpha users are still strongly encouraged to upgrade as soon as possible.

In addition to fixing these security issues, the remaining major issues with Firefox 38 from 5.0a4 were also fixed. This release also features improvements to fingerprinting defenses. In particular, we continue to refine our font fingerprinting defense that was added in 5.0a4. With this defense, Tor Browser now ships with a standard set of fonts, and prefers to use the provided fonts instead of native ones in most cases. Interested users are encouraged to help us refine this defense by commenting on the associated ticket in our bugtracker.

This release also will reset the permanent NoScript whitelist, due to an issue where previous NoScript updates had added certain domains to the whitelist during upgrade. The whitelist is reset to the default for all users as a result, and future updates to the whitelist by NoScript have been disabled.

Here is the complete changelog since 5.0a4:

  • All Platforms
    • Update Firefox to 38.2.0esr
    • Update NoScript to 2.6.9.34
    • Update Torbutton to 1.9.3.3
      • Bug 16731: TBB 5.0 a3/a4 fails to download a file on right click
      • Bug 16730: Reset NoScript whitelist on upgrade
      • Bug 16722: Prevent "Tiles" feature from being enabled after upgrade
      • Bug 16488: Remove "Sign in to Sync" from the browser menu (fixup)
      • Bug 14429: Make sure the automatic resizing is enabled
      • Translation updates
    • Update Tor Launcher to 0.2.7.7
      • Translation updates
    • Bug 16730: Prevent NoScript from updating the default whitelist
    • Bug 16715: Use ThreadsafeIsCallerChrome() instead of IsCallerChrome()
    • Bug 16572: Verify cache isolation for XMLHttpRequests in Web Workers
    • Bug 16311: Fix navigation timing in ESR 38
    • Bug 15646: Prevent keyboard layout fingerprinting in KeyboardEvent (fixup)
    • Bug 16672: Change font whitelists and configs for rendering issues (partial)

Tor Browser 5.0 is released

The Tor Browser Team is proud to announce the first stable release in the 5.0 series. This release is available from the Tor Browser Project page and also from our distribution directory.

This release features important security updates to Firefox. Note that the recent PDF.js exploit did not affect 4.5 users, but they should upgrade to this release immediately because numerous other potential security issues were fixed by Mozilla in this release. (Incidentally: Users who are using the 5.0-alpha series are vulnerable to the PDF.js exploit, but not if they were using the 'High' security level. Regardless, we are also upgrading 5.0-alpha users to 5.5a1 today to fix the issue as well).

This release also brings us up to date with Firefox 38-ESR, which should mean improved support for HTML5 video on Youtube, as well as a host of other improvements. Controversial and hard-to-audit binary components related to EME DRM were disabled, however.

The release also features new privacy enhancements. In particular, more identifier sources that appeared in Firefox 38 (or were otherwise disabled previously) are now isolated to the first party (URL bar) domain. This release also contains defenses from the 5.0-alpha series for keystroke (typing) fingerprinting and some instances of performance/timing fingerprinting.

Regrettably, our new defenses for font and keyboard layout fingerprinting did not stabilize in time for this release. Users who are interested in helping us improve them should try out 5.5a1.

This release also will reset the permanent NoScript whitelist, due to an issue where previous NoScript updates had added certain domains to the whitelist during upgrade. The whitelist is reset to the default for all users as a result, and future updates to the whitelist by NoScript have been disabled.

Starting with this release, Tor Browser will now also download and apply upgrades in the background, to ensure that users upgrade quicker and with less interaction. This behavior is governed by the about:config pref app.update.auto, but we do not recommend disabling it unless you really know what you're doing.

Here is the complete changelog since 4.5.3:

  • All Platforms
    • Update Firefox to 38.2.0esr
    • Update OpenSSL to 1.0.1p
    • Update HTTPS-Everywhere to 5.0.7
    • Update NoScript to 2.6.9.34
    • Update meek to 0.20
    • Update Tor to 0.2.6.10 with patches:
      • Bug 16674: Allow FQDNs ending with a single '.' in our SOCKS host name checks.
      • Bug 16430: Allow DNS names with _ characters in them (fixes nytimes.com)
      • Bug 15482: Don't allow circuits to change while a site is in use
    • Update Torbutton to 1.9.3.2
      • Bug 16731: TBB 5.0 a3/a4 fails to download a file on right click
      • Bug 16730: Reset NoScript whitelist on upgrade
      • Bug 16722: Prevent "Tiles" feature from being enabled after upgrade
      • Bug 16488: Remove "Sign in to Sync" from the browser menu (fixup)
      • Bug 16268: Show Tor Browser logo on About page
      • Bug 16639: Check for Updates menu item can cause update download failure
      • Bug 15781: Remove the sessionstore filter
      • Bug 15656: Sync privacy.resistFingerprinting with Torbutton pref
      • Bug 16427: Use internal update URL to block updates (instead of 127.0.0.1)
      • Bug 16200: Update Cache API usage and prefs for FF38
      • Bug 16357: Use Mozilla API to wipe permissions db
      • Bug 14429: Make sure the automatic resizing is disabled
      • Translation updates
    • Update Tor Launcher to 0.2.7.7
      • Bug 16428: Use internal update URL to block updates (instead of 127.0.0.1)
      • Bug 15145: Visually distinguish "proxy" and "bridge" screens.
      • Translation updates
    • Bug 16730: Prevent NoScript from updating the default whitelist
    • Bug 16715: Use ThreadsafeIsCallerChrome() instead of IsCallerChrome()
    • Bug 16572: Verify cache isolation for XMLHttpRequests in Web Workers
    • Bug 16884: Prefer IPv6 when supported by the current Tor exit
    • Bug 16488: Remove "Sign in to Sync" from the browser menu
    • Bug 16662: Enable network.http.spdy.* prefs in meek-http-helper
    • Bug 15703: Isolate mediasource URIs and media streams to first party
    • Bug 16429+16416: Isolate blob URIs to first party
    • Bug 16632: Turn on the background updater and restart prompting
    • Bug 16528: Prevent indexedDB Modernizr site breakage on Twitter and elsewhere
    • Bug 16523: Fix in-browser JavaScript debugger
    • Bug 16236: Windows updater: avoid writing to the registry
    • Bug 16625: Fully disable network connection prediction
    • Bug 16495: Fix SVG crash when security level is set to "High"
    • Bug 13247: Fix meek profile error after bowser restarts
    • Bug 16005: Relax WebGL minimal mode
    • Bug 16300: Isolate Broadcast Channels to first party
    • Bug 16439: Remove Roku screencasting code
    • Bug 16285: Disabling EME bits
    • Bug 16206: Enforce certificate pinning
    • Bug 15910: Disable Gecko Media Plugins for now
    • Bug 13670: Isolate OCSP requests by first party domain
    • Bug 16448: Isolate favicon requests by first party
    • Bug 7561: Disable FTP request caching
    • Bug 6503: Fix single-word URL bar searching
    • Bug 15526: ES6 page crashes Tor Browser
    • Bug 16254: Disable GeoIP-based search results.
    • Bug 16222: Disable WebIDE to prevent remote debugging and addon downloads.
    • Bug 13024: Disable DOM Resource Timing API
    • Bug 16340: Disable User Timing API
    • Bug 14952: Disable HTTP/2
    • Bug 1517: Reduce precision of time for Javascript
    • Bug 13670: Ensure OCSP & favicons respect URL bar domain isolation
    • Bug 16311: Fix navigation timing in ESR 38
  • Windows
    • Bug 16014: Staged update fails if meek is enabled
    • Bug 16269: repeated add-on compatibility check after update (meek enabled)
  • Mac OS
    • Use OSX 10.7 SDK
    • Bug 16253: Tor Browser menu on OS X is broken with ESR 38
    • Bug 15773: Enable ICU on OS X
  • Build System
    • Bug 16351: Upgrade our toolchain to use GCC 5.1
    • Bug 15772 and child tickets: Update build system for Firefox 38
    • Bugs 15921+15922: Fix build errors during Mozilla Tryserver builds
    • Bug 15864: rename sha256sums.txt to sha256sums-unsigned-build.txt

Tor Browser 5.0a2 is released

The second alpha release in the 5.0 series of the Tor Browser is now available from our extended downloads page as well as the distribution directory.

This release provides a fix for the Logjam attack (https://weakdh.org/) and updates a number of Tor Browser components: Tor to version 0.2.7.1-alpha, Torbutton to version 1.9.2.7, NoScript to version 2.6.9.26, meek to version 0.19 and HTTPS-Everywhere to version 5.0.5. Moreover, it fixes a possible crash on Linux and avoids breaking the Add-ons page if Torbutton is disabled, and it also fixes an update issue when using meek on Windows systems.

Here is the complete changelog

  • All Platforms
    • Update Tor to 0.2.7.1-alpha
    • Update OpenSSL to 1.0.1n
    • Update HTTPS-Everywhere to 5.0.5
    • Update NoScript to 2.6.9.26
    • Update meek to 0.19
    • Update Torbutton to 1.9.2.7
      • Bug 15984: Disabling Torbutton breaks the Add-ons Manager
      • Bug 14429: Make sure the automatic resizing is enabled
      • Translation updates
    • Bug 16130: Defend against logjam attack
    • Bug 15984: Disabling Torbutton breaks the Add-ons Manager
  • Windows
    • Bug 16014: Staged update fails if meek is enabled
    • Bug 16269: repeated add-on compatibility check after update (meek enabled)
  • Linux
    • Bug 16026: Fix crash in GStreamer
    • Bug 16083: Update comment in start-tor-browser

Tor Browser 4.5.2 is released

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

Tor Browser 4.5.2 provides a fix for the Logjam attack (https://weakdh.org/) and updates a number of Tor Browser components: Tor to version 0.2.6.9, Torbutton to version 1.9.2.6, NoScript to version 2.6.9.26 and HTTPS-Everywhere to version 5.0.5. Moreover, it fixes a possible crash on Linux and avoids breaking the Add-ons page if Torbutton is disabled.

Here is the complete changelog since 4.5.1:

  • All Platforms
    • Update Tor to 0.2.6.9
    • Update OpenSSL to 1.0.1n
    • Update HTTPS-Everywhere to 5.0.5
    • Update NoScript to 2.6.9.26
    • Update Torbutton to 1.9.2.6
      • Bug 15984: Disabling Torbutton breaks the Add-ons Manager
      • Bug 14429: Make sure the automatic resizing is disabled
      • Translation updates
    • Bug 16130: Defend against logjam attack
    • Bug 15984: Disabling Torbutton breaks the Add-ons Manager
  • Linux
    • Bug 16026: Fix crash in GStreamer
    • Bug 16083: Update comment in start-tor-browser
Syndicate content Syndicate content