Mike Gerwitz said:

That's a denial of service.

There also seems to be confusion around terminology that's
aggravating discussion. "Denial of Service" (abbreviated DoS) has a
very specific meaning in computing, and refers to an attack on a
network resource that makes it unavailable to users requesting
it.[0]

I have a degree in infosec, so I can tell you that it is not correct
to say that a denial of service is necessarily an attack. You have
denial of service ("DoS"), and you have the (very common) DoS attack.
You pointed to a definition of a /DoS attack/, and described it as a
DoS.

Whether a DoS is an "attack" or not is a matter of intent. I called
it an attack in the subject for an earlier post because CloudFlare is
doing it deliberately, and they know the harm they are causing as
their business model justifies it (to them).

For this discussion, it's not important whether the DoS is an attack
or not. But it is a DoS nonetheless. It is therefore a security
issue. We do not limit infosec matters to malicious attacks, as
Hollywood films would imply.

So, as Alfred mentioned in another part of this thread, this isn't
DoS---the server itself is doing this, not an attacker.

You may not have noticed that Alfred is using a dictionary:

http://lists.gnu.org/archive/html/gnu-system-discuss/2017-03/msg00064.html

Any entry-level infosec textbook will give better information than a dictionary.

Despite how disagreeable this is, it's important to understand why
and how this is happening. (Let me preface this with me saying that
I disagree fundamentally with centralizing chunks of the Web behind CloudFlare, but that's orthogonal to this discussion.)

The problem with CloudFlare and Tor is a well-understood and
well-documented one that is under active discussion between the Tor
Project and CloudFlare.[1][2]

I highly recommend reading ticket 18361. It's a shame ioerror is no
longer around to properly defend the Tor community. IMO Schneiere is
asleep at the helm. The thread demonstrates that CloudFlare is
fixated on evolving the captcha instead of improving the heuristics to
the level of their competitors, which would render the captcha quality
a non-issue.

Without rereading the whole bug report (I followed it back when it
unfolded), I also seem to recall CloudFlare actually trying to put the
Tor community to work, fixing software using gratis labor from
volunteers so that it will work with their captcha, as opposed to
doing the work themselves. As expected, it's all about the bottom
line with CloudFlare. They don't invest in good heuristics because
the cost is higher than blocking Tor users unilaterally.

Exit nodes are blocked by CloudFlare based on heuristics. If an
exit node is flagged for whatever reason (often due to high
traffic), then any user of that exit node is affected. It's
annoying, and it's a big problem, but a non-trivial one to solve. I
deal with their CAPTCHAs every single day.

That's marketing at work. All Tor exit nodes are published.
CloudFlare blocks all Tor nodes. Heuristics are also used, but those
run in /aggregate/ to the Tor block list.

Consider the FSF's webserver. Back in May of last year, they were
hit by a large DDoS attack peaking at 200Gbps.[3] In a situation
like this, you have no choice but to start blacklisting. So let's
say IP X was blacklisted because there was traffic coming from it
that was slamming the FSF's servers. Let's also say that X was a
Tor exit node (since exit nodes are often used for attacks,
unfortunately). Let's say that you, as a Tor user, were using exit
node X. You try to visit the FSF's website and you're blocked.

This scenario is true, but misleading and misfocused. Indeed when a significant attack is underway, things get messy, legit users get
blocked (which is the inherent problem anyway). In your scenario
above, the incident response effort is in fact working in the interest
of getting service to legit users. No one has a problem with sensible emergency blocking.

The problem comes when, in the absence of attack, a cheap preemptive
approach is used with substantial collateral damage. It's not
heuristic blocking, it's unilateral and blunt. If a site wants off
the unilateral Tor block list, they must whitelist the tor network specifically. GNU Radio Foundation, Inc. is not doing that.

This comment must be addressed separately:

(since exit nodes are often used for attacks, unfortunately)

We often hear that from CloudFlare spokespeople.

A DDoS attack requires many high performance high bandwidth nodes.
The Tor network doesn't have that. Tor only has 7,280 nodes (as of my
last count taken on feb.27), and most of them are slow. Most brute
force attacks would kill the Tor network itself before the target. An
attacker could only use Tor to DDoS a vastly underpowered site.

Have you been discriminated against?

Of course. How is that even disputable? The point of contention is
whether the crude and discriminatory blocking technique is
*necessary*. If you want to claim it's not discriminatory, we can go
over the mountain of evidence to the contrary.

Denied service for unjust reasons? No, you haven't. It's
completely justified.

This has not been demonstrated. I might accept that the DoS is "just"
if I can first be convinced that it is necessary. Roughly 90% of the
surface web has figured out how to protect their sites without
CloudFlare (and the discriminatory practices it implements). One of
the ways to make a convincing case for CloudFlare is to demonstrate
why gnuradio.org (with its threat model) cannot be part of that 90%*
of freedom-respecting (non-CF) sites.

(*) I know I've neglected to count the number of non-CF sites that
block Tor, but I suspect that's a relatively small. 10% would be
generous based on my anecdotal experience, so IMO it'd be safe to
say 80% of the web functions without discriminating unilaterally
against the Tor community.

Unfortunately, Tor being what it is, is host to some malicious
traffic.[4]

That reference doesn't really support what you just said. I've read
that article before, and wonder if you read past the first sentence.
Your statement is technically correct. There is "some" malicious
traffic coming from Tor, as well as non-Tor networks of that size or
larger.

Obviously the 94% figure is a perverse PR tactic. When you say "some"
and then reference the disputed classic 94% claim, are you trying to
draw a parallel there? To say "some" without a figure is obviously insufficient.

The 94% has not been substantiated in any way. It's so unrealistic
that CF spokepeople have had to defend it by saying it's a packet
count, not a user count. We also know that CF treats all robots as "malicious". Without going further into those flaws, the
unverifiability of the figure can be summarily dismissed by a quote
from Dwayne David Paul (in response to a CIA claim of proof):

DDP> You don't "announce" proof, you share it. If they haven't
DDP> shared it, then it's not proof. "I promise I have evidence"
DDP> isn't really evidence.'

Combined with the fact that there are far more Tor users
than exit nodes, Tor users will disproportionately be served
CAPTCHAs. If you are driving down a highway on New Year's at
midnight and are stuck in a line of people being given tests for
drunk driving, you can't claim discrimination for being one of the
people in that line being questioned.

If non-white people are being automatically stopped and tested, while
white people are checked only when their driving shows signs of
impairment, we would (quite rightly) call it discriminatory.

CloudFlare could do much better at deciding when to serve such
CAPTCHAs, but that's not entirely relevant for this discussion.

It certainly is, if you're going to challenge the claim of
"discriminatory" blocking, and also claim that the status quo (and the unilateral treatment therein) is necessary.

I don't like CloudFlare. I don't think people should use
CloudFlare. I use Tor for all of my Web traffic. But my negative
bias doesn't change the facts of the matter.

This is not only a red herring, but the bias in your statements shows
the contrary. Stating a counter bias can only deceive readers and has
no purpose in a logical argument. The reader can judge your bias from
the statements you put forward, if they care to.

If you are going to proxy your connections through others' servers
that others are also using, and by design you cannot be
distinguished from those others, then you will be treated as part of
that group.

That's false. All concurrent Tor users are first distinguishable by
exit node IPs. It is not necessary to treat all Tor users as
attackers. Furthermore, for a particular given exit node IP, it is
also possible to treat users sharing the same node differently. The
TCP/IP header has lots of information that can distinguish concurrent
users of a shared exit node.

So:

- The page you are seeing is an attack mitigation from CloudFlare
because the Tor exit node you were using was flagged (different
exit nodes will give you different results);

That's CF bias at work. CF will not disclose their algorithms, but we
know from jgrahamc in the famous ticket 18361 that CF is using the
exit node list. It's also plainly evident to Tor users in our regular
use that the (unsubstantiated) claim above cannot possibly be correct.

- "Denial of Service" means something else;[0] and

It's not necessarily an attack. In the quote at the top, I actually
took care to omit the word "attack". Attack is in the subject line,
but the subject line of the thread was well-established before the
lynx instance came up.

- While there are innocent users caught in the line of fire, there
is no discrimination against any particular people.

When someone needlessly puts innocent users in the line of fire, this
is quite obviously discrimination. It's a cost-saving tactic. One
could claim that saving money is not discrimination, but I say it's
both. It's discrimination against a minority group to save money.

--
Please note this was sent anonymously, so the "From:" address will be unusable. List archives with replies to:
https://lists.gnu.org/archive/html/security-discuss/2017-03/msg00078.html will be monitored.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)