跳转到内容

BitTorrent协议加密

本页使用了标题或全文手工转换
维基百科,自由的百科全书

协议加密Protocol encryptionPE)、消息流加密message stream encryptionMSE)或协议头加密protocol header encryptPHE)是部分对等网路档案分享客户端的特性,包括BitTorrent客户端。它们尝试增强隐私和保密性,并尝试使第三方(如互联网服务供应商)更难识别流量头部。

MSE/PE在BitCometBitTornado英语BitTornadoDelugeFlashgetKTorrentMainlineµTorrentqBittorrentrTorrentTransmissionTixatiVuze等软件中有被实现。PHE在旧版本的BitComet中被实现。类似的协议混淆英语Obfuscation在最新版本的非BitTorrent系统(包括eMule)中也有实现[1]

目的

[编辑]

截至2005年1月,BitTorrent流量占据了住宅互联网总流量的三分之一以上[2],虽然这在2009年下降到不足20%[3]。一些互联网服务提供商通过增加其容量来处理这种流量,另有一些服务商使用专用的系统来降速对等流量以降低成本。混淆和加密会使流量更难以被检测和控制。这些系统的最初设计目的是匿名性保密性,但在某些国家(或地区、运营商)因互联网服务供应商限制BitTorrent流量或用户而变成必需品,他们认为BitTorrent流量占用过多网络资源(增加运营成本)、干扰网络正常运行,或认为或限制“非法的”文件共享。[来源请求]

历史

[编辑]

早期方法

[编辑]

协议头加密(PHE)由RnySmile英语RnySmile构想并最先在2005年9月8日的BitComet 0.60中实现。一些软件如IPP2P声称可以检测到使用了PHP的BitComet流量[4]。PHE是可以被检测的,因为只有部分流被加密。由于没有此协议的开放规范,其他客户端支持它的唯一方法是通过逆向工程

MSE/PE的开发

[编辑]

2006年1月下旬,Vuze(当时称为Azureus)的开发者决定设计并实现一个新的、开放的协议混淆方法,它被称消息流加密(message stream encryption,简称MSE)。该协议被包含在2006年1月19日的Azureus CVS快照2307-B29中[5]

这份首稿受到了严重的批评,因为它缺乏几个关键特征。在几名BitTorrent开发者磋商后,一份新的提案在几天内被撰写并实现到AzureusµTorrent beta。在µTorrent中,新的协议被称为协议加密(protocol encryption,简称PE)。

BitTorrent客户端各版本中的MSE/PE

[编辑]
  • BitComet 0.63版本,发布于2006年3月7日。它移除了旧的协议头加密并实现了新的MSE/PE以兼容Azureus和µTorrent[6]
  • BitTornado英语BitTornado从T-0.3.18版本开始支持MSE/PE。截至2007年1月5日,该版本仍在下载页面上标为“实验性”[7]
  • BitTorrent (Mainline)从2006年5月2日的4.9.2-beta开始支持MSE/PE[8]
  • Deluge从Deluge-0.5.1开始支持MSE/PE[9]
  • KTorrent在2006年4月29日的SVN版本535386中实现MSE/PE[10]
  • rTorrent从rTorrent-0.7.0开始支持MSE/PE[11]
  • Transmission从Transmission-0.90开始支持MSE/PE[12]
  • Vuze(以前名为Azureus)自2006年1月25日(CVS快照2307-B33)起支持最终版标准[13]。Azureus 2.4.0.0于2006年2月10日发布,是首个支持MSE/PE的稳定版本客户端。不过,Azureus的实现中存在瑕疵,会导致不正确的加密片段,从而散列检查失败。该瑕疵在2.4.0.2版本中被纠正[14]
  • µTorrent在Azureus的beta 1.4.1 build 407发布4年后支持MSE/PE[15]。µTorrent的1.5(build 436)版本于2006年3月7日发布;它是首个支持PE的µTorrent稳定版本[16]

操作

[编辑]

BitComet 0.60至0.62版本中使用的PHE方法即没有发布,也不兼容MSE/PE。

MSE/PE使用密钥交换结合torrent的infohash建立一个RC4加密密钥。密钥交换有助于最小化被动监听器的风险,而infohash有助于避免中间人攻击。选择RC4是为了速度更快。输出的第一个kibibyte(1024字节)被丢弃以防止Fluhrer, Mantin and Shamir attack英语Fluhrer, Mantin and Shamir attack

该规范允许用户选择仅加密报头或者完全加密整个连接。加密整个连接提供更强的混淆能力,但也消耗更多的CPU时间。

为确保与不支持此规范的其他客户端的兼容性,用户还可选择是否仍允许未加密的传入或传出连接。

支持的客户端通过节点交换(PEX)和分散式杂凑表(DHT)通告它们已启用MSE/PE。

安全性

[编辑]

该加密方法若对应常用的对称加密算法,加密强度约为60-80比特[17]。在密码学领域,这个有效的密钥长度相当低,但该协议不是为安全传输而设计,而是作为一种快速并有效的混淆方法。AES曾被提出作为加密方法,但未被采用,因为会消耗太多的CPU时间。它需要迪菲-赫尔曼密钥交换(Diffie–Hellman)密钥来做到AES级别的安全性,而AES要做到会更大,或者需要椭圆曲线密码学,使握手要使用较多的CPU时间。

效果

[编辑]

一些互联网服务提供商正在使用更复杂的措施(例如模式/时量分析,或者基于信道侧数据对端口进行分类)来检测BitTorrent流量。这意味着加密的BitTorrent流量也可以被限流。但是,也有些服务商继续使用简单、便宜的方法来识别和限流BitTorrent,因此当前的方案仍有效果。[来源请求]

对BitTorrent协议加密(也称MSE)的分析显示,数据包大小的测量统计和TCP会话中前100个数据包的数据包方向可以被用来识别混淆的协议,具有超过96%的准确性[18]

Sandvine英语Sandvine应用程序采用另一种途径,通过使播种(Seeding)失效来瓦解BitTorrent流量。Sandvine截取对等端到跟踪服务器(tracker)的通信并基于跟踪服务器返回的节点列表中的节点地址和端口号来识别对等端。当Sandvine在之后看到已截取的对等端列表中的对等端的连接时,它可能(根据策略)发送伪造的TCP重置来中断这些连接。有多种方案来抗击Sandvine的攻击,包括对等端到跟踪服务器及对等端到对等端之间的通信加密,使用微软的Teredo使TCP连接隧道化为UDP数据包,在终端主机的TCP层中过滤掉TCP重置包,或者完全从基于TCP的传输变为基于UDP的传输等。每个解决方案都各有利弊。过滤掉TCP重置通常需要内核访问权限和远程节点的参与,因为Sandvine会将重置数据包同时发给本地和远程节点。[来源请求]

批评

[编辑]

BitTorrent的发明者布莱姆·科亨(Bram Cohen)反对将加密加入BitTorrent协议,他担心加密可能导致客户端之间的不兼容,并还强调大多数ISP不封阻torrent协议。2006年他写道:“我相当怀疑有些开发者受到了他的ISP的限制,并更有兴趣破解他的ISP的限制,而不是整个互联网的性能。”[19] 许多BitTorrent社区的用户强烈反对Cohen的指责[20]。Cohen后来也添加了加密连接到他的Mainline客户端[21]使其有接收能力,但不会如此发送加密连接。[来源请求]

参考资料

[编辑]
  1. ^ eMule protocol obfuscation (encryption). emule-project.net. 2006-09-16 [2010-03-11]. (原始内容存档于2009-09-25). 
  2. ^ The Bittorrent Effect. Wired. 2007-05-30 [2016-12-05]. (原始内容存档于2014-03-15). 
  3. ^ 2009 Global Broadband Phenomena (PDF). Sandvine.com. 2009-11-16 [2016-12-05]. (原始内容 (PDF)存档于2009-11-22). 
  4. ^ News. IPP2P.org. 2006-01-04 [2016-12-05]. (原始内容存档于2013-05-20). 
  5. ^ [Azureus-commitlog] CVS Snapshot Azureus2307-B29.jar has been released !. Sourceforge.net. 2006-01-19 [2016-12-05]. (原始内容存档于2019-09-24). 
  6. ^ BitComet Client Release Notes. Bitcomet.com. 2006-03-07 [2016-12-05]. (原始内容存档于2010-12-17). 
  7. ^ BitTornado T-0.3.18. Degreez.net forum. 2007-01-05 [2016-12-05]. (原始内容存档于2017-03-25). 
  8. ^ Version Notes. BitTorrent.com. 2006-05-02 [2016-12-05]. (原始内容存档于2006-06-13). 
  9. ^ Changelog: Deluge 0.5.1 (11 June 2007). Deluge-torrent.org. 2007-06-11 [2016-12-05]. (原始内容存档于2008-04-01). 
  10. ^ Encryption has been added !. KTorrent.pwsp.net forum. 2006-04-29 [2016-12-05]. (原始内容存档于2007-06-05). 
  11. ^ [Libtorrent-devel] LibTorrent 0.11.0 and rTorrent 0.7.0 released. Rakshasa.no mail archive. 2006-12-13 [2016-12-05]. (原始内容存档于2007-05-02). 
  12. ^ Transmission 0.90 Released!. Transmission.m0k.org forum. 2007-10-24 [2016-12-05]. (原始内容存档于2007-10-27). 
  13. ^ [Azureus-commitlog] CVS Snapshot Azureus2307-B33.jar has been released !. Sourceforge.net. 2006-01-25 [2016-12-05]. (原始内容存档于2019-09-24). 
  14. ^ Azureus : Java BitTorrent Client - Changelog. Azureus.sourceforge.net. [2016-12-05]. (原始内容存档于2006-03-20). 
  15. ^ µTorrent 1.4.2 beta 435. uTorrent Announcements. 2006-01-29 [2016-12-05]. (原始内容存档于2006-05-14). 
  16. ^ "µTorrent 1.5 released"页面存档备份,存于互联网档案馆). uTorrent Announcements. 2006-03-07.
  17. ^ RFC 3526 chapter 8. IETF.org. [2016-12-05]. (原始内容存档于2017-01-18). 
  18. ^ Hjelmvik, Erik; John, Wolfgang. Breaking and Improving Protocol Obfuscation (PDF). Department of Computer Science and Engineering, Chalmers University of Technology. 2010-07-27 [2016-12-05]. ISSN 1652-926X. (原始内容 (PDF)存档于2016-12-04). 
  19. ^ Cohen, Bram. Obfuscating BitTorrent. Bram Cohen blog. 2006-01-29 [2016-12-05]. (原始内容存档于2006-02-07). 
  20. ^ Debate over Protocol Encryption. uTorrent.com forum. 2006-02-04 [2016-12-05]. (原始内容存档于2007-10-22). 
  21. ^ BitTorrent Mainline Version History. BitTorrent.com. 2006-10-15 [2016-12-05]. (原始内容存档于2007-02-25). 

外部链接

[编辑]