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隐匿服务还存在着很多的问题等待完善。在解决其可用性与可扩展性之后，随着隐匿服务的普及，它需要大量的研究者们投身于其安全性上的改进。毕竟，大规模网络服务技术已经相当成熟，而隐匿服务，多了一份保护服务提供者的隐匿性的责任，需要在现有技术之上做出更多的努力。