\n
这些并非全部都是篡改,但其中一部分显然是篡改,下面将详细介绍。挑战在于过滤掉这些干扰信息,确定哪些异常连接可以肯定地归因于篡改。
\n在我们的工作中,我们确定了 19 种异常连接模式,作为连接篡改的候选签名。我们发现其中的 14 种模式,之前曾被主动的“实地”测量工作报告过,这为宏观层面的验证提供了机会:如果我们在其他人实地观察到的相同位置观察到来自 Cloudflare 网络的篡改签名,那么我们可以更加确信,对于之前没有报告过的其他地方,这些签名也能捕捉到连接篡改的真实案例。为了减轻在已知存在篡改的地方进行查看而产生的确认偏差风险,我们决定同时查看所有地方。
采用这种方法,下图取自我们的同行评审研究,是对 19 个签名的直观并排比较。数据取自 2023 年 1 月 26 日开始的两周间隔。每个签名列中都有按连接来源国家/地区细分的匹配连接比例。例如,右边第三列标有 ⟨PSH → RST;RST0⟩,表示我们几乎只在来自中国的连接上观察到该签名。总体而言,我们的发现反映了先前公开的报告中的已知案例,这表明我们的方法有效。
\n图 1:跨国家/地区的签名匹配:每一列是与特定签名匹配的全球总连接数。每一列内部,是来自各个国家/地区的连接中与该签名匹配的连接比例。
有趣的是,通过深入研究普遍性,并抛开签名匹配的原始数量,有趣的模式就显现出来了。由于这种数据驱动的视角,还带来了意想不到的宏观见解。如果我们关注按互联网用户数量排名全球前三的国家/地区,可以发现,来自中国的连接在至少 9 个签名中占据了相当大的比例。这也许并不令人惊讶,但为之前的研究提供了支持,这些研究发现,中国防火长城 (GFW) 由阻止命令的许多不同部署和实施组成。接下来,来自印度的连接匹配也在 9 个不同签名中占据了相当大的比例,其中 5 个与中国匹配率很高的签名相同。看看人口第三多的美国,除了两个签名外,所有签名中都出现了明显(甚至较大)的匹配比例。
以下是部分国家/地区签名分布的快照,该快照也是从同行评审研究中获取的。全球分布情况也包含在内,以供比较。为了完整性,我们也包含了标记为 ⟨SYN → ∅⟩ 的深灰色部分,但与其他部分相比,这一部分更有可能用篡改之外的其他原因来解释(例如,由于低速率 SYN 洪水攻击)。
\n图 4:每个国家/地区的签名分布:来自特定国家/地区(以及全球)的与特定签名匹配或未被篡改的连接百分比。
从这个角度来看,我们观察到的模式再次与先前的研究相符。我们首先关注高于全球平均水平的比例,并忽略中灰色中干扰最大的特征 ⟨SYN → ∅⟩;在这个最早的阶段,签名匹配有太多其他解释。在来自土库曼斯坦 (TM)、俄罗斯 (RU)、伊朗 (IR) 和中国 (CN) 的所有连接中,大约 80%、30%、40% 和 30% 的连接与篡改签名相匹配。数据还显示,在之前没有报告的地方,签名匹配率很高。例如,来自秘鲁 (PE) 和墨西哥 (MX) 的连接匹配率分别约为 50% 和 25%;对这些国家/地区各个网络的分析表明,一个可能的原因是移动和蜂窝网络中的零费率,即 ISP 允许免费访问某些资源(但不允许免费访问其他资源)。看看全球平均水平以下的国家,英国 (GB)、美国 (US) 和德国 (DE) 匹配签名的连接数均在 10% 左右。
数据表明,连接篡改现象十分普遍,离很多用户(甚至大多数用户)都很近。从很多方面来看,这种现象比大多数人想象的还要近。为了解释其中的原因,我们使用电话这种非常熟悉的通信工具来解释连接篡改现象。
\n连接篡改是第三方阻止访问特定内容的一种方式。但是,第三方仅仅知道它想要阻止的内容类型是不够的。第三方只能通过名称来阻止身份。
归根结底,连接篡改是因意外才有可能发生的——这是协议设计的一个意外副作用。在互联网上,最常见的身份是域名。在互联网上的通信中,域名通常在 TLS 中的“服务器名称指示 (SNI)”字段中传输——以明文形式公开给所有人查看。
要理解这一点的重要性,首先要了解在没有互联网的情况下,人与人之间的通信中连接篡改是什么样子的。互联网本身的外观和运作方式与邮政系统非常相似,后者只依赖地址,而不依赖姓名。然而,大多数人使用互联网的方式更像“普通的老式电话系统”,它需要姓名才能成功。
在电话系统中,人们首先拨打的是电话号码,而不是称呼姓名。只有在对方接听并且呼叫者听到声音后,呼叫才会接通并可用。呼叫者只有在接通后才会询问姓名。呼叫在系统中表现为未标识通信方的能量信号。最后,在通话结束后,需要重新拨打电话才能再次进行通信。
在互联网上,客户端(例如浏览器)会“建立连接”。这与电话呼叫者非常相似,客户端向服务器号码(即 IP 地址)发起连接请求。用于连接两个设备的最古老的“面向连接”协议称为传输控制协议 (TCP)。域名的传输与连接建立无关,就像接听电话后再询问姓名一样。连接由元数据“逻辑”标识,而元数据并不标识通信方。最后,每次访问网站时都会建立新的连接。
\nTCP 连接与电话通话的比较
如果电话公司被要求阻止与某一方通话,会发生什么情况?一种选择是修改或操纵电话簿,使呼叫者无法获得他们拨打电话所需的电话号码;这就是 DNS 过滤的本质。第二种选择是阻止对该电话号码的所有呼叫,但这会无意中影响其他人,就像 IP 阻止那样。
一旦电话响起,电话公司要知道正在呼叫谁,唯一的办法就是监听通话,等待呼叫者说“某某在吗?”或“我可以和某某通话吗?”。移动电话也不例外。我们打给某个号码,所找的那个人就会接电话,这只是一种期望,而并非现实。例如,父母可能会把号码给自己的孩子,或者出租车公司可能会留下值班人员的手机号码。因此,电话公司必须监听。一旦听到某个名字,它就可以挂断电话;双方都不知道发生了什么——这就是互联网连接篡改的定义。
就建立通信渠道而言,电话呼叫和 TCP 连接至少是相当的,甚至可以说完全相同——尤其是因为域名的传输是与建立连接分开的。
同样,在互联网上,第三方了解连接的预期接收者的唯一方法是“查看”数据包传输时的内部情况。电话公司必须监听姓名,而互联网上的第三方则等待看到它不喜欢的东西,通常是禁用的名称。回想一下上面所说的协议的意外副作用:名称在 SNI 中可见,SNI 是帮助加密数据通信所必需的。当发生这种情况时,第三方会通过丢弃消息或注入特制的消息来导致通信双方中止连接,从而使一个或两个设备关闭连接。
触发篡改的机制始于深度数据包检测 (DPI),这意味着查看地址以外的数据部分以及属于连接的其他元数据。可以肯定地说,此功能不是免费的。无论是 ISP 的路由器还是上级代理,DPI 都是一项昂贵的操作,而且规模越大或速度越快,成本就越高。
最后值得一提的是,电话篡改的弱点同样出现在连接篡改中。例如,尽管写起来不同,但 Jean 和 Gene 的读音对任何人来说都无法区分。同样,篡改 Twitter 的简称“t.co”的连接也会影响“microsoft.com”——这种情况已经发生了。
\n在深入探讨技术之前,Cloudflare 的许多员工还有一个个人动机。透明度很重要,这也是我们开始这项工作的原因,但在看到 2022 年伊朗马赫萨·阿米尼抗议期间的数据后,我们才在内部承诺在 Radar 上共享数据。
下图是抗议活动期间 17 天内来自伊朗的连接情况。图表追踪了异常连接的单个信号,包括不同类型的连接篡改签名。这些数据的日期早于 Radar 服务,因此我们选择分享同行评审论文中的这一表示。这也是通过 Radar 共享数据的价值的第一个示例。
\n图 8 :全国抗议期间伊朗的签名匹配率。 (𝑥 轴是当地时间。)
从数据中,有两个观察结果引人注目。首先,抗议活动开始前线条似乎很稳定,抗议活动开始后线条数量增加。其次,随着时间的推移,线条之间发生变化,特别是浅灰色、深紫色和深绿色的线条。回想一下,每条线都是不同的篡改签名,因此线条之间的变化表明了根本原因的变化——要么是起作用的机制,要么是调用它们的流量。
我们强调,签名匹配本身并不意味着存在篡改。然而,在 2022 年伊朗的案例中,有公开报道称其采取了各种形式的封锁。当时使用的方法,特别是基于服务器名称指示 (SNI) 的内容访问封锁,之前也已得到充分记录,并且与我们上图所示的观察结果相符。
那今天呢?下面我们可以看到从 2023 年 8 月到 2024 年 8 月的十二个月 Radar 视图。每种颜色代表可能发生篡改的连接的不同阶段。在过去的 12 个月中,伊朗的 TCP 连接异常总体上低于全球平均水平,但在浅蓝色区域表示的异常部分中似乎明显更高。此 “Post ACK” 通信阶段通常与基于 SNI 的阻止有关。(在上图中,相关签名由深紫色和深绿色线表示。)此外,自 2023 年 12 月中旬以来不同情节线的比例变化表明,技术一直在随着时间的推移而变化。
\n作为开放测量和研究社区重要性的证明,这项工作确实“站在巨人的肩膀上”。它是与马里兰大学、洛桑联邦理工学院和密歇根大学的研究人员合作完成的,但并非孤立存在。人们已经付出了大量的努力来测量连接篡改,其中大部分来自审查测量社区。大部分工作由主动测量构成,研究人员在网络和区域内或沿网络和区域制作和传输探测器,以识别阻止行为。毫无疑问,主动测量既有优点也有缺点,如论文第 2 节所述。
与主动测量相对应的是被动测量,也是我们项目的重点,它采用“观察而不采取任何行动”的方法。被动测量有其自身的优点和缺点,但至关重要的是,它依赖于拥有良好的有利位置,例如大型网络运营商。主动和被动测量在结合使用时最有效,在本文所讨论的情况中,有助于更全面地了解连接篡改对用户的影响。
最重要的是,在进行任何类型的测量时,都必须非常小心地了解和评估测量的安全性,因为对人员和网络施加的风险通常是间接的或隐藏的。
\n我们毫不怀疑对连接篡改保持透明的重要性,但我们也需要明确从数据中获取的见解的局限性。作为 Cloudflare 网络(且仅限 Cloudflare 网络)连接的被动观察者,我们只能看到或推断以下内容:
连接被篡改的迹象,但不知道发生的位置。客户端应用和服务器系统之间的任何软件或设备都可能篡改连接。这个范围涵盖专用系统、企业或家庭宽带路由器中的防火墙,以及安装在家庭或学校计算机上的保护软件。我们所能推断的只是连接的起始位置(尽管这受限于互联网设计固有的地理位置不准确性)。
(通常,但并非总是)是什么触发了篡改,但不知道原因。通常,篡改系统由域名、关键字或正则表达式触发。通过足够的重复和手动检查,可能可以识别出篡改的可能起因,但无法识别原因。许多篡改系统设计容易产生意想不到的后果,上面提到的 t.co 示例就是其中之一。
确实受影响的人和事,但不包括可能受影响的人和事。作为被动观察者,我们能做出的推断种类有限。例如,在 1001 个与 example.com
的连接中,有 1000 个可观察到篡改,这表明下一次连接尝试也可能发生篡改。然而,这并没有说明与 another-example.com
的连接相关的任何信息。
如果您只是想获取和使用 Radar 上的数据,请参阅我们的“操作方法”指南。若想要了解更多,那让我们来了解一下数据本身。
这项工作的重点是 TCP。在我们的数据中,第三方可以使用两种机制来强制关闭连接:丢弃数据包以引起超时,或注入伪造的 TCP RST 数据包,每种机制都有各种部署选择。个别篡改签名可能反映了这些选择。需要了解的是,正常的 TCP 关闭是使用 FIN 数据包启动的。
\n我们的检测机制会根据一组签名来评估连接中的数据包集,以判断是否存在连接篡改。这些签名是根据之前工作中识别出的签名手工生成的,并通过分析我们归类为异常(即提前关闭的连接,以及在客户端发出不到 10 个数据包时,以 RST 数据包或超时的方式不合时宜地关闭的连接)的 Cloudflare 网络连接样本生成的。我们分析了这些样本,发现 19 种模式占样本中所有可能被篡改的连接的 86.9%,如下表所示。
\n表 1:我们通过全球被动测量识别的一组篡改签名。
为了帮助推断篡改情况,我们还根据上述 19 个签名出现的连接生命周期阶段对其进行了分类。每个阶段都暗示了有关中间盒的一些信息,如下所述,并附有相应的序列图:
\n(a) Post-SYN(握手过程中):篡改可能由目标 IP 地址触发,因为中间盒可能没有看到应用数据(数据通常在握手完成后传输)。
(b) Post-ACK(握手后紧接着):连接建立后立即被强制关闭,未看到任何数据。中间盒甚至很可能已经看到了数据包;例如 HTTP 中的主机标头或 TLS 中的 SNI 字段。
(c) Post-PSH(第一个数据包之后):中间盒肯定已经看到第一个数据包,因为服务器已经接收到它。中间盒可能一直在等待带有 PSH 标志的数据包,该标志通常设置为指示数据包中的数据应在收到后立即传送给应用,不得延迟。这里的中间盒可能是旁观者攻击 (monster-on-the-side),因为它允许有问题的数据包到达目的地。
(d) 流程后期(多个数据包后):在连接的后期篡改(不是紧接在第一个数据包之后,但仍在前 10 个数据包内)。TLS 中加密数据的普遍性使得这一阶段成为最不容易发生篡改的阶段。可能的触发因素是在 (HTTP) 连接后期以明文形式出现的关键字,或者企业代理和家长保护软件之类的产品。这些软件可以查看加密流量,并在遇到某些关键字时重置连接。
我们如何确信上述签名能够检测到中间盒篡改,而不仅仅是非典型的客户端行为?被动测量的一个挑战是我们无法完全了解连接到我们网络的客户端,因此很难(甚至不可能)获得绝对肯定的结果。我们会寻找强有力的篡改证据,而这必须首先从识别误报开始。
我们知道以下误报来源很难与真正的篡改来源区分开来。除最后一个之外,其他所有误报都发生在连接的前两个阶段,即在接收数据包之前。
扫描程序是客户端应用,用于探测服务器以引出响应。一些扫描程序软件使用标头中的固定位进行自我识别,这有助于我们进行过滤。例如,我们发现 Zmap 约占所有 ⟨SYN → RST⟩ 签名匹配的 1%。
SYN 洪水攻击是另一个可能的误报来源,尤其是对于 Post-SYN 连接阶段的签名,例如 ⟨SYN → ∅⟩ 和 ⟨SYN → RST⟩ 签名。这些不太可能出现在我们的数据集收集中,数据集收集发生在 DDoS 防护系统之后。
Happy Eyeballs 是双栈客户端常用的一种技术,客户端会发起与服务器的 IPv6 连接,并在延迟一段时间以支持 IPv6 后,再建立 IPv4 连接。客户端会保留第一个成功的连接并丢弃另一个。停止传输或使用 RST 而非 FIN 关闭连接的客户端会显示在数据中,与 ⟨SYN → RST⟩ 签名相匹配。
浏览器触发的 RST 可能出现在连接的任何阶段,但尤其适用于在连接后期(多个数据包之后)匹配的签名。例如,它可能由用户关闭浏览器选项卡触发。然而,与有针对性的篡改不同,源自浏览器的 RST 不太可能偏向特定服务或网站。
我们如何区分合法客户端发起的误报和第三方篡改?我们寻求一种基于证据的方法来区分篡改签名和数据集内的其他信号。为此,我们要利用数据包标头中的各个位。
\n单独的签名匹配不足以做出正确的判断。与此同时,我们可以通过检查总体连接来找到进一步支持其准确性的证据——如果原因是篡改,并且篡改是有针对性的,那么一定还有其他共同的模式或标记。例如,我们预计浏览器行为会出现在世界各地;然而,正如我们上面所展示的,仅在某些地方或某些时间间隔与连接匹配的签名就会凸显出来。
类似地,我们期望连接内连续数据包中的某些特征也能凸显出来,事实上它们也确实如此,即 IP 标头中的 IP-ID 和 TTL 字段。
\nIPv4 数据包标头中的 IP-ID(IP 标识)字段通常是每个连接的固定值,通常由客户端针对其发送的每个后续数据包进行递增。换句话说,我们预计从同一客户端发送的后续数据包中 IP-ID 值的变化很小。因此,在正常连接中,后续数据包之间 IP-ID 值的大幅变化是意料之外的,可以用作数据包注入的指标。这正是我们在标记为 (a) 的上图中看到的一组选定签名的情况。
生存时间 (TTL) 字段为检测注入的数据包提供了另一个线索。同样,大多数客户端实施也对连接上发送的每个数据包使用相同的 TTL,通常最初设置为 64 或 128,并由数据包路由上的每个路由器递减。如果 RST 数据包的 TTL 与连接中的其他数据包不相同,则表明它是注入的。请看上图 (b),我们可以看到 TTL 的明显差异,表明存在第三方。
我们强烈建议读者阅读这些内容背后的细节,了解它们的意义和原因。IP-ID 和 TTL 最大差值较大的连接为流量篡改提供了积极证据,但没有这些信号并不一定意味着没有发生篡改,因为众所周知,一些中间盒会从连接中的原始数据包中复制 IP 标头值,包括 IP-ID 和 TTL。我们的重点在于负责任地确保我们的数据集具有指示价值。
最后还有一点需要注意:虽然我们的篡改签名可以捕获多种形式的篡改,但仍有可能出现漏报,即连接已被篡改但未被我们检测到。一些示例是在前 10 个数据包之后终止的连接(因为我们并没有对这一部分进行采样)、FIN 注入(RST 注入的不太常见的替代方案)或所有数据包在到达 Cloudflare 服务器之前被丢弃的连接。我们的签名也不适用于基于 UDP 的协议,例如 QUIC。我们希望将来扩大连接篡改签名的范围。
\n为了了解这在 Cloudflare 网络上的表现,下面我们提供了与连接篡改的 OONI 报告一致的 TCP 连接异常的更多示例。
如需了解此项研究的更多见解,请参阅完整的技术论文和演示文稿。对于下文未列出的其他地区和网络,请参阅 Radar 上的新数据。
\n来自巴基斯坦内部的报告显示,2024 年 8 月用户的互联网体验发生了变化。看一下 8 月初的两个星期时间,从 2024 年 8 月 9 日开始,Post-ACK 连接异常发生了显著变化。
\n8 月 9 日的 Post-ACK 峰值几乎完全归因于 AS56167 (Pak Telecom Mobile Limited),如下面第一张图所示,其中 Post-ACK 异常从对于所有连接不足 5%,跃升至 70% 以上,并且此后一直保持高位。相应地,我们看到从 AS56167 中的客户端到达 Cloudflare 网络的成功 HTTP 请求数量显著减少(如下面第二张图所示),这证明连接正在中断。这个巴基斯坦的例子强调了确凿报告和观察结果的重要性,在 Radar 数据集发布中对此进行了更详细的讨论。
\n2024 年 4 月的 OONI 报告讨论了坦桑尼亚的有针对性的连接篡改行为。报告指出,在客户端观察到这种阻止,因为在 TLS 握手期间的 Client Hello 消息之后连接超时,这表明中间盒正在丢弃包含 Client Hello 消息的数据包。在服务器端,以这种方式被篡改的连接将显示为 Post-ACK 超时,因为包含 Client Hello 消息的 PSH 数据包永远不会到达服务器。
查看下面浅蓝色部分中表示的 Post-ACK 数据,我们发现了匹配的证据:来自坦桑尼亚的所有新 TCP 连接中,近 30% 都显示为 Post-ACK 异常。进一步细分(下图中未显示),大约三分之一是由于超时,与上面的 OONI 报告一致。其余部分是由于 RST。
\n埃塞俄比亚是另一个之前报告过连接篡改的地区。与此一致,我们发现埃塞俄比亚网络中 Post-PSH TCP 异常的发生率较高。我们的内部数据显示,这里的大多数 Post-PSH 异常都是由 RST 引起的,不过超时也很普遍。
\n从位于埃塞俄比亚的 IP 地址到达 Cloudflare 服务器的流量大部分来自 AS24757 (Ethio Telecom),如下面第一张图所示,因此其数据与全国范围内的连接异常分布非常吻合也就不足为奇了。来自 AS328988 (SAFARICOM TELECOMMUNICATIONS ETHIOPIA PLC) 的 Post-PSH 连接数量(如下面第二张图所示)的比例更高,占该网络所有连接的 33% 以上。
\n连接篡改是一种以各种形式部署在互联网上的阻止机制。尽管我们已经开发出各种方法来帮助在全球范围内检测和了解这种行为,但这种体验就像电话中断一样,因人而异。
连接篡改也可能因意外而发生。之所以能成功,是因为域名以明文形式可见。但情况可能并非总是如此。例如,Encrypted Client Hello (ECH) 是一种加密 SNI 字段的新兴构建块。
我们将继续寻找讨论网络活动和中断的方法,以促进更广泛的对话。请查看 Cloudflare Radar 上有关连接异常的最新内容和相应的博客文章,以及同行评审技术论文及其 15 分钟的总结演讲。
"],"published_at":[0,"2024-09-05T00:00-07:00"],"updated_at":[0,"2024-10-09T23:05:22.113Z"],"feature_image":[0,"https://cf-assets.www.cloudflare.com/zkvhlag99gkb/25gh0YtlMKeoZPrXPocdbF/1086704243bdd200d84824411f2acc53/2544-1-Hero.png"],"tags":[1,[[0,{"id":[0,"5kZtWqjqa7aOUoZr8NFGwI"],"name":[0,"Radar"],"slug":[0,"cloudflare-radar"]}],[0,{"id":[0,"0kgHdg1ytbdWl5BNo6bEa"],"name":[0,"互联网流量"],"slug":[0,"internet-traffic"]}],[0,{"id":[0,"5DD7GZ0oxjP3NGOaJMwyWq"],"name":[0,"Internet Quality"],"slug":[0,"internet-quality"]}],[0,{"id":[0,"1x7tpPmKIUCt19EDgM1Tsl"],"name":[0,"Research"],"slug":[0,"research"]}],[0,{"id":[0,"3yArjf0gLKZy8ObEDxbNNi"],"name":[0,"趋势"],"slug":[0,"trends"]}],[0,{"id":[0,"4nA5kKyA1tOqFyjHMque21"],"name":[0,"消费者服务"],"slug":[0,"consumer-services"]}]]],"relatedTags":[0],"authors":[1,[[0,{"name":[0,"Ram Sundara Raman"],"slug":[0,"ram-sundara-raman"],"bio":[0],"profile_image":[0,"https://cf-assets.www.cloudflare.com/zkvhlag99gkb/3UVOuih3bnqUpi04pndstU/943d06f0e1f5a9c3da97bba49154fdae/1718326572215.jpg"],"location":[0],"website":[0],"twitter":[0,"ramakrishnan13s"],"facebook":[0]}],[0,{"name":[0,"Luke Valenta"],"slug":[0,"luke"],"bio":[0,null],"profile_image":[0,"https://cf-assets.www.cloudflare.com/zkvhlag99gkb/2FfvsynZPyK2w2lJSIXdqr/f8758aa6638121491d233932a076770e/luke.jpg"],"location":[0,"Austin, TX"],"website":[0,"https://lukevalenta.com/"],"twitter":[0,"@lukevalenta"],"facebook":[0,null]}],[0,{"name":[0,"Marwan Fayed"],"slug":[0,"marwan"],"bio":[0,null],"profile_image":[0,"https://cf-assets.www.cloudflare.com/zkvhlag99gkb/IXphrXdPbBBtMHdRMzIrB/340102a31143f4743a74c87ec0e0c11e/marwan.jpg"],"location":[0,null],"website":[0,null],"twitter":[0,"@marwanfayed"],"facebook":[0,null]}]]],"meta_description":[0,"Cloudflare 开始提供在我们的全球网络上观察到的连接篡改行为。"],"primary_author":[0,{}],"localeList":[0,{"name":[0,"A global assessment of third-party connection tampering Loc"],"enUS":[0,"English for Locale"],"zhCN":[0,"Translated for Locale"],"zhHansCN":[0,"No Page for Locale"],"zhTW":[0,"Translated for Locale"],"frFR":[0,"No Page for Locale"],"deDE":[0,"No Page for Locale"],"itIT":[0,"No Page for Locale"],"jaJP":[0,"No Page for Locale"],"koKR":[0,"No Page for Locale"],"ptBR":[0,"No Page for Locale"],"esLA":[0,"No Page for Locale"],"esES":[0,"No Page for Locale"],"enAU":[0,"No Page for Locale"],"enCA":[0,"No Page for Locale"],"enIN":[0,"No Page for Locale"],"enGB":[0,"No Page for Locale"],"idID":[0,"No Page for Locale"],"ruRU":[0,"No Page for Locale"],"svSE":[0,"No Page for Locale"],"viVN":[0,"No Page for Locale"],"plPL":[0,"No Page for Locale"],"arAR":[0,"No Page for Locale"],"nlNL":[0,"No Page for Locale"],"thTH":[0,"No Page for Locale"],"trTR":[0,"No Page for Locale"],"heIL":[0,"No Page for Locale"],"lvLV":[0,"No Page for Locale"],"etEE":[0,"No Page for Locale"],"ltLT":[0,"No Page for Locale"]}],"url":[0,"https://blog.cloudflare.com/connection-tampering"],"metadata":[0,{"title":[0,"A global assessment of third-party connection tampering"],"description":[0,"Cloudflare brings visibility to the practice of connection tampering as observed from our global network."],"imgPreview":[0,"https://cf-assets.www.cloudflare.com/zkvhlag99gkb/7qfmk2t7Ak57tVFtpXUwg1/d2bcf7ba705dc4e269dfe6a94235a87e/A_global_assessment_of_third-party_connection_tampering-OG.png"]}]}],"locale":[0,"zh-cn"],"translations":[0,{"posts.by":[0,"作者"],"footer.gdpr":[0,"GDPR"],"lang_blurb1":[0,"这篇博文也有 {lang1} 版本。"],"lang_blurb2":[0,"这篇博文也有 {lang1} 和{lang2}版本。"],"lang_blurb3":[0,"这篇博文也有 {lang1}、{lang2} 和{lang3}版本。"],"footer.press":[0,"新闻"],"header.title":[0,"Cloudflare 博客"],"search.clear":[0,"清除"],"search.filter":[0,"过滤"],"search.source":[0,"来源"],"footer.careers":[0,"招聘"],"footer.company":[0,"公司"],"footer.support":[0,"支持"],"footer.the_net":[0,"theNet"],"search.filters":[0,"过滤器"],"footer.our_team":[0,"我们的团队"],"footer.webinars":[0,"网络研讨会"],"page.more_posts":[0,"更多帖子"],"posts.time_read":[0,"{time} 分钟阅读时间"],"search.language":[0,"语言"],"footer.community":[0,"社区"],"footer.resources":[0,"资源"],"footer.solutions":[0,"解决方案"],"footer.trademark":[0,"商标"],"header.subscribe":[0,"订阅"],"footer.compliance":[0,"合规性"],"footer.free_plans":[0,"Free 计划"],"footer.impact_ESG":[0,"影响/ESG"],"posts.follow_on_X":[0,"在 X 上关注"],"footer.help_center":[0,"帮助中心"],"footer.network_map":[0,"网络地图"],"header.please_wait":[0,"请稍候"],"page.related_posts":[0,"相关帖子"],"search.result_stat":[0,"针对 {search_keyword} 的第 {search_range} 个搜索结果(共 {search_total} 个结果)"],"footer.case_studies":[0,"案例研究"],"footer.connect_2024":[0,"Connect 2024"],"footer.terms_of_use":[0,"服务条款"],"footer.white_papers":[0,"白皮书"],"footer.cloudflare_tv":[0,"Cloudflare TV"],"footer.community_hub":[0,"社区中心"],"footer.compare_plans":[0,"比较各项计划"],"footer.contact_sales":[0,"联系销售"],"header.contact_sales":[0,"联系销售团队"],"header.email_address":[0,"电子邮件地址"],"page.error.not_found":[0,"未找到页面"],"footer.developer_docs":[0,"开发人员文档"],"footer.privacy_policy":[0,"隐私政策"],"footer.request_a_demo":[0,"请求演示"],"page.continue_reading":[0,"继续阅读"],"footer.analysts_report":[0,"分析报告"],"footer.for_enterprises":[0,"企业级服务"],"footer.getting_started":[0,"开始使用"],"footer.learning_center":[0,"学习中心"],"footer.project_galileo":[0,"Project Galileo"],"pagination.newer_posts":[0,"较新的帖子"],"pagination.older_posts":[0,"较旧的帖子"],"posts.social_buttons.x":[0,"在 X 上讨论"],"search.icon_aria_label":[0,"搜索"],"search.source_location":[0,"来源/位置"],"footer.about_cloudflare":[0,"关于 Cloudflare"],"footer.athenian_project":[0,"Athenian Project"],"footer.become_a_partner":[0,"成为合作伙伴"],"footer.cloudflare_radar":[0,"Cloudflare Radar"],"footer.network_services":[0,"网络服务"],"footer.trust_and_safety":[0,"信任与安全"],"header.get_started_free":[0,"免费开始使用"],"page.search.placeholder":[0,"搜索 Cloudflare"],"footer.cloudflare_status":[0,"Cloudflare 状态"],"footer.cookie_preference":[0,"Cookie 首选项"],"header.valid_email_error":[0,"必须是有效的电子邮件地址。"],"search.result_stat_empty":[0,"显示第 {search_range} 个结果(共 {search_total} 个结果)"],"footer.connectivity_cloud":[0,"全球连通云"],"footer.developer_services":[0,"开发人员服务"],"footer.investor_relations":[0,"投资者关系"],"page.not_found.error_code":[0,"错误代码:404"],"search.autocomplete_title":[0,"请输入查询内容。按回车键发送"],"footer.logos_and_press_kit":[0,"标识与媒体资料包"],"footer.application_services":[0,"应用程序服务"],"footer.get_a_recommendation":[0,"获得推荐"],"posts.social_buttons.reddit":[0,"在 Reddit 上讨论"],"footer.sse_and_sase_services":[0,"SSE 和 SASE 服务"],"page.not_found.outdated_link":[0,"您可能使用了过期的链接,或者输入了错误的地址。"],"footer.report_security_issues":[0,"报告安全问题"],"page.error.error_message_page":[0,"抱歉,我们找不到您要打开的页面。"],"header.subscribe_notifications":[0,"订阅以接收新文章的通知:"],"footer.cloudflare_for_campaigns":[0,"Cloudflare for Campaigns"],"header.subscription_confimation":[0,"订阅已确认。感谢订阅!"],"posts.social_buttons.hackernews":[0,"在 Hacker News 上讨论"],"footer.diversity_equity_inclusion":[0,"多元、公平与包容"],"footer.critical_infrastructure_defense_project":[0,"关键基础设施防护项目"]}]}" ssr="" client="load" opts="{"name":"PostCard","value":true}" await-children="">2021-10-14
对大规模运营而言,IP 寻址抑制了网络和 web 导向服务的创新。对于每一个架构更改,当然在开始设计新系统时,我们被迫问的第一组问题就是:...