Tor隱匿服務可擴展性研究

韓越++陸天波

摘要：隨著網絡服務的發展與人們對隱私要求的日益提高。在提供用戶通信匿名的基礎上，產生了保護服務器匿名性的需求。第二代洋蔥路由The Second Generation Onion Router（Tor）的隱匿服務功能就完美地實現了這樣的需求。然而自其提出至今已逾10年，其隱匿服務技術并未得到良好的發展。近年來，隨著網絡服務規模的不斷擴大，在Tor網絡上架設大型網絡服務，或將網絡服務遷移至Tor網絡中的需求逐漸增多。然而，在隱匿服務設計之初，由于其實現只考慮了單核單線程的情況，并未能充分利用現在流行的多核架構，也不支持負載均衡等技術。因而，其可擴展性成為了服務提供者需要解決的首要問題。本文通過使用相同的主機名與私鑰運行多個隱匿服務實例來解決其可擴展性問題，并使用Shadow在離線環境下進行仿真，最終通過實驗分析了這種方式對Tor隱匿服務帶來的性能提升及可能存在的問題。

關鍵詞：計算機網絡；匿名通信；Tor；隱匿服務

中圖分類號：TP393

文獻標識碼：A

DOI：10.3969/j.issn.1003-6970.2016.02.017

引言

近年來網絡服務發展迅猛，網絡應用中用戶對個人隱私及信息安全的要求日益提升，進而產生了保護網絡服務隱匿性的需求。The Second Generation Onion Router（Tor）匿名通信系統被稱為第二代洋蔥路由系統，是目前最為流行的匿名通信解決方案。它能夠在抵抗多種被動或主動攻擊的同時，保持良好的性能。Tor的低通信延遲、高匿名性、易使用、易部署等諸多特點使得它在近年來得到飛速發展。現今，全球已有超過6000個Tor網絡結點，超過200萬人使用Tor網絡進行通信。

Tor于2004年便提出了隱匿服務（Hidden Service）的概念。自此，Tor不僅可以支持客戶端用戶完成基本的匿名通信服務，還一定程度上確保了隱匿服務提供方的匿名。通過使用Tor網絡，用戶可以匿名地訪問該隱匿服務，而隱匿服務提供方也可以維護地理位置不可知的服務器。 用戶需要通過Tor指定的頂級域名（Top LevelDomain，TLD）.onion訪問隱匿服務。Tor網絡可以識別自己的TLD，并自動連接到該隱匿服務。然后，隱匿服務會將收到的請求交由普通的服務器軟件進行處理。

雖然Tor的隱匿服務發布至今已逾10年，但其發展遠沒有Tor本身那樣繁盛。隱匿服務現在處于一個尷尬的境遇。它擁有一定數量的忠實用戶群體，但很少有研究學者來專門關注它。這使得Tor隱匿服務仍有許多問題需要研究、實驗，以增強其有效性及安全性。且隨著在Tor網絡上架設大型網絡服務，或將網絡服務遷移至Tor網絡中的需求逐漸增多，隱匿服務的可擴展性自然成為了其需首要解決的問題之一。

1 Tor隱匿服務概述

1.1 Tor隱匿服務基本流程

當某用戶希望對外提供Web服務或即時通信服務時，Tor的隱匿服務可以幫助服務提供者隱藏其物理地址。通過提供“集合結點”（Rendezvous Point，RP），其他用戶可以在對服務提供者除域名信息外一無所知的情況下，順利訪問其隱匿服務。

第一步：服務提供方為了能夠在Tor網絡中匿名地對外提供服務，需要對Tor網絡聲明其存在，將一些必要的信息通報給Tor網絡。因此，在正式提供服務之前，服務提供方需要隨機選取Tor網絡中的幾個中繼結點，與之建立連接，傳遞服務的公鑰，并請求這些中繼結點作為該隱匿服務的介紹結點（Introduction Point，IP）。

如圖1所示，隱匿服務提供方Bob向IPI，IP2，IP3分別建立3條匿名鏈路，并請求他們成為自己的介紹結點。由于它們之間建立的是Tor匿名鏈路，而非直連，IPI，IP2，IP3三者只知道其服務相關的公鑰，并不知道服務提供方Bob的身份或IP地址。

第二步：如圖2所示，Bob需要為其提供的隱匿服務生成一個隱匿服務描述符。

該描述符之中應包含：隱匿服務對應的公鑰，隱匿服務的介紹結點列表，以及利用隱匿服務私鑰對該描述符前述部分的簽名。

一旦成功生成了隱匿服務描述符，它會被上傳到響應的隱匿服務目錄服務器以供其他用戶查找。其查找索引形式為“XYZ.omon”，其中XYZ為根據隱匿服務公鑰生成的隱匿服務名，一般由16個英文字母組成。至此，隱匿服務已被成功部署，等待提供服務。

第三步：如圖3所示，當一個用戶想要連接到一個隱匿服務時，他需要事先通過其他途徑獲得該隱匿服務對應的洋蔥地址，即前述的“XYZ.omon”。得到該地址后，用戶通過分布式哈希表詢問對應的隱匿服務目錄服務器來獲得與之對應的隱匿服務描述符。若存在該描述符，那么用戶就可以知曉匿名服務的介紹結點列表以及其所使用的公鑰信息。

于此同時，用戶隨機挑選一個Tor網絡中的中繼結點，并通過告知該結點一個一次性秘密信息，來請求其作為該用戶的集合結點RP。

第四步：當用戶成功獲取了隱匿服務的描述符，并設置了集合結點后，用戶需要再構造一個由隱匿服務公鑰加密的消息。該消息需包含：集合結點的地址，以及先前預先協商完成的一次性秘密信息。該消息將通過Tor鏈路被發送至隱匿服務的某一個介紹結點，而介紹結點則會將該消息回傳給隱匿服務提供者。如圖4所示，隱匿服務提供方Bob與請求方Alice均通過Tor鏈路來進行數據通信，雙方的身份信息都不會被泄露，從而保證了各自的匿名。

第五步：隱匿服務提供方Bob對用戶Alice發送來的服務相關消息進行解密，并獲得其中的集合結點地址及一次性秘密信息。隨后，Bob向集合結點建立匿名鏈路，并向其發送接收到的一次性秘密信息，如圖5所示。

第六步：集合結點通知隱匿服務請求者Alice，自己已成功與隱匿服務提供方建立起鏈接。Alice確認該消息后，便可以利用通過集合結點建立起的匿名鏈路進行類似于常規Tor網絡通信的匿名通信。對于隱匿服務提供方亦是如此。

該匿名鏈路與常規Tor網絡中的匿名鏈路的主要差別在于，隱匿服務中的匿名鏈路大多由6個結點組成，長度是常規匿名鏈路的2倍。且在該鏈路中，集合結點明確知道自己的身份。

在整個隱匿服務協議的運行過程之中，協議力求保證通信雙方的匿名性。協議中所選用的IPI，IP2，IP3，以及RP均無法確切得知通信雙方的身份及地理位置，匿名性由Tor鏈路的特性（單個路由無法得知整條鏈路）提供保障。

1.2 Tor隱匿服務基本流程

1.2.1 隱匿服務目錄服務器與分布式哈希表

為了連接到特定的隱匿服務，用戶客戶端需要對該隱匿服務的相關信息進行查詢。在Tor網絡中，該查詢服務的實現原理類似于分布式哈希表，可以讓隱匿服務的描述符在Tor網絡中被結點轉發傳播。

權威目錄服務器（Directory authorities）會對運行超過24小時的結點進行投票，來決定該結點是否有成為隱匿服務目錄服務器的資格。這樣會確保只有高可靠性的結點才會被選作隱匿服務目錄服務器結點。一旦一個中繼結點被授予HSDir標記，就意味著它可以作為隱匿服務目錄服務器，有能力處理隱匿服務描述符，并允許用戶對其進行上傳或下載。

一個隱匿服務的描述符會被發布到哪臺隱匿服務目錄服務器上是確定的。因此，當一個用戶想訪問一個特定的隱匿服務時，它可以通過計算得知自己需要向哪臺隱匿服務目錄服務器去請求所需的隱匿服務描述符。在同一時刻，網絡中會有6臺隱匿服務目錄服務器持有對同一特定隱匿服務的描述符。并且，每個客戶端實例也都會保存一個當前網絡中隱匿服務目錄服務器列表的子集。

在最初的實現中，Tor網絡中有一組特定的目錄服務器用于存儲網絡中隱匿服務的描述符。這種實現不能抵抗單點失效，其可擴展性、可用性、抗審查能力等方面也都存在著問題。而現在的設計則提供了更好的可用性及可擴展性。

分布式哈希表的實現形式使得隱匿服務描述符的存儲沒有最初設計中那樣集中。對于特定的隱匿服務，如果持有其隱匿服務描述符的一臺隱匿服務目錄服務器發生故障，網絡中還會有其他的隱匿服務目錄服務器正常工作，便不會導致隱匿服務的描述符獲取失敗。并且，這樣的設計提高了攻擊者針對隱匿服務目錄服務器的攻擊難度。

1.2.2 隱匿服務描述符的創建及發布

Tor隱匿服務首先產生兩個相同的描述符，不同的描述符會根據其描述符ID與得到的簽名進行區分。

隱匿服務描述符ID（Descriptor-id）的計算方法如下：

公式（l）中，H為一個安全的哈希函數H，連接起后述多個值。

pennanent-id為隱匿服務公鑰截斷前80位的哈希結果。

time-period為隱匿服務生效時間的Unix時間戳。

descriptor-cookie是一個可選參數，為一個客戶端和一個隱匿服務之間用于認證互通而共同協商的秘密信息。

replica則標識了哪兩個副本被建立，它決定了描述符會發布于分布式哈希表中的位置，下文會針對此作詳述。

完成了描述符的創建后，隱匿服務會發布每個副本到3個隱匿服務目錄服務器，即共有6臺隱匿服務目錄服務器會持有該隱匿服務的描述符。一個隱匿服務會去權威目錄服務器下載Tor網絡結點數據，保留HSDir標識的結點信息，并按結點的指紋信息（fingerprint），即結點公鑰的哈希值排列成環狀（也稱作哈希環）。順時針順序，取指紋信息與描述符指紋相近的三個中繼結點作為其隱匿服務目錄服務器結點，保存其隱匿服務描述符。隱匿服務描述符的兩個副本都遵循同樣的規則。如上圖6所示，該匿名服務的兩個描述符分別選中了nl，n2，n3和kl，k2，k3作為其隱匿服務目錄服務器結點。這種規則使得兩個指向同一隱匿服務的描述符，能夠在Tor網絡中得到更均勻的分布，從而提高其可用性。

當隱匿服務目錄服務器接收到一個隱匿服務描述符時，首先要驗證其真實性。它會使用隱匿服務的公鑰來驗證其描述符中的簽名信息，并將結果與其描述符ID做比對。另外，如果該隱匿服務目錄服務器上已經存儲了同一隱匿服務的描述符，則會對其進行更新。

通常情況下，隱匿服務會每隔一小時重新發布它的描述符。另外，在檢測到隱匿服務目錄服務器發生變更或介紹結點失效時，隱匿服務也會更新其描述符至對應的隱匿服務目錄服務器。

1.2.3 隱匿服務描述符的獲取

對于一個想要連接到隱匿服務的客戶端，它需要先去獲取隱匿服務對應的有效描述符。

當客戶端持有該隱匿服務描述符的緩存時，它會嘗試直接與之建立連接。如若失效，則需要去重新獲取。

與隱匿服務發布其描述符類似，客戶端首先通過權威目錄服務器下載Tor網絡結點的數據，并獲取其中包含HSDir標識的結點，根據其指紋排列成環。然后，客戶端會根據欲連接的隱匿服務的ID來計算可能含有該隱匿服務描述符的隱匿服務目錄服務器地址集合。該集合一般含有6個結點，客戶端會隨機選擇其一，對隱匿服務描述符進行獲取。如若失敗，則會依次嘗試。

2 可擴展的Tor隱匿服務

在最初的設計實現中，Tor的隱匿服務并非針對多服務器系統，也沒能充分利用多處理器架構，或提供負載均衡功能。而隨著近年來網絡服務的迅猛發展，在Tor網絡上架設大型網絡服務的需求逐漸增多。因此，其可擴展性成為了服務提供者需要解決的首要問題。

目前，隱匿服務并不能很方便地進行擴展。大型網站很難在不改變其現有體系結構的情況下，以隱匿服務的方式遷移到Tor網絡中。這其中最主要的問題便是，隱匿服務需要通過介紹結點接入隱匿服務。一個隱匿服務描述符只能對應3到10個介紹結點。而大多介紹結點只是普通的中繼結點，有著有限的帶寬，并不善于處理大規模的流量。

其次，隱匿服務本身缺乏對負載均衡的支持。雖然我們可以使用TCP/HTTP負載均衡工具（例如HAProxy等）來進行初步的負載均衡，但并沒有類似DNS輪詢這樣的技術來將客戶端分配到不同的IP上。我們可以設立很多相同的隱匿服務當作“子服務“，通過增加描述符數量來達到類似的效果。這樣的方式雖然在結果上有一定的吸引力，但同時又會引入更多的問題，比如子服務間的通信、長期密鑰的存儲、介紹結點的分配等等。

綜上所述，對Tor隱匿服務可擴展性的改進大體可以通過兩種方式解決。一是針對提供隱匿服務的服務器自身的改進。我們可以簡單地加強其硬件等資源，使其擁有諸如更多的內存，更快的CPU；或者改進其體系架構，使其更有效地利用現有資源，以更低的成本完成性能的調優。二是針對隱匿服務工作方式的特殊性，在請求來臨時，將不同請求派發到指向不同實例的介紹結點，進行有效的流量分發、使負載均衡。

在這里，我們重點關注后者。在接下來的實驗中，我們會使用相同的主機名和公鑰運行多個隱匿服務實例，通過實驗來探究這種方式對提升隱匿服務性能帶來的收益，并進一步探究運行的實例個數對提升性能的影響。

3 實驗

3.1 實驗工具

Tor網絡當前擁有數千個結點，用戶數量也在與日俱增。如何在Tor網絡上進行相關實驗成為了一個較為重要的問題。而局域網仿真，即是解決該問題的一個重要方法。

Shadow堤一個離散事件網絡仿真器。它允許用戶在其上建立、仿真一個含上千結點的大型Tor網絡，以獲得網絡負載和性能相關的重要參數。同時，Shadow也是一個重要的調試工具，在其上可以運行關于Tor的相關確定性實驗，在學術界廣受追捧。Shadow在現有版本中已經直接附帶了Tor網絡的幾種基本配置，用以幫助用戶迅速地實現Tor網絡仿真的起步工作。

Shadow的Tor插件允許用戶通過XML文件來定義、配置其網絡拓撲和網絡流量，甚至還可以定義Tor的相關配置文件，比如各種結點配置等。在實驗結束時，Shadow還能產出詳細的日志文件，描述了各結點CPU、內存使用情況，生成、接收到的流量等一系列具體信息。

Shadow附帶了很多實用的日志分析工具，并支持自定義生成實驗結果的圖表。后文中，我們通過在實驗中監控隱匿服務結點的使用情況來確定其性能，圖表結果大多來源于此。

3.2 實驗設計

接下來，我們將進行兩組實驗，一是通過負載均衡實驗來評估這種擴展方式的性能，二是通過故障之后的服務切換來衡量其可靠性。

在負載均衡實驗中，我們會記錄各個隱匿服務實例對客戶端請求的響應數據，也會探究隱匿服務使用的實例數量是否會對整個系統的性能產生影響。而在故障轉移實驗中，則會重點關注在某實例發生故障后，流量重新建立的時間開銷，來衡量隱匿服務的可靠性。

實驗中，我們選用Shadow對Tor網絡進行仿真，并保證實驗環境的一致。本文所有實驗皆運行于同一臺8G內存的筆記本，且Shadow中對Tor網絡拓撲結構的設置除隱匿服務結點外完全相同。每個實驗都會仿真5000Ticks（Shadow中的時間計量單位）。由于計算機內存限制，網絡拓撲由一個權威目錄服務器、30個中繼結點、10個出口結點、30個隱匿服務客戶端及若干隱匿服務服務器組成。

實驗將模擬一個簡化的Tor網絡，所有隱匿服務客戶端都會重復地向同一個.omon地址發送數據包。在負載均衡實驗中，所有的隱匿服務服務器會在實驗周期中正常運行；而在故障轉移實驗中，一臺隱匿服務服務器會在3000ticks時停止服務。

在這兩個實驗中，我們會分別運行1、2、3、6個隱匿服務實例，以觀察運行更多的實例是否可以得到更好的性能與可靠性，或者反之亦然。

3.3 實驗結果

3.3.1 負載均衡實驗

圖7至圖10展示了隱匿服務實例個數分別為1、2、3、6時，各隱匿服務實例接收流量隨時間變化的曲線。

如圖8所示，在只包含2個隱匿服務實例的情況下，其中一個隱匿服務實例“hiddenserverl-11.0.0.72”接受了約360MiB的請求流量，占總流量的56%，而另一個實例“hiddenserver2-11.0.0.73”占據44%。可見，流量確實被分發到兩個實例上，且較為均勻。從而，我們通過實驗也證實了，通過運行多個Tor隱匿服務實例，確實可以起到簡單的負載均衡效果，來增加其性能。

但是隨著實驗中我們對隱匿服務實例數量的增加，流量分配開始變得不均。如圖9所示，實驗在3個隱匿服務實例下進行，其中一隱匿服務“hiddenserver3-11.0.0.74”被分配到了約330MiB的流量，約占整體的50%，而其他兩個隱匿服務實例，“hiddenserverl-11.0.0.72”與“hiddenserver2-11.0.0.73”，分別只分配到約32%和18%的流量。

我們再觀察圖10，在運行6個隱匿服務實例的實驗中，只有其中4個隱匿服務實例接收到了流量，另外兩個實例“hiddenserver5-11.0.0.76”與“hiddenserver6-11.0.0.77”所接收到的流量占比甚至不到總量的0%。

由此可見，隨著運行隱匿服務實例個數的增多，這種通過簡單運行多實例的方式帶來的負載均衡效果將越來越差。

對比這些隱匿服務各自發布描述符的時間，我們猜測，隱匿服務實例接收到的流量與匿名描述符發布時間也有著緊密的聯系，最先發布描述符的隱匿服務實例往往會接收到更多的流量。

再來看圖11，它展示了分別運行1、2、3、6個隱匿服務實例的情況下，隱匿服務客戶端接收固定字節文件（1048576 bytes）所消耗時間的曲線。我們可以明顯發現，運行多個實例的隱匿服務完成下載的時間大幅少于單實例。因此，我們可以得出結論，一個隱匿服務運行更多的實例，會讓用戶得到更快的響應時間，性能得到顯著提升。

3.3.2 失效轉移實驗

在失效轉移實驗中，我們同樣會分別運行具有2、3、6個實例的隱匿服務，但會在各實驗大約一半的時間時（3000ticks），關閉其中一個隱匿服務實例。

按照Tor隱匿服務協議，當這一情況發生時，原本連接到那臺失效的隱匿服務實例上的客戶端會查詢之前獲取到的隱匿服務描述符緩存，選擇另一個介紹結點，試圖與隱匿服務恢復連接。直到檢測到所有介紹結點皆失效，才會到目錄服務器重新獲取新的描述符，繼而連接到隱匿服務（另外一個有效的實例上）。

圖12至圖14展示了各隱匿服務實例接收流量隨時間變化的曲線。后綴帶有“will_stop”的隱匿服務實例會在3000 ticks處關閉，表現為3000 ticks后該實例服務的流量將不再變化，如圖中水平直線所示。

觀察圖12、圖13，當一臺隱匿服務失效后，其他的隱匿服務很快便承擔了其流量。究其原因，在這兩個實驗中，各隱匿服務實例在最開始同時發布了其描述符至相應的匿名服務目錄服務器，因而，在遇到某一隱匿服務實例失效時，通過重新獲取隱匿服務描述符，便可得到能夠有效連接到隱匿服務的介紹結點列表。

我們偶然發現，如果隱匿服務開啟時間不同，所得到的結果也會不同。如圖14所示，在這個實驗中，一個隱匿服務實例“hiddenserver_will_stop-11.0.0.74”在其他實例運行后開啟，因此這個實例的描述符在上傳后會替換所有相應隱匿服務目錄服務器上的描述符。在這之后連接隱匿服務的客戶端所獲取的描述符都會指向該最近啟動的隱匿服務實例。如若此時這個實例關閉，客戶端便無法獲取到有效的隱匿服務描述符，直至其他有效的隱匿服務更新其描述符。

這正如圖14所展示的一樣，在3000ticks后，客戶端由于無法獲取到有效的隱匿服務描述符，在一定時間內會導致整個隱匿服務的失效。直至4000ticks，其有效的隱匿服務實例定期更新其描述符，才使得客戶端可以獲取到有效的隱匿服務描述符，流量與服務才得以恢復。

3.3 實驗結論

通過實驗，我們可以確認運行多個隱匿服務實例可以完成對請求流量分配的原因。

第一，在任意給定時間，隱匿服務目錄服務器上對于一個隱匿服務可能持有不同的描述符。有的指向實例a，有的指向實例b。

即使所有的隱匿服務實例同時開啟并發布他們的描述符。隱匿服務目錄服務器接收到描述符的時間也可能會不同。因為隱匿服務會定期更新它的描述符，所以每個隱匿服務目錄服務器只會使最新獲取的描述符生效。

第二，客戶端決定訪問哪個目錄服務器獲取描述符是隨機的。在真實Tor網絡中，描述符的同時發布很難實現。這就導致隱匿服務目錄服務器很可能只保存了剛剛開啟的實例的描述符，而沒有保存另外其他的描述符。

但是，因為每個隱匿服務實例需要一定周期才會更新其描述符，所以網絡中一段時間中存儲的描述符會發生變化。這樣會使所有的新連接都鏈接到最新的隱匿服務實例上，以達到流量的動態分配。

4 總結與展望

本文介紹了Tor隱匿服務的設計原理，且通過實驗證實了通過運行多個Tor隱匿服務實例，更準確的說目錄服務器持有指向不同實例的描述符，可以起到分散負載的作用。這在一定程度上提高了Tor隱匿服務的可擴展性。通過負載均衡實驗，揭示了實例數量與最終負載均衡、性能提升的對應關系。并通過失效轉移實驗暴露出了該方法所存在的一些問題。這些都為在Tor中架設大型隱匿服務時所需的相關配置提供了非常可觀的參考價值。

由于工作量和時間的關系，本文只探討了隱匿服務可擴展性方面的問題與解決方案。Tor隱匿服務還存在著很多的問題等待完善。在解決其可用性與可擴展性之后，隨著隱匿服務的普及，它需要大量的研究者們投身于其安全性上的改進。畢竟，大規模網絡服務技術已經相當成熟，而隱匿服務，多了一份保護服務提供者的隱匿性的責任，需要在現有技術之上做出更多的努力。