對(duì)第三方連接篡改的全球評(píng)估

您是否有過(guò)這樣的經(jīng)歷：打了個(gè)電話，剛接通，電話就被切斷了，并沒(méi)有什么確切的原因或解釋？讓我們以這個(gè)類比為起點(diǎn)，來(lái)了解互聯(lián)網(wǎng)上的連接篡改及其影響。

我們發(fā)現(xiàn)，20%的互聯(lián)網(wǎng)連接會(huì)在交換任何有用數(shù)據(jù)之前突然關(guān)閉?；旧?，每五個(gè)電話中就有一個(gè)在使用前被切斷。對(duì)于電話通話，通話的一方或雙方可能很難知道到底發(fā)生了什么。是連接出現(xiàn)了錯(cuò)誤嗎？還是電話那頭的人掛了電話？或者是有第三方介入并阻止了通話？

在互聯(lián)網(wǎng)上，Cloudflare具有獨(dú)特的優(yōu)勢(shì)，可以幫助確定第三方何時(shí)可能參與其中。我們的全球網(wǎng)絡(luò)讓我們能夠識(shí)別一些模式，表明可能有外部方故意篡改連接以阻止訪問(wèn)內(nèi)容。盡管這些模式通常很難破譯，但連接突然關(guān)閉的方式為可能發(fā)生的情況提供了線索。篡改源通常不會(huì)試圖隱藏其行為，這為它們的存在留下了線索，我們可以使用這些線索來(lái)識(shí)別連接協(xié)議中可檢測(cè)到的“簽名”。正如我們?cè)谙挛闹薪忉尩哪菢?，還有其他不太可能被欺騙的協(xié)議功能，它們指向第三方行為。我們可以使用這些提示來(lái)構(gòu)建可以識(shí)別的連接篡改簽名模式。

需要明確的是，第三方篡改連接的原因有很多。企業(yè)可能會(huì)篡改其網(wǎng)絡(luò)的出站連接，以防止用戶與垃圾郵件或網(wǎng)絡(luò)釣魚網(wǎng)站交互。ISP可能會(huì)利用連接篡改來(lái)執(zhí)行法院或監(jiān)管機(jī)構(gòu)的命令，這些命令要求通過(guò)阻止網(wǎng)站來(lái)解決版權(quán)侵權(quán)問(wèn)題或用于其他法律目的。政府可能會(huì)強(qiáng)制實(shí)施大規(guī)模的審查和信息管控。

盡管這種情況人人皆知，但之前沒(méi)有其他大型公司研究過(guò)大規(guī)模和跨司法管轄區(qū)的連接篡改活動(dòng)。我們認(rèn)為，這造成了一個(gè)顯著的缺口，妨礙人們理解互聯(lián)網(wǎng)生態(tài)系統(tǒng)中正在發(fā)生的事情，而揭露這些行為對(duì)于互聯(lián)網(wǎng)的透明度和長(zhǎng)期健康至關(guān)重要。因此，今天，我們很榮幸與大家分享對(duì)全球連接篡改行為的看法。

完整的技術(shù)細(xì)節(jié)最近經(jīng)過(guò)同行評(píng)審，并發(fā)布在ACM SIGCOMM的“全球被動(dòng)連接篡改檢測(cè)”上，還擁有公開演示文稿。我們還宣布在Cloudflare Radar上推出一個(gè)新的儀表板和API，以近乎實(shí)時(shí)的方式顯示特定連接超時(shí)和重置事件的視圖，這兩種機(jī)制在全球連接到Cloudflare網(wǎng)絡(luò)的用戶所遭受的篡改中占主導(dǎo)地位。

了解連接篡改的性質(zhì)以及我們討論它的原因?qū)⒂兄谀玫乩斫馕覀兊挠^點(diǎn)。

為全球受眾提供全球洞察

連接篡改的跡象在全球網(wǎng)絡(luò)中隨處可見(jiàn)。我們最初感到震驚的是，在全球范圍內(nèi)，前往Cloudflare的連接中，大約20%的連接在進(jìn)行任何有用數(shù)據(jù)交換之前就意外關(guān)閉了，這與連接篡改的比例一致。下面是Cloudflare所觀察到的這些異常連接的快照，我們會(huì)在Radar上分享。

通過(guò)Cloudflare Radar

這些并非全部都是篡改，但其中一部分顯然是篡改，下面將詳細(xì)介紹。挑戰(zhàn)在于過(guò)濾掉這些干擾信息，確定哪些異常連接可以被明確地歸因于篡改。

宏觀層面的分析和驗(yàn)證

在我們的工作中，我們確定了19種異常連接模式，作為連接篡改的候選簽名。我們發(fā)現(xiàn)其中的14種模式，之前曾被主動(dòng)的“實(shí)地”測(cè)量工作報(bào)告過(guò)，這為宏觀層面的驗(yàn)證提供了機(jī)會(huì)：如果我們?cè)谄渌藢?shí)地觀察到的相同位置觀察到來(lái)自Cloudflare網(wǎng)絡(luò)的篡改簽名，那么我們可以更加確信，對(duì)于之前沒(méi)有報(bào)告過(guò)的其他地方，這些簽名也能捕捉到連接篡改的真實(shí)案例。為了減輕在已知存在篡改的地方進(jìn)行查看而產(chǎn)生的確認(rèn)偏差風(fēng)險(xiǎn)，我們決定同時(shí)查看所有地方。

采用這種方法，下圖取自我們的同行評(píng)審研究，是對(duì)19個(gè)簽名的直觀并排比較。數(shù)據(jù)取自2023年1月26日開始的兩周間隔。每個(gè)簽名列中都有按連接來(lái)源國(guó)家/地區(qū)細(xì)分的匹配連接比例。例如，右邊第三列標(biāo)有?PSH→RST;RST0?，表示我們幾乎只在來(lái)自中國(guó)的連接上觀察到該簽名?？傮w而言，我們的發(fā)現(xiàn)反映了先前公開的報(bào)告中的已知案例，這表明我們的方法有效。

圖1：跨國(guó)家/地區(qū)的簽名匹配：每一列是與特定簽名匹配的全球總連接數(shù)。每一列內(nèi)部，是來(lái)自各個(gè)國(guó)家/地區(qū)的連接中與該簽名匹配的連接比例。

有趣的是，通過(guò)深入研究普遍性，并拋開簽名匹配的原始數(shù)量，有趣的模式就顯現(xiàn)出來(lái)了。由于這種數(shù)據(jù)驅(qū)動(dòng)的視角，還帶來(lái)了意想不到的宏觀見(jiàn)解。如果我們關(guān)注按互聯(lián)網(wǎng)用戶數(shù)量排名全球前三的國(guó)家/地區(qū)，可以發(fā)現(xiàn)，來(lái)自中國(guó)的連接在至少9個(gè)簽名中占據(jù)了相當(dāng)大的比例。這也許并不令人驚訝，但為之前的研究提供了支持，這些研究發(fā)現(xiàn)，中國(guó)國(guó)家防火墻（GFW）由阻止命令的許多不同部署和實(shí)施組成。接下來(lái)，來(lái)自印度的連接匹配也在9個(gè)不同簽名中占據(jù)了相當(dāng)大的比例，其中5個(gè)與中國(guó)匹配率很高的簽名相同?？纯慈丝诘谌嗟拿绹?guó)，除了兩個(gè)簽名外，所有簽名中都出現(xiàn)了明顯（甚至較大）的匹配比例。

以下是部分國(guó)家/地區(qū)簽名分布的快照，該快照也是從同行評(píng)審研究中獲取的。全球分布情況也包含在內(nèi)，以供比較。為了完整性，我們也包含了標(biāo)記為?SYN→??的深灰色部分，但與其他部分相比，這一部分更有可能用篡改之外的其他原因來(lái)解釋（例如，由于低速率SYN洪水攻擊）。

圖2：每個(gè)國(guó)家/地區(qū)的簽名分布：來(lái)自特定國(guó)家/地區(qū)（以及全球）的與特定簽名匹配或未被篡改的連接百分比。

從這個(gè)角度來(lái)看，我們觀察到的模式再次與先前的研究相符。我們首先關(guān)注高于全球平均水平的比例，并忽略中灰色中干擾最大的特征?SYN→??；在這個(gè)最早的階段，簽名匹配有太多其他解釋。在來(lái)自土庫(kù)曼斯坦（TM）、俄羅斯（RU）、伊朗（IR）和中國(guó)（CN）的所有連接中，大約80%、30%、40%和30%的連接與篡改簽名相匹配。數(shù)據(jù)還顯示，在之前沒(méi)有報(bào)告的地方，簽名匹配率很高。例如，來(lái)自秘魯（PE）和墨西哥（MX）的連接匹配率分別約為50%和25%；對(duì)這些國(guó)家/地區(qū)各個(gè)網(wǎng)絡(luò)的分析表明，一個(gè)可能的原因是移動(dòng)和蜂窩網(wǎng)絡(luò)中的零費(fèi)率，即ISP允許免費(fèi)訪問(wèn)某些資源（但不允許免費(fèi)訪問(wèn)其他資源）?？纯慈蚱骄揭韵碌膰?guó)家，英國(guó)（GB）、美國(guó)（US）和德國(guó)（DE）匹配簽名的連接數(shù)均在10%左右。

數(shù)據(jù)表明，連接篡改現(xiàn)象十分普遍，離很多用戶（甚至大多數(shù)用戶）都很近。從很多方面來(lái)看，這種現(xiàn)象比大多數(shù)人想象的還要近。為了解釋其中的原因，我們使用電話這種非常熟悉的通信工具來(lái)解釋連接篡改現(xiàn)象。

使用電話通話示例解釋篡改

連接篡改是第三方阻止訪問(wèn)特定內(nèi)容的一種方式。但是，第三方僅僅知道它想要阻止的內(nèi)容類型是不夠的。第三方只能通過(guò)名稱來(lái)阻止身份。

歸根結(jié)底，連接篡改是因意外才有可能發(fā)生的——這是協(xié)議設(shè)計(jì)的一個(gè)意外副作用。在互聯(lián)網(wǎng)上，最常見(jiàn)的身份是域名。在互聯(lián)網(wǎng)上的通信中，域名通常在TLS中的“服務(wù)器名稱指示（SNI）”字段中傳輸——以明文形式公開給所有人查看。

要理解這一點(diǎn)的重要性，首先要了解在沒(méi)有互聯(lián)網(wǎng)的情況下，人與人之間的通信中連接篡改是什么樣子的?；ヂ?lián)網(wǎng)本身的外觀和運(yùn)作方式與郵政系統(tǒng)非常相似，后者只依賴地址，而不依賴姓名。然而，大多數(shù)人使用互聯(lián)網(wǎng)的方式更像“普通的老式電話系統(tǒng)”，它需要姓名才能成功。

在電話系統(tǒng)中，人們首先撥打的是電話號(hào)碼，而不是稱呼姓名。只有在對(duì)方接聽(tīng)并且呼叫者聽(tīng)到聲音后，呼叫才會(huì)接通并可用。呼叫者只有在接通后才會(huì)詢問(wèn)姓名。呼叫在系統(tǒng)中表現(xiàn)為未標(biāo)識(shí)通信方的能量信號(hào)。最后，在通話結(jié)束后，需要重新?lián)艽螂娫挷拍茉俅芜M(jìn)行通信。

在互聯(lián)網(wǎng)上，客戶端（例如瀏覽器）會(huì)“建立連接”。這與電話呼叫者非常相似，客戶端向服務(wù)器號(hào)碼（即IP地址）發(fā)起連接請(qǐng)求。用于連接兩個(gè)設(shè)備的最古老的“面向連接”協(xié)議稱為傳輸控制協(xié)議（TCP）。域名的傳輸與連接建立無(wú)關(guān)，就像接聽(tīng)電話后再詢問(wèn)姓名一樣。連接由元數(shù)據(jù)“邏輯”標(biāo)識(shí)，而元數(shù)據(jù)并不標(biāo)識(shí)通信方。最后，每次訪問(wèn)網(wǎng)站時(shí)都會(huì)建立新的連接。

TCP連接與電話通話的比較

如果電話公司被要求阻止與某一方通話，會(huì)發(fā)生什么情況？一種選擇是修改或操縱電話簿，使呼叫者無(wú)法獲得他們撥打電話所需的電話號(hào)碼；這就是DNS過(guò)濾的本質(zhì)。第二種選擇是阻止對(duì)該電話號(hào)碼的所有呼叫，但這會(huì)無(wú)意中影響其他人，就像IP阻止那樣。

一旦電話響起，電話公司要知道正在呼叫誰(shuí)，唯一的辦法就是監(jiān)聽(tīng)通話，等待呼叫者說(shuō)“某某在嗎？”或“我可以和某某通話嗎？”。移動(dòng)電話也不例外。我們打給某個(gè)號(hào)碼，所找的那個(gè)人就會(huì)接電話，這只是一種期望，而并非現(xiàn)實(shí)。例如，父母可能會(huì)把號(hào)碼給自己的孩子，或者出租車公司可能會(huì)留下值班人員的手機(jī)號(hào)碼。因此，電話公司必須監(jiān)聽(tīng)。一旦聽(tīng)到某個(gè)名字，它就可以掛斷電話；雙方都不知道發(fā)生了什么——這就是互聯(lián)網(wǎng)連接篡改的定義。

就建立通信渠道而言，電話呼叫和TCP連接至少是相當(dāng)?shù)模踔量梢哉f(shuō)完全相同——尤其是因?yàn)橛蛎膫鬏斒桥c建立連接分開的。

同樣，在互聯(lián)網(wǎng)上，第三方了解連接的預(yù)期接收者的唯一方法是“查看”數(shù)據(jù)包傳輸時(shí)的內(nèi)部情況。電話公司必須監(jiān)聽(tīng)姓名，而互聯(lián)網(wǎng)上的第三方則等待看到它不喜歡的東西，通常是禁用的名稱。回想一下上面所說(shuō)的協(xié)議的意外副作用：名稱在SNI中可見(jiàn)，SNI是幫助加密數(shù)據(jù)通信所必需的。當(dāng)發(fā)生這種情況時(shí)，第三方會(huì)通過(guò)丟棄消息或注入特制的消息來(lái)導(dǎo)致通信雙方中止連接，從而使一個(gè)或兩個(gè)設(shè)備關(guān)閉連接。

觸發(fā)篡改的機(jī)制始于深度數(shù)據(jù)包檢測(cè)（DPI），這意味著查看地址以外的數(shù)據(jù)部分以及屬于連接的其他元數(shù)據(jù)?？梢钥隙ǖ卣f(shuō)，此功能不是免費(fèi)的。無(wú)論是ISP的路由器還是上級(jí)代理，DPI都是一項(xiàng)昂貴的操作，而且規(guī)模越大或速度越快，成本就越高。

最后值得一提的是，電話篡改的弱點(diǎn)同樣出現(xiàn)在連接篡改中。例如，盡管寫起來(lái)不同，但Jean和Gene的讀音對(duì)任何人來(lái)說(shuō)都無(wú)法區(qū)分。同樣，篡改Twitter的簡(jiǎn)稱“t.co”的連接也會(huì)影響“microsoft.com”——這種情況已經(jīng)發(fā)生了。

馬赫薩·阿米尼（Mahsa Amini）抗議期間的篡改實(shí)時(shí)圖像

在深入探討技術(shù)之前，Cloudflare的許多員工還有一個(gè)個(gè)人動(dòng)機(jī)。透明度很重要，這也是我們開始這項(xiàng)工作的原因，但在看到2022年伊朗馬赫薩·阿米尼抗議期間的數(shù)據(jù)后，我們才在內(nèi)部承諾在Radar上共享數(shù)據(jù)。

下圖是抗議活動(dòng)期間17天內(nèi)來(lái)自伊朗的連接情況。圖表追蹤了異常連接的單個(gè)信號(hào)，包括不同類型的連接篡改簽名。這些數(shù)據(jù)的日期早于Radar服務(wù)，因此我們選擇分享同行評(píng)審論文中的這一表示。這也是通過(guò)Radar共享數(shù)據(jù)的價(jià)值的第一個(gè)示例。

圖4：全國(guó)抗議期間伊朗的簽名匹配率。

（??軸是當(dāng)?shù)貢r(shí)間。）

從數(shù)據(jù)中，有兩個(gè)觀察結(jié)果引人注目。首先，抗議活動(dòng)開始前線條似乎很穩(wěn)定，抗議活動(dòng)開始后線條數(shù)量增加。其次，隨著時(shí)間的推移，線條之間發(fā)生變化，特別是淺灰色、深紫色和深綠色的線條?；叵胍幌?，每條線都是不同的篡改簽名，因此線條之間的變化表明了根本原因的變化——要么是起作用的機(jī)制，要么是調(diào)用它們的流量。

我們強(qiáng)調(diào)，簽名匹配本身并不意味著存在篡改。然而，在2022年伊朗的案例中，有公開報(bào)道稱其采取了各種形式的封鎖。當(dāng)時(shí)使用的方法，特別是基于服務(wù)器名稱指示（SNI）的內(nèi)容訪問(wèn)封鎖，之前也已得到充分記錄，并且與我們上圖所示的觀察結(jié)果相符。

那近期如何呢？下面我們可以看到從2023年8月到2024年8月的十二個(gè)月Radar視圖。每種顏色代表可能發(fā)生篡改的連接的不同階段。在過(guò)去的12個(gè)月中，伊朗的TCP連接異?？傮w上低于全球平均水平，但在淺藍(lán)色區(qū)域表示的異常部分中似乎明顯更高。此“Post ACK”通信階段通常與基于SNI的阻止有關(guān)。（在上圖中，相關(guān)簽名由深紫色和深綠色線表示。）此外，自2023年12月中旬以來(lái)不同情節(jié)線的比例變化表明，技術(shù)一直在隨著時(shí)間的推移而變化。

通過(guò)Cloudflare Radar

開放網(wǎng)絡(luò)測(cè)量社區(qū)的重要性

作為開放測(cè)量和研究社區(qū)重要性的證明，這項(xiàng)工作確實(shí)相當(dāng)于“站在巨人的肩膀上”。它是與馬里蘭大學(xué)、洛桑聯(lián)邦理工學(xué)院和密歇根大學(xué)的研究人員合作完成的，并非孤立存在。人們已經(jīng)付出了大量的努力來(lái)測(cè)量連接篡改，其中大部分來(lái)自審查測(cè)量社區(qū)。大部分工作由主動(dòng)測(cè)量構(gòu)成，研究人員在網(wǎng)絡(luò)和區(qū)域內(nèi)或沿網(wǎng)絡(luò)和區(qū)域制作和傳輸探測(cè)器，以識(shí)別阻止行為。毫無(wú)疑問(wèn)，主動(dòng)測(cè)量既有優(yōu)點(diǎn)也有缺點(diǎn)，如論文第2節(jié)所述。

與主動(dòng)測(cè)量相對(duì)應(yīng)的是被動(dòng)測(cè)量，也是我們項(xiàng)目的重點(diǎn)，它采用“觀察而不采取任何行動(dòng)”的方法。被動(dòng)測(cè)量有其自身的優(yōu)點(diǎn)和缺點(diǎn)，但至關(guān)重要的是，它依賴于擁有良好的有利位置，例如大型網(wǎng)絡(luò)運(yùn)營(yíng)商。主動(dòng)和被動(dòng)測(cè)量在結(jié)合使用時(shí)最有效，在本文所討論的情況中，有助于更全面地了解連接篡改對(duì)用戶的影響。

最重要的是，在進(jìn)行任何類型的測(cè)量時(shí)，都必須非常小心地了解和評(píng)估測(cè)量的安全性，因?yàn)閷?duì)人員和網(wǎng)絡(luò)施加的風(fēng)險(xiǎn)通常是間接的或隱藏的。

我們數(shù)據(jù)的局限性

我們毫不懷疑對(duì)連接篡改保持透明的重要性，但我們也需要明確從數(shù)據(jù)中獲取的見(jiàn)解的局限性。作為Cloudflare網(wǎng)絡(luò)（且僅限Cloudflare網(wǎng)絡(luò)）連接的被動(dòng)觀察者，我們只能看到或推斷以下內(nèi)容：

連接被篡改的跡象，但不知道發(fā)生的位置?？蛻舳藨?yīng)用和服務(wù)器系統(tǒng)之間的任何軟件或設(shè)備都可能篡改連接。這個(gè)范圍涵蓋專用系統(tǒng)、企業(yè)或家庭寬帶路由器中的防火墻，以及安裝在家庭或?qū)W校計(jì)算機(jī)上的保護(hù)軟件。我們所能推斷的只是連接的起始位置（盡管這受限于互聯(lián)網(wǎng)設(shè)計(jì)固有的地理位置不準(zhǔn)確性）。

（通常，但并非總是）是什么觸發(fā)了篡改，但不知道原因。通常，篡改系統(tǒng)由域名、關(guān)鍵字或正則表達(dá)式觸發(fā)。通過(guò)足夠的重復(fù)和手動(dòng)檢查，可能可以識(shí)別出篡改的可能起因，但無(wú)法識(shí)別原因。許多篡改系統(tǒng)設(shè)計(jì)容易產(chǎn)生意想不到的后果，上面提到的t.co示例就是其中之一。

確實(shí)受影響的人和事，但不包括可能受影響的人和事。作為被動(dòng)觀察者，我們能做出的推斷種類有限。例如，在1001個(gè)與example.com的連接中，有1000個(gè)可觀察到篡改，這表明下一次連接嘗試也可能發(fā)生篡改。然而，這并沒(méi)有說(shuō)明與another-example.com的連接相關(guān)的任何信息。

數(shù)據(jù)，數(shù)據(jù)，數(shù)據(jù)：從干擾信息中提取信號(hào)

如果您只是想獲取和使用Radar上的數(shù)據(jù)，請(qǐng)參閱我們的“操作方法”指南。若想要了解更多，那讓我們來(lái)了解一下數(shù)據(jù)本身。

這項(xiàng)工作的重點(diǎn)是TCP。在我們的數(shù)據(jù)中，第三方可以使用兩種機(jī)制來(lái)強(qiáng)制關(guān)閉連接：丟棄數(shù)據(jù)包以引起超時(shí)，或注入偽造的TCP RST數(shù)據(jù)包，每種機(jī)制都有各種部署選擇。個(gè)別篡改簽名可能反映了這些選擇。需要了解的是，正常的TCP關(guān)閉是使用FIN數(shù)據(jù)包啟動(dòng)的。

連接篡改簽名

我們的檢測(cè)機(jī)制會(huì)根據(jù)一組簽名來(lái)評(píng)估連接中的數(shù)據(jù)包集，以判斷是否存在連接篡改。這些簽名是根據(jù)之前工作中識(shí)別出的簽名手工生成的，并通過(guò)分析我們歸類為異常（即提前關(guān)閉的連接，以及在客戶端發(fā)出不到10個(gè)數(shù)據(jù)包時(shí)，以RST數(shù)據(jù)包或超時(shí)的方式不合時(shí)宜地關(guān)閉的連接）的Cloudflare網(wǎng)絡(luò)連接樣本生成的。我們分析了這些樣本，發(fā)現(xiàn)19種模式占樣本中所有可能被篡改的連接的86.9%，如下表所示。

表1：我們通過(guò)全球被動(dòng)測(cè)量識(shí)別的一組篡改簽名。

為了幫助推斷篡改情況，我們還根據(jù)上述19個(gè)簽名出現(xiàn)的連接生命周期階段對(duì)其進(jìn)行了分類。每個(gè)階段都暗示了有關(guān)中間盒的一些信息，如下所述，并附有相應(yīng)的序列圖：

-（a）Post-SYN（握手過(guò)程中）：篡改可能由目標(biāo)IP地址觸發(fā)，因?yàn)橹虚g盒可能沒(méi)有看到應(yīng)用數(shù)據(jù)（數(shù)據(jù)通常在握手完成后傳輸）。

-（b）Post-ACK（握手后緊接著）：連接建立后立即被強(qiáng)制關(guān)閉，未看到任何數(shù)據(jù)。中間盒甚至很可能已經(jīng)看到了數(shù)據(jù)包；例如HTTP中的主機(jī)標(biāo)頭或TLS中的SNI字段。

-（c）Post-PSH（第一個(gè)數(shù)據(jù)包之后）：中間盒肯定已經(jīng)看到第一個(gè)數(shù)據(jù)包，因?yàn)榉?wù)器已經(jīng)接收到它。中間盒可能一直在等待帶有PSH標(biāo)志的數(shù)據(jù)包，該標(biāo)志通常設(shè)置為指示數(shù)據(jù)包中的數(shù)據(jù)應(yīng)在收到后立即傳送給應(yīng)用，不得延遲。這里的中間盒可能是旁觀者攻擊（monster-on-the-side），因?yàn)樗试S有問(wèn)題的數(shù)據(jù)包到達(dá)目的地。

-（d）流程后期（多個(gè)數(shù)據(jù)包后）：在連接的后期篡改（不是緊接在第一個(gè)數(shù)據(jù)包之后，但仍在前10個(gè)數(shù)據(jù)包內(nèi)）。TLS中加密數(shù)據(jù)的普遍性使得這一階段成為最不容易發(fā)生篡改的階段?？赡艿挠|發(fā)因素是在（HTTP）連接后期以明文形式出現(xiàn)的關(guān)鍵字，或者企業(yè)代理和家長(zhǎng)保護(hù)軟件之類的產(chǎn)品。這些軟件可以查看加密流量，并在遇到某些關(guān)鍵字時(shí)重置連接。

考慮其他解釋

我們?nèi)绾未_信上述簽名能夠檢測(cè)到中間盒篡改，而不僅僅是非典型的客戶端行為？被動(dòng)測(cè)量的一個(gè)挑戰(zhàn)是我們無(wú)法完全了解連接到我們網(wǎng)絡(luò)的客戶端，因此很難（甚至不可能）獲得絕對(duì)肯定的結(jié)果。我們會(huì)尋找強(qiáng)有力的篡改證據(jù)，而這必須首先從識(shí)別誤報(bào)開始。

我們知道以下誤報(bào)來(lái)源很難與真正的篡改來(lái)源區(qū)分開來(lái)。除最后一個(gè)之外，其他所有誤報(bào)都發(fā)生在連接的前兩個(gè)階段，即在接收數(shù)據(jù)包之前。

-掃描程序是客戶端應(yīng)用，用于探測(cè)服務(wù)器以引出響應(yīng)。一些掃描程序軟件使用標(biāo)頭中的固定位進(jìn)行自我識(shí)別，這有助于我們進(jìn)行過(guò)濾。例如，我們發(fā)現(xiàn)Zmap約占所有?SYN→RST?簽名匹配的1%。

-SYN洪水攻擊是另一個(gè)可能的誤報(bào)來(lái)源，尤其是對(duì)于Post-SYN連接階段的簽名，例如?SYN→??和?SYN→RST?簽名。這些不太可能出現(xiàn)在我們的數(shù)據(jù)集收集中，數(shù)據(jù)集收集發(fā)生在DDoS防護(hù)系統(tǒng)之后。

-Happy Eyeballs是雙棧客戶端常用的一種技術(shù)，客戶端會(huì)發(fā)起與服務(wù)器的IPv6連接，并在延遲一段時(shí)間以支持IPv6后，再建立IPv4連接?？蛻舳藭?huì)保留第一個(gè)成功的連接并丟棄另一個(gè)。停止傳輸或使用RST而非FIN關(guān)閉連接的客戶端會(huì)顯示在數(shù)據(jù)中，與?SYN→RST?簽名相匹配。

-瀏覽器觸發(fā)的RST可能出現(xiàn)在連接的任何階段，但尤其適用于在連接后期（多個(gè)數(shù)據(jù)包之后）匹配的簽名。例如，它可能由用戶關(guān)閉瀏覽器選項(xiàng)卡觸發(fā)。然而，與有針對(duì)性的篡改不同，源自瀏覽器的RST不太可能偏向特定服務(wù)或網(wǎng)站。

我們?nèi)绾螀^(qū)分合法客戶端發(fā)起的誤報(bào)和第三方篡改？我們尋求一種基于證據(jù)的方法來(lái)區(qū)分篡改簽名和數(shù)據(jù)集內(nèi)的其他信號(hào)。為此，我們要利用數(shù)據(jù)包標(biāo)頭中的各個(gè)位。

簽名驗(yàn)證——讓數(shù)據(jù)說(shuō)話

單獨(dú)的簽名匹配不足以做出正確的判斷。與此同時(shí)，我們可以通過(guò)檢查總體連接來(lái)找到進(jìn)一步支持其準(zhǔn)確性的證據(jù)——如果原因是篡改，并且篡改是有針對(duì)性的，那么一定還有其他共同的模式或標(biāo)記。例如，我們預(yù)計(jì)瀏覽器行為會(huì)出現(xiàn)在世界各地；然而，正如我們上面所展示的，僅在某些地方或某些時(shí)間間隔與連接匹配的簽名就會(huì)凸顯出來(lái)。

類似地，我們期望連接內(nèi)連續(xù)數(shù)據(jù)包中的某些特征也能凸顯出來(lái)，事實(shí)上它們也確實(shí)如此，即IP標(biāo)頭中的IP-ID和TTL字段。

IPv4數(shù)據(jù)包標(biāo)頭中的IP-ID（IP標(biāo)識(shí)）字段通常是每個(gè)連接的固定值，通常由客戶端針對(duì)其發(fā)送的每個(gè)后續(xù)數(shù)據(jù)包進(jìn)行遞增。換句話說(shuō)，我們預(yù)計(jì)從同一客戶端發(fā)送的后續(xù)數(shù)據(jù)包中IP-ID值的變化很小。因此，在正常連接中，后續(xù)數(shù)據(jù)包之間IP-ID值的大幅變化是意料之外的，可以用作數(shù)據(jù)包注入的指標(biāo)。這正是我們?cè)跇?biāo)記為（a）的上圖中看到的一組選定簽名的情況。

生存時(shí)間（TTL）字段為檢測(cè)注入的數(shù)據(jù)包提供了另一個(gè)線索。同樣，大多數(shù)客戶端實(shí)施也對(duì)連接上發(fā)送的每個(gè)數(shù)據(jù)包使用相同的TTL，通常最初設(shè)置為64或128，并由數(shù)據(jù)包路由上的每個(gè)路由器遞減。如果RST數(shù)據(jù)包的TTL與連接中的其他數(shù)據(jù)包不相同，則表明它是注入的。請(qǐng)看上圖（b），我們可以看到TTL的明顯差異，表明存在第三方。

我們強(qiáng)烈建議讀者閱讀這些內(nèi)容背后的細(xì)節(jié)，了解它們的意義和原因。IP-ID和TTL最大差值較大的連接為流量篡改提供了積極證據(jù)，但沒(méi)有這些信號(hào)并不一定意味著沒(méi)有發(fā)生篡改，因?yàn)楸娝苤?，一些中間盒會(huì)從連接中的原始數(shù)據(jù)包中復(fù)制IP標(biāo)頭值，包括IP-ID和TTL。我們的重點(diǎn)在于負(fù)責(zé)任地確保我們的數(shù)據(jù)集具有指示價(jià)值。

最后還有一點(diǎn)需要注意：雖然我們的篡改簽名可以捕獲多種形式的篡改，但仍有可能出現(xiàn)漏報(bào)，即連接已被篡改但未被我們檢測(cè)到。一些示例是在前10個(gè)數(shù)據(jù)包之后終止的連接（因?yàn)槲覀儾](méi)有對(duì)這一部分進(jìn)行采樣）、FIN注入（RST注入的不太常見(jiàn)的替代方案）或所有數(shù)據(jù)包在到達(dá)Cloudflare服務(wù)器之前被丟棄的連接。我們的簽名也不適用于基于UDP的協(xié)議，例如QUIC。我們希望將來(lái)擴(kuò)大連接篡改簽名的范圍。

案例研究

為了了解這在Cloudflare網(wǎng)絡(luò)上的表現(xiàn)，下面我們提供了與連接篡改的OONI報(bào)告一致的TCP連接異常的更多示例。

如需了解此項(xiàng)研究的更多見(jiàn)解，請(qǐng)參閱完整的技術(shù)論文和演示文稿。對(duì)于下文未列出的其他地區(qū)和網(wǎng)絡(luò)，請(qǐng)參閱Radar上的新數(shù)據(jù)。

巴基斯坦

來(lái)自巴基斯坦內(nèi)部的報(bào)告顯示，2024年8月用戶的互聯(lián)網(wǎng)體驗(yàn)發(fā)生了變化?？匆幌?月初的兩個(gè)星期時(shí)間，從2024年8月9日開始，Post-ACK連接異常發(fā)生了顯著變化。

通過(guò)Cloudflare Radar

8月9日的Post-ACK峰值幾乎完全歸因于AS56167（Pak Telecom Mobile Limited），如下面第一張圖所示，其中Post-ACK異常從對(duì)于所有連接不足5%，躍升至70%以上，并且此后一直保持高位。相應(yīng)地，我們看到從AS56167中的客戶端到達(dá)Cloudflare網(wǎng)絡(luò)的成功HTTP請(qǐng)求數(shù)量顯著減少（如下面第二張圖所示），這證明連接正在中斷。這個(gè)巴基斯坦的例子強(qiáng)調(diào)了確鑿報(bào)告和觀察結(jié)果的重要性，在Radar數(shù)據(jù)集發(fā)布中對(duì)此進(jìn)行了更詳細(xì)的討論。

通過(guò)Cloudflare Radar

通過(guò)Cloudflare Radar

坦桑尼亞

2024年4月的OONI報(bào)告討論了坦桑尼亞的有針對(duì)性的連接篡改行為。報(bào)告指出，在客戶端觀察到這種阻止，因?yàn)樵赥LS握手期間的Client Hello消息之后連接超時(shí)，這表明中間盒正在丟棄包含Client Hello消息的數(shù)據(jù)包。在服務(wù)器端，以這種方式被篡改的連接將顯示為Post-ACK超時(shí)，因?yàn)榘珻lient Hello消息的PSH數(shù)據(jù)包永遠(yuǎn)不會(huì)到達(dá)服務(wù)器。

查看下面淺藍(lán)色部分中表示的Post-ACK數(shù)據(jù)，我們發(fā)現(xiàn)了匹配的證據(jù)：來(lái)自坦桑尼亞的所有新TCP連接中，近30%都顯示為Post-ACK異常。進(jìn)一步細(xì)分（下圖中未顯示），大約三分之一是由于超時(shí)，與上面的OONI報(bào)告一致。其余部分是由于RST。

通過(guò)Cloudflare Radar

埃塞俄比亞

埃塞俄比亞是另一個(gè)之前報(bào)告過(guò)連接篡改的地區(qū)。與此一致，我們發(fā)現(xiàn)埃塞俄比亞網(wǎng)絡(luò)中Post-PSH TCP異常的發(fā)生率較高。我們的內(nèi)部數(shù)據(jù)顯示，這里的大多數(shù)Post-PSH異常都是由RST引起的，不過(guò)超時(shí)也很普遍。

通過(guò)Cloudflare Radar

從位于埃塞俄比亞的IP地址到達(dá)Cloudflare服務(wù)器的流量大部分來(lái)自AS24757（Ethio Telecom），如下面第一張圖所示，因此其數(shù)據(jù)與全國(guó)范圍內(nèi)的連接異常分布非常吻合也就不足為奇了。來(lái)自AS328988（SAFARICOM TELECOMMUNICATIONS ETHIOPIA PLC）的Post-PSH連接數(shù)量（如下面第二張圖所示）的比例更高，占該網(wǎng)絡(luò)所有連接的33%以上。

通過(guò)Cloudflare Radar

通過(guò)Cloudflare Radar

反思現(xiàn)在，以促進(jìn)更具韌性的未來(lái)

連接篡改是一種以各種形式部署在互聯(lián)網(wǎng)上的阻止機(jī)制。盡管我們已經(jīng)開發(fā)出各種方法來(lái)幫助在全球范圍內(nèi)檢測(cè)和了解這種行為，但這種體驗(yàn)就像電話中斷一樣，因人而異。

連接篡改也可能因意外而發(fā)生。之所以能成功，是因?yàn)橛蛎悦魑男问娇梢?jiàn)。但情況可能并非總是如此。例如，Encrypted Client Hello（ECH）是一種加密SNI字段的新興構(gòu)建塊。