[tbb-bugs] #24351 [Applications/Tor Browser]: Block Global Active Adversary Cloudflare
Tor Bug Tracker & Wiki
blackhole at torproject.org
Mon Nov 20 21:55:53 UTC 2017
#24351: Block Global Active Adversary Cloudflare
-------------------------------------------------+-------------------------
Reporter: nullius | Owner: tbb-
| team
Type: enhancement | Status:
| reopened
Priority: High | Milestone:
Component: Applications/Tor Browser | Version:
Severity: Normal | Resolution:
Keywords: security, privacy, anonymity, mitm, | Actual Points:
cloudflare |
Parent ID: #18361 | Points:
Reviewer: | Sponsor:
-------------------------------------------------+-------------------------
Changes (by nullius):
* status: closed => reopened
* resolution: invalid =>
Comment:
Replying to [comment:7 cypherpunks]:
> You can't tell unless you have access to a site owner's Cloudflare
account whether they have full SSL with Cloudflare or whether Cloudflare
is MiTMing them, so this doesn't seem possible.
Either you are obfuscating, or you are technologically incompetent. Quick
proof: Assume the opposite. If Cloudflare did not act as a MITM proxy
with full, active access sufficient to read ''and modify'' TLS plaintext
of all connections passing through them, then they would be unable to
inject the HTTP headers which this bug proposes to detect for blocking.
[Sequential dotted initials “Q.”, “E.”, “D.” forbidden by Trac spam
filter.]
Cloudflare is a MITM, ''by design''. That is the primary (only?) service
they offer. It does not matter what the site’s service level with them
is. From the connecting user-agent’s perspective (here apropos), it does
not even matter if the site uses its
[https://web.archive.org/web/20171118213855/https://blog.cloudflare.com
/keyless-ssl-the-nitty-gritty-technical-details/ so-called “keyless SSL”]
service to preserve secrecy of its ''long-term'' private keys. Cloudflare
always, always has the symmetric key to the session; and within the
ostensibly encrypted session, Cloudflare is by definition a Man-In-The-
Middle which decrypts, modifies, and proxies the plaintext.
Why, it is exactly as if Cloudflare were designed as a mass surveillance
tool! So, what rationalizations could be supposed for those who use their
services, or ignore them as a global threat?
“But Cloudflare is a trustworthy provider of Internet infrastructure.”
Then, why do we need TLS at all? Just make peering arrangements with
trustworthy networks who agree to pass your packets only through
trustworthy routers! TLS eliminates trust in the network: By design, TLS
promises end-''to-end'' encryption. Meaning, with the ''endpoint''. By
design, Cloudflare makes a mockery of this promise.
“But most sites are on third-party hardware, anyway.” Irrelevant:
Cloudflare centralizes trust.
Without the Cloudflare MITM proxy, `little-newbie-web-shop.com`’s TLS is
handled by `cheap-shared-web-host.com`; `chic-trendy-cloud-buzzword-
startup.com`’s TLS is handled by AWS; `at-risk-controversial-activism.org`
and `high-security-bitcoin-services.com` should (we hope) do all their
crypto on hardware under their respective owners’ physical control. The
site visitor is responsible for deciding which endpoints to trust with
private information. (N.b.: Reading interests and “clicktrails” are
private information.) When all these sites sign up for Cloudflare, then
Cloudflare becomes the one-stop decryption shop. Do you trust Cloudflare
to ''be'' the “secure” Internet, or some huge proportion thereof?
Centralizing trust has a much worse effect than allowing access to many
individual sites: It creates a single point at which to perform mass
dragnet surveillance. As of today, Cloudflare has access to the plaintext
data of more TLS sessions to more endpoints than anybody else on
Earth.![1] Here, the whole is more than the sum of the parts: They are
in a position to track, tap, ''and link'' Internet activity across a wide
range of sites. This is why they have been declared a [ticket:18361
Global Active Adversary].
If I were the NSA or another TLA, and I sat down to design a mass-
interception network to MITM TLS on a large portion of the Internet, then
the result would look exactly like Cloudflare. They are in a position
where they in fact do intercept the communications of billions of people
with millions of websites. That is not a hypothetical: It is a
description of what they actually do—every day, ''right now''. Then, they
cross their fingers and promise to respect people’s privacy. “Trust us;
we will make you ‘safer’.” Again—why use any encryption at all?
On that level, Cloudflare is even worse than “key escrow” or another
backdoor would be. Since the 90s, advocates of “key escrow” have promised
that if centrally trusted parties are allowed to keep a backdoor key, then
that would really, truly only ever be used to intercept the communications
of whatever they deem “bad guys”. (Pinky swear!) Cloudflare walks in
through the front door, and takes the plaintext—all of it, without
exception, for everybody whose connections pass through them.
And worst of all, the design of Cloudflare removes responsibility and
decision-making power from the initiator of communications. End-users are
fooled into believing they connect to many different sites—all of which
run through a single chokepoint. '''The purpose of this bug is to
mitigate that problem, in a web browser specifically designed for
security, privacy, and unlinkability on an anonymity network.'''
“But we need Cloudflare to protect from DDoS.” Hey, that’s a nice site
you have there. It would be a shame, such a shame, if anything happened
to it. Why don’t you let us decrypt all your TLS sessions, so we can
protect you?
Cloudflare only exists because of criminal activity which can be otherwise
defended against, and which should not be possible at all. They profit
from fear of vigilante network censors, hold-your-site-hostage
blackmailers, and Internet arsonists who simply enjoy setting things on
fire for the “lulz”. The proper long-term solution to these problems
involves serious technical work to make DDoS attacks more difficult to
perform (and especially, harder to amplify). The proper short-term
solution involves sysadmins working with competent hosts and upstream
providers—just as is done by many sites which are not Cloudflare
~~patsies~~ customers. (I notice that torproject dot org, a controversial
website, somehow manages to survive without Cloudflare.) Routing the TLS
plaintext of millions of websites through a single MITM is ''not'' a
solution.
Anyway, the reason why sites use Cloudflare is irrelevant. This bug is
about user choice, informed decisions, and frankly, the honesty of the
network. When I see the lock icon in Tor Browser, I take that as a
guarantee that my connection is end-to-end encrypted. '''If a site uses
Cloudflare, then the browser lock icon is a false promise.''' When I use
Tor Browser to make a https connection, I also quite reasonably expect
that it will terminate the connection with an error message if it detects
any evidence whatsoever a MITM attack. In this sense, blocking or warning
on detection of `CF-RAY:` is more reliable than, say, disallowing self-
signed certificates: The latter could be the genuine certificate of a
website configured by a doofus, or it could be a `BadExit` running
`sslstrip`, or it could be network naughtiness by hackers (on the
government payroll or otherwise). `CF-RAY:` is ''always'' the result of a
definitional MITM attack by a Global Active Adversary.
In sum, “[ticket:24321 CAPTCHA madness]” is the smallest problem with
Cloudflare. Their design, their business model, their very existence is a
threat to the privacy, security, and freedom of the Internet. Blocking
Cloudflare is an eminently reasonable mitigation strategy for a web
browser which bears the name, “Tor Browser”. Bug re-opened.
----
1. Source: I just assume as much; but Cloudflare would brag about that,
if restated in other words as on their homepage:
“[https://web.archive.org/web/20171120102156/https://www.cloudflare.com/
Cloudflare makes more than 6,000,000 Internet properties faster and
safer.]” Yes, they provide “secure CDN” service to more sites than
anybody else. Do you know of anybody else who actively MITMs that many
TLS endpoints?
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/24351#comment:8>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
More information about the tbb-bugs
mailing list