維基百科

BitTorrent協議加密

協議加密（Protocol encryption，PE）、消息流加密（message stream encryption，MSE）或協議頭加密（protocol header encrypt，PHE）是部分對等網路檔案分享客戶端的特性，包括BitTorrent客戶端。它們嘗試增強隱私和保密性，並嘗試使第三方（如互聯網服務供應商）更難識別流量頭部。

MSE/PE在BitComet、BitTornado（英語：BitTornado）、Deluge、Flashget、KTorrent、Mainline、µTorrent、qBittorrent、rTorrent、Transmission、Tixati和Vuze等軟件中有被實現。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）. 

外部連結

取自「https://zh.wikipedia.org/w/index.php?title=BitTorrent协议加密&oldid=84728880」