译|Cloudflare有害论
原文由 Hugo Landau 在 2019 年发表，链接： https://www.devever.net/~hl/cloudflare
[网站们应避免使用 Cloudflare。]
Cloudflare的HTTP前端服务包含一些严重值得质疑的做法。就目前情况而言，使用Cloudflare的网站数量之多，再加上其存在的问题，对互联网的状态构成了威胁。
Cloudflare向站长们宣传时并不会指出这些问题，站长们甚至可能并不知情。
CAPTCHA 验证码的荒谬性
如果网站用了 Cloudflare，默认情况下，大概率导致网站出现随机的异常。
所谓网站，本质上是一个处理 HTTP 请求的服务。而使用 Cloudflare 会导致这种服务变得不可靠，并对用户呈现一种「拒绝服务」的状况，并且几乎是随机发生且无可追溯的。
当发生此类「拒绝服务」的情况时，Cloudflare 会下发一个奇怪的「One More Step」页面，要求访问者完成 reCAPTCHA 才能访问该网站。 Cloudflare 声称这是基于 IP 的声誉，但这其实是一种将 IP 和用户（粗暴地）混为一谈的错误推断，这种做法对 Tor 用户的网页浏览体验造成了极大的损害。
如果用户禁用了 Cookie ，或者使用了不支持 iframe 的浏览器（例如 lynx），这个页面甚至无法正常工作。
该页面的 HTTP 状态代码为 403 Forbidden（禁止访问）。 从本质上讲，Cloudflare 的这种设计是一种对用户随机实施的 拒绝服务 攻击，而同时 Cloudflare 却自相矛盾地宣传自己是一个用于减轻 DoS 攻击的服务。
Cloudflare 声称这些措施对于打击恶意行为是必要的。这个说法值得怀疑，因为（这种验证码措施）作为一种CDN的运营模式，似乎很少有其他 CDN服务商效仿。换句话说，其他 CDN 似乎并不需要如此操作，就可以在正确实现 HTTP 的同时提供抗 DDoS 的保护，而不会要求用户随机完成验证码。
Cloudflare 随机要求用户完成验证码的行为，在设计上对非人类用户存在歧视。
这对网络的可抓取性造成危害。
目前尚不清楚那些需要进行网络爬虫的组织在受到 Cloudflare 行为的阻碍时有什么可行的补救措施。即便 Cloudflare 对这些组织进行了白名单处理，这实际上是将 Cloudflare 变成了搜索引擎合法性的判断权威；鉴于 Cloudflare 用户数量之庞大，这一点令人深感忧虑。
在HTTP标准中，并没有要求用户或其用户代理完成验证码才能加载页面的依据，而且Cloudflare发出的验证码验证也没有以任何标准方式传达。用于这些页面的「403 Forbidden」状态码可以表达任意种类的禁止策略，例如不可协商的拒绝访问。
Cloudflare 不仅要求人类用户（但并不始终如一；只有当它随机决定这样做时），而且也不能以机器可读的方式明确地表达状态，这对机器人——包括很多合法的机器人——是歧视性的。
相当荒谬的是，如果您想通过 Cloudflare 提供 API，就必须将 API endpoints排除在验证之外，否则 Cloudflare 可能会阻止访问。
这样就有一个问题：
[如果您必须在其中挖洞，那最初设置这一系统的意义何在？]
这基本上证明了前面的观点： Cloudflare 的这种所谓保护机制会对正常服务产生干扰。
Cloudflare 无法以合理、透明的方式实施 HTTP，这种莫名的无能似乎是所有其他 CDN 服务所没有的问题。
而更荒谬的是，Cloudflare 甚至联系了 Tor 项目团队，要求他们修改 Tor 以适应 Cloudflare 自身存在问题的操作方式。
Cloudflare 在与 Tor 的联系中表示，其验证码的理由不是缓解 DDoS，而是出于以下原因：
- 他们希望减少垃圾评论
- 他们认为在GET请求中验证用户，比在实际发表评论的POST请求中验证，是一种更好的 UI
- 此外，如果评论系统使用AJAX， 拦截POST请求将无法正常工作
你可能会认为，最后一点可能会让 Cloudflare 意识到，试图在 CDN 层面阻止垃圾评论是徒劳无益的，其结果只能是破坏 HTTP， 但事实并非如此。
Cloudflare 在此尝试的做法，从根本上来说就是错误的（事实上，「 WAF 」的整个前提从根本上都是错误的，见下文），因为 Cloudflare 无法理解 HTTP 流量的语义，也绝对无法重新构建站长们的网络应用程序，使其理解自己的 AJAX 请求为何会被随机拒绝。
换句话说，由于如上所述，CAPTCHA 平等地歧视所有机器人，因此 Cloudflare 的服务会无意中歧视其所服务的网站的 JavaScript， 从而破坏它们。
Cloudflare 对此的应对似乎是预先对整个网站弹出验证码，以防万一有人想要发表评论，但即使这样做也不一定有什么效果；
我确实遇到过一些没有预先弹验证码的网站，于是它们的 AJAX 功能被破坏，原因是 Cloudflare 拒绝了后续的 AJAX 触发请求，而 JS 代码的设计并不是为了处理这种情况（无论如何，也不可能有任何合理的方法来处理这种情况）。
「恶用 」和 WAF 谬论
除了作为CDN之外，Cloudflare 还声称他们的 CAPTCHA 可以用来减轻其他「恶意」流量，比如「采集电子邮件地址」。
lunar： 你能告诉我们，什么行为算作恶用吗？
jgrahamc： 恶意行为包括：评论垃圾信息、搜集电子邮件地址、攻击 Web 应用程序（例如 SQL 注入）、HTTP DoS（利用反应缓慢的 Web 服务器或应用程序使其离线）。 我对 L3/L4 层的 DoS 和 Tor 不感兴趣，因为这几乎不存在（除非出口节点本身是僵尸网络的一部分）。
这是一种从根上就不成立的做法。
尝试在 CDN 级别过滤 SQL 注入只是一种徒劳的安全表演。
所谓 WAF ，只是一种荒谬的理念，即通过匹配请求/响应中已知的常见恶意请求模式，就足以解决易受攻击的 Web 应用程序的安全问题。事实上，这种做法并不可靠或准确，因为不可能做到。
如果我尝试使用用户名 ' OR 0=0 -- 登录网站，Cloudflare 无法知道这是 SQL 注入攻击还是网站决定合法颁发的特殊用户名。 Cloudflare 无法知道该网站是否使用 SQL 进行数据存储。
如果我在评论中发布 ' OR 0=0 --， Cloudflare 无法知道这是否是 SQL 注入攻击，或者它是否真的有效，或者我是否真的发布了讨论 SQL 注入并包含示例的评论（此时这实际上已经成为一种审查）。
使用 Cloudflare 意味着，如果 Cloudflare 认为用户尝试使用 Cloudflare 在设计上对其过敏的文本模式，它会随机对用户造成 DoS。
当然，发生这些拒绝服务的情况是不明确的，也没有任何详尽地枚举，因此使用 Cloudflare 会给任何网站的可用性和内容中立性带来严重且无法预见的风险。
它本质上是一种使您的网站不可靠并且随机故障的方式。
任意且定义不明确的内容操纵
继续有缺陷的 WAF 这一话题，作为一个无法理解传输内容语义含义的代理，Cloudflare坚持做一些不符合CDN本质的事情。
即使在它没有随机对其客户网站进行DoS攻击的时候，Cloudflare也不愿意充当中立的流量代理，而是坚持对响应内容做一些特殊处理。
例如，它会混淆电子邮件地址，并用一些 JavaScript 解析来取代它们，目的是使（恶意的）采集工作复杂化。
不过，它并没有篡改电子邮件地址…… 它篡改的是任何隐约看起来像电子邮件地址的东西，即使不是邮件地址。
比如
Welcome to example. Com. To access the foobar API, use curl:
curl 'https://[email protected]/foobar'
变成了
Welcome to example. Com. To access the foobar API, use curl:
curl 'https://[email protected]/foobar'
XMPP 地址？ 已过滤。
SIP 地址？ 已过滤。
OpenSSH 算法标识符？ 已过滤。
Kerberos principal？ 已过滤。
由于这种过滤必然是在不考虑上下文的情况下进行的，因此它也存在试图防止 SQL 注入时所固有的问题，并有力地证明了 「 WAF 」从根本上来说是一个愚蠢的想法。
Cloudflare 实际上根本不可能知道某个内容是否是电子邮件地址，但它会过滤掉。
由于我在默认情况下禁用 JavaScript 的情况下浏览网页，因此在网站上发现一些甚至不是电子邮件地址的内容被替换为 「 email protected 」 ，甚至是源码列表的部分内容，这都让我不断地感到非常无语 🤦♂️。
当然，这种做法也会歧视禁用 JavaScript 的用户以及不支持 JavaScript 的浏览器，从而阻止他们查看电子邮件地址（或任何看起来类似的地址）。
Cloudflare 还会采取其他「自由」措施。
它会重新修改网页的 JavaScript，以优化网页。实际上，Cloudflare 会修改响应，以应用各种它认为合适的模糊定义的转换。从站长的角度来看，这应该被视为一种风险。
它实际上是一个情报机构
没有任何其他 CDN 服务提供与 Cloudflare 相媲美的免费服务。 而为什么 Cloudflare 提供免费服务？
这是因为 Cloudflare 不是 CDN，而是一个情报项目。其全部目的就是收集数据。
这不是我的推论哦，Cloudflare 的创始人曾很高兴地公开表示：
Back in 2003, Lee Holloway and I started Project Honey Pot as an open-source project to track online fraud and abuse. The Project allowed anyone with a website to install a piece of code and track hackers and spammers.
We ran it as a hobby and didn’t think much about it until, in 2008, the Department of Homeland Security called and said, ‘Do you have any idea how valuable the data you have is?’ That started us thinking about how we could effectively deploy the data from Project Honey Pot, as well as other sources, in order to protect websites online.
That turned into the initial impetus for CloudFlare.
早在 2003 年，Lee Holloway 和我就启动了 Project Honey Pot，作为一个开源项目来跟踪在线欺诈和滥用行为。该项目允许任何拥有网站的人安装一段代码并跟踪黑客和垃圾邮件发送者。
我们把它当作一种爱好来运行，并没有考虑太多，直到 2008 年，国土安全部打电话来说：“你知道你拥有的数据有多么有价值吗？” 这让我们开始思考如何有效地部署来自 Project Honey Pot 以及其他来源的数据，以保护在线网站。
这成为了 CloudFlare 的最初动力。
是的，Cloudflare 是由Project Honeypot 人员创建的。
译注： Project HoneyPot是一个分布式的蜜罐系统，主要用于防范和监测网络攻击行为
Cloudflare 还拥有极其慷慨的免费套餐，可能大多数使用它的网站都不付费。但正如我们在这个监视资本主义时代逐渐认识到的那样：
[如果你不付费，那么你不是客户——你就是产品。]
对 Tor 用户匿名的威胁。 Cloudflare不仅仅是通过要求Tor用户解决验证码来无谓地妨碍他们访问网站，它还构成了一个可能导致Tor用户去匿名化的工具。
Cloudflare基本上是攻击Tor的理想平台，因为它是迄今为止最接近「全视积极攻击者 」(GAA) 的存在 —— 一个能够在全球任意位置观察和修改流量的实体。
与之相比，「全视消极攻击者 」（GPA）的级别反而较低，它只能观察但不能修改世界上任何地方的流量。
译注： Global Passive Adversary (GPA) 全视消极攻击者是一种在网络安全和隐私保护领域常见的威胁模型，用于描述具有一种全视之眼、上帝视角的攻击者。由于GPA能够收集广泛的元数据信息，它在去匿名化攻击（de-anonymization attack）方面非常有效。
而 Tor 的设计目的并不能针对以上其中任何一个攻击提供有效的安全保护。
客观地来看，NSA 已经在2013 年放弃了获得 GPA 的地位（因此放弃了能够可靠地对 Tor 流量进行去匿名化的努力），更不用说成为 GAA 了。
Cloudflare 正在效果显著地邀请人们帮助其成为 GAA。
跟踪 cookie。顺便说一下，Cloudflare 会为任何使用它的网站提供一种追踪 cookie。即使网站本身是完全静态和无状态的，您仍然会被分配一个跟踪 cookie。( 由于 Cloudflare 肯定在欧盟拥有资产——它必须如此，因为它是一个 CDN——因此它在这点上也严重违反了欧盟法律）。
它可能是美国政府附属情报机构
众所周知，Cloudflare 为各种网站提供服务，包括海盗湾等臭名昭著的盗版网站。它同时又是一家美国公司。
大家都知道，即使是纸面上看似合法的公司（如 Megaupload），一旦涉及侵犯版权，美国也会将其取缔，因此这种情况非常不寻常。
可能的责任。《美国法典》第 17 编第 512 条 规定了各类实体的版权侵权责任豁免。17 USC 512 (c) 条*规定了 「根据用户指示删除系统或网络上的信息」；这就是众所周知的 「DMCA 通知 」条款。
不过，该法还包含一项与缓存代理（即 Cloudflare）有关的条款 17 USC 512 (b)。
该条款规定了免责有效的几个条件：
- 缓存代理传输的材料未经修改；以及
- 如果法院命令从原网站上删除材料，那么代理需要应对、处理与这些材料相关的删除命令；等等。
换句话说，如果美国法院命令海盗湾删除其网站的某些页面，Cloudflare 将有义务遵守要求他们在海盗湾本身不遵守的情况下实施删除的通知 ——无论如何，美国法院似乎也可以直接命令 Cloudflare 禁止对其进行访问。
但即使这样也是没有意义的，因为 Cloudflare 会修改它传输的材料。因此，它根本不能主张 17 USC 512 (b) 的豁免。此外，由于 47 USC 230 （《通信规范法》）明确规定了，其授予代理的责任豁免中不包含版权，因此如果没有适用的《美国法典》第 17 条第 512 条的豁免，它（Cloudflare）可能要承担相应责任。
尽管如此，美国甚至没有对 Cloudflare 向臭名昭著的盗版网站提供服务的活动发起攻击。
我的结论。如果美国政府愿意，他们很可能会通过法律诉讼对 Cloudflare 的业务产生不利影响。因此，他们没有这样做实在非同寻常。而如你所知，如果美国联邦执法部门认为不这样做就能获得更多情报，他们很乐意不去取缔非法活动。
从之前的一些项目——比如 PRISM —— 来看，大多数大型科技公司都非常乐意遵守情报和执法机构的完全访问请求。
此外，鉴于 Cloudflare 现在被大量网站使用，这意味着 Cloudflare 本质上是世界首屈一指的全球 「 中间人 机构」。
这种级别的访问和可见性是情报机构通常只能在梦里想想，尤其是因为它破坏了 TLS。
坦率地说，Cloudflare 可用的拦截数据对情报机构来说非常诱人，他们几乎不可能不去追踪这些数据，特别是考虑到有效勒索 Cloudflare 合法性的可能性，并且，重要的是，他们的创始人与国土安全部的已知历史接触。 （尽管如此，前提是科技公司默认不愿意协助法外监视，而众所周知，事实往往并非如此，这些科技公司往往表现出冷漠或彻底的热忱）
换句话说，基于概率的平衡，我认为 Cloudflare 缺乏来自美国政府的持续的压力，以及考虑到情报机构和科技公司的标准操作，使得 Cloudflare 极有可能成为美国信号情报 的有效组成部分。
译注： 美国信号情报 （SIGINT），是美国国家安全局（NSA）及其他情报机构收集和分析的情报类型。信号情报主要涉及通过电子信号（如电话、电子邮件、互联网通信等）获取的信息。
这当然不是证据或证明。然而，考虑到概率，假设事实不是这样——坦率地说——是不明智的。
尽管单独将 Cloudflare 用作窃听工具本身就挺可怕，但 Cloudflare 的部分 GAA（全视积极攻击者 ）与 NSA 的部分 GPA（全视消极攻击者 ）相结合的未来将极其可怕。
出于谨慎考虑——以及对那些试图将自己置于「 中间人 」地位的公司的不信任，即使他们声称是出于善意——完全有必要保持警惕。
毕竟，这种可能性本身就威胁到「加密复兴」，威胁到公众密码学社区自2013年以来所努力争取的一切——而密码学的核心就是在于减轻这些可能性。
作者注： 就我个人而言，我认为如今情报机构可能正在做的任何事情，它很可能正在做。斯诺登的爆料似乎表明这一规则很有用，所以我有时将其称为「斯诺登定律」。
结论
- Cloudflare 的产品基于根本性有缺陷的想法，例如根本无效的 WAF
- 使用 Cloudflare 是一种随机地攻击、并巧妙地破坏您自己的网站的方法
- 使用 Cloudflare 会歧视 Tor 用户，甚至一些非 Tor 用户
- Cloudflare 是世界领先的全球 中间人 机构，其实力可与任何信号情报机构相媲美。由于其广泛使用以及终止 TLS 会话这一事实，他们能够监视、监控、去匿名化和修改数量惊人且不断增长的网络流量。即使您信任 Cloudflare，将这种级别的信任置于一个实体也是极其不明智的。
- 一个提前的说明——熟悉 Cloudflare 服务的人可能会提到他们的「Keyless SSL」服务，但这实际上并没有改变任何事情，因为 Cloudflare 仍然终止 TLS 会话并查看解密后的流量。
- 很难想象这些拦截的数据最终不会落入情报机构手中。
💬 Comments
You can use your Fediverse account to reply to this post.