BitTorrent協議加密

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

MSE/PE在BitComet、BitTornado、Deluge、Flashget、KTorrent、Mainline、µTorrent、qBittorrent、rTorrent、Transmission、Tixati和Vuze等軟體中有被實現。PHE在舊版本的BitComet中被實現。類似的協議混淆在最新版本的非BitTorrent系統（包括eMule）中也有實現。

## 目的

截至2005年1月，BitTorrent流量占據了住宅網際網路總流量的三分之一以上，雖然這在2009年下降到不足20%。一些網際網路服務提供商通過增加其容量來處理這種流量，另有一些服務商使用專用的系統來降速對等流量以降低成本。混淆和加密會使流量更難以被檢測和控制。這些系統的最初設計目的是匿名性或保密性，但在某些國家（或地區、運營商）因網際網路服務供應商限制BitTorrent流量或使用者而變成必需品，他們認為BitTorrent流量占用過多網路資源（增加運營成本）、干擾網路正常運行，或認為或限制「非法的」文件共享。

## 歷史

### 早期方法

協議頭加密（PHE）由RnySmile構想並最先在2005年9月8日的BitComet 0.60中實現。一些軟體如IPP2P聲稱可以檢測到使用了PHP的BitComet流量。PHE是可以被檢測的，因為只有部分流被加密。由於沒有此協議的開放規範，其他客戶端支持它的唯一方法是通過逆向工程。

### MSE/PE的開發

2006年1月下旬，Vuze（當時稱為Azureus）的開發者決定設計並實現一個新的、開放的協議混淆方法，它被稱消息流加密（message stream encryption，簡稱MSE）。該協議被包含在2006年1月19日的Azureus CVS快照2307-B29中。

這份首稿受到了嚴重的批評，因為它缺乏幾個關鍵特徵。在幾名BitTorrent開發者磋商後，一份新的提案在幾天內被撰寫並實現到Azureus和µTorrent beta。在µTorrent中，新的協議被稱為協議加密（protocol encryption，簡稱PE）。

### BitTorrent客戶端各版本中的MSE/PE

- BitComet 0.63版本，發布於2006年3月7日。它移除了舊的協議頭加密並實現了新的MSE/PE以兼容Azureus和µTorrent。
- BitTornado從T-0.3.18版本開始支持MSE/PE。截至2007年1月5日，該版本仍在下載頁面上標為「實驗性」。
- BitTorrent （Mainline）從2006年5月2日的4.9.2-beta開始支持MSE/PE。
- Deluge從Deluge-0.5.1開始支持MSE/PE。
- KTorrent在2006年4月29日的SVN版本535386中實現MSE/PE。
- rTorrent從rTorrent-0.7.0開始支持MSE/PE。
- Transmission從Transmission-0.90開始支持MSE/PE。
- Vuze（以前名為Azureus）自2006年1月25日（CVS快照2307-B33）起支持最終版標準。Azureus 2.4.0.0於2006年2月10日發布，是首個支持MSE/PE的穩定版本客戶端。不過，Azureus的實現中存在瑕疵，會導致不正確的加密片段，從而散列檢查失敗。該瑕疵在2.4.0.2版本中被糾正。
- µTorrent在Azureus的beta 1.4.1 build 407發布4年後支持MSE/PE。µTorrent的1.5（build 436）版本於2006年3月7日發布；它是首個支持PE的µTorrent穩定版本。

## 操作

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

MSE/PE使用密鑰交換結合torrent的infohash建立一個RC4加密密鑰。密鑰交換有助於最小化被動監聽器的風險，而infohash有助於避免中間人攻擊。選擇RC4是為了速度更快。輸出的第一個kibibyte（1024位元組）被丟棄以防止Fluhrer, Mantin and Shamir attack。

該規範允許用戶選擇僅加密報頭或者完全加密整個連接。加密整個連接提供更強的混淆能力，但也消耗更多的CPU時間。

為確保與不支持此規範的其他客戶端的兼容性，使用者還可選擇是否仍允許未加密的傳入或傳出連接。

支持的客戶端通過節點交換（PEX）和分散式雜湊表（DHT）通告它們已啟用MSE/PE。

## 安全性

該加密方法若對應常用的對稱加密演算法，加密強度約為60-80比特。在密碼學領域，這個有效的密鑰長度相當低，但該協議不是為安全傳輸而設計，而是作為一種快速並有效的混淆方法。AES曾被提出作為加密方法，但未被採用，因為會消耗太多的CPU時間。它需要迪菲-赫爾曼密鑰交換（Diffie–Hellman）密鑰來做到AES級別的安全性，而AES要做到會更大，或者需要橢圓曲線密碼學，使握手要使用較多的CPU時間。

## 效果

一些網際網路服務提供商正在使用更複雜的措施（例如模式/時量分析，或者基於信道側數據對埠進行分類）來檢測BitTorrent流量。這意味著加密的BitTorrent流量也可以被限流。但是，也有些服務商繼續使用簡單、便宜的方法來識別和限流BitTorrent，因此當前的方案仍有效果。

對BitTorrent協議加密（也稱MSE）的分析顯示，數據包大小的測量統計和TCP會話中前100個數據包的數據包方向可以被用來識別混淆的協議，具有超過96%的準確性。

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的限制，而不是整個網際網路的性能。」許多BitTorrent社區的使用者強烈反對Cohen的指責。Cohen後來也添加了加密連接到他的Mainline客戶端使其有接收能力，但不會如此發送加密連接。

## 外部連結

- "Message Stream Encryption". Vuze.
- "ISPs that shape BitTorrent". Vuze.
- "BitTorrent End to End Encryption and Bandwidth Throttling - Part I" with µTorrent developers. Slyck News.
- "BitTorrent End to End Encryption and Bandwidth Throttling - Part II" with Azureus developers Slyck News.
- "BitTorrent and End to End Encryption". Slashdot.
- "Tracker Peer Obfuscation". BitTorrent.org.
- "Identifying the Message Stream Encryption (MSE) protocol" for Statistical Protocol IDentification. Sourceforge.
- "Block P2P Traffic on a Cisco IOS Router using NBAR". Cisco.
- "Aria2c VPN/Proxy Tutorial". GoTux.