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
- <br />
- Why is Akamai blocking me?<br />
- Blog Post created by Lawrence Taub Employee on Apr 7, 2016<br />
- Like • Show 7 Likes7<br />
- Why is Akamai blocking me?</p>
- <p>Akamai does not block users from accessing our customers’ websites. However, our customers can use tools and policies which may in turn block you (the end user). Our customers use these rules to protect them and you from malicious actors on the internet. Some common reasons could include:<br />
- Explicit IP blocking / blacklisting<br />
- Location-based blacklisting<br />
- Rule-based blocking (i.e. web application firewall protections)<br />
- Reputation-based blocking<br />
- HTTP request rate controls (e.g. DoS protections)</p>
- <p>The following activities may trigger application security controls:<br />
- Web application layer attacks such as: SQL Injection, Cross-Site Scripting, Local File Inclusion, Remote Command Execution, Remote File Inclusion, etc.<br />
- Volumetric attacks or similar high rate HTTP traffic<br />
- Web contents scraping, data mining, web content indexing and similar automated web activities<br />
- Web vulnerability scanning using automated tools</p>
- <p>Your reputation follows you. If your IP is identified as behaving poorly on one site, you may be blocked on other websites. A first step in troubleshooting may be to determine whether your organization is performing one of the activities listed above that could affect your reputation.</p>
- <p>When a page cannot be accessed, whether because of a customer policy blocking access to that resource or a variety of other reasons such as a server error, the error page will typically be presented as follows:</p>
- <p>2016-01-27-12-21-11-137732.png<br />
- [eg:<br />
- Access Denied<br />
- You don't have permission to access "<a href="http://www.lowes.com/"" rel="nofollow">http://www.lowes.com/"</a>; on this server.</p>
- <p>Reference #18.random.string.goes.here.81n1<br />
- <p>Notice the reference number. Akamai customers can use this reference number to identify why this request failed.</p>
- <p>If you are unable to access a web site, this may be the result of a policy configured by the site owner you are attempting to access. To make a change to this policy, the site owner (the Akamai customer) would have to change their policy. Akamai is unable to make this change without the explicit direction of the site owner. To obtain the contact information for a site owner, one avenue to explore might be via whois. Please contact the site owner directly and have them in turn contact Akamai if they believe that you should be able to access the resource.
So lookup the whois and ask them to whitelist every exit node?
I would guess auto-submitting exit nodes (which I have also run) would get black listed too.