協議加密（Protocol encryption，PE）、訊息流加密（message stream encryption，MSE）或協議頭加密（protocol header encrypt，PHE）是部分對等網路檔案分享客戶端的特性，包括 BitTorrent 客戶端。它們嘗試增強隱私和保密性，並嘗試使第三方（如網際網路服務供應商）更難識別流量頭部。 MSEPE 在 BitComet、、Deluge、Flashget、KTorrent、Mainline、µTorrent、qBittorrent、rTorrent、Transmission、Tixati 和 Vuze 等軟體中有被實現。PHE 在舊版本的 BitComet 中被實現。類似的協議在最新版本的非 BitTorrent 系統（包括 eMule）中也有實現。 目的 截至 2005 年 1 月，BitTorrent 流量佔據了住宅網際網路總流量的三分之一以上，雖然這在 2009 年下降到不足 20。一些網際網路服務提供商透過增加其容量來處理這種流量，另有一些服務商使用專用的系統來降速對等流量以降低成本。混淆和加密會使流量更難以被檢測和控制。這些系統的最初設計目的是匿名性或保密性，但在某些國家（或地區、運營商）因網際網路服務供應商限制 BitTorrent 流量或使用者而變成必需品，他們認為 BitTorrent 流量佔用過多網路資源（增加運營成本）、干擾網路正常執行，或認為或限制 非法的 檔案共享。 歷史 早期方法 協議頭加密（PHE）由構想並最先在 2005 年 9 月 8 日的 BitComet 060 中實現。一些軟體如 IPP2P 聲稱可以檢測到使用了 PHP 的 BitComet 流量。PHE 是可以被檢測的，因為只有部分流被加密。由於沒有此協議的開放規範，其他客戶端支援它的唯一方法是透過逆向工程。 MSEPE 的開發 2006 年 1 月下旬，Vuze（當時稱為 Azureus）的開發者決定設計並實現一個新的、開放的協議混淆方法，它被稱訊息流加密（message stream encryption，簡稱 MSE）。該協議被包含在 2006 年 1 月 19 日的 Azureus CVS 快照 2307B29 中。 這份首稿受到了嚴重的批評，因為它缺乏幾個關鍵特徵。在幾名 BitTorrent 開發者磋商後，一份新的提案在幾天內被撰寫並實現到 Azureus 和 µTorrent beta。在 µTorrent 中，新的協議被稱為協議加密（protocol encryption，簡稱 PE）。 BitTorrent 客戶端各版本中的 MSEPE BitComet 063 版本，釋出於 2006 年 3 月 7 日。它移除了舊的協議頭加密並實現了新的 MSEPE 以相容 Azureus 和 µTorrent。 從 T0318 版本開始支援 MSEPE。截至 2007 年 1 月 5 日，該版本仍在下載頁面上標為 實驗性。 BitTorrent （Mainline）從 2006 年 5 月 2 日的 492beta 開始支援 MSEPE。 Deluge 從 Deluge051 開始支援 MSEPE。 KTorrent 在 2006 年 4 月 29 日的 SVN 版本 535386 中實現 MSEPE。 rTorrent 從 rTorrent070 開始支援 MSEPE。 Transmission 從 Transmission090 開始支援 MSEPE。 Vuze（以前名為 Azureus）自 2006 年 1 月 25 日（CVS 快照 2307B33）起支援最終版標準。Azureus 2400 於 2006 年 2 月 10 日釋出，是首個支援 MSEPE 的穩定版本客戶端。不過，Azureus 的實現中存在瑕疵，會導致不正確的加密片段，從而雜湊檢查失敗。該瑕疵在 2402 版本中被糾正。 µTorrent 在 Azureus 的 beta 141 build 407 釋出 4 年後支援 MSEPE。µTorrent 的 15（build 436）版本於 2006 年 3 月 7 日釋出；它是首個支援 PE 的 µTorrent 穩定版本 µTorrent 15 released uTorrent Announcements 20060307。 操作 BitComet 060 至 062 版本中使用的 PHE 方法即沒有釋出，也不相容 MSEPE。 MSEPE 使用金鑰交換結合 torrent 的 infohash 建立一個 RC4 加密金鑰。金鑰交換有助於最小化被動監聽器的風險，而 infohash 有助於避免中間人攻擊。選擇 RC4 是為了速度更快。輸出的第一個 kibibyte（1024 位元組）被丟棄以防止。 該規範允許使用者選擇僅加密報頭或者完全加密整個連線。加密整個連線提供更強的混淆能力，但也消耗更多的 CPU 時間。 為確保與不支援此規範的其他客戶端的相容性，使用者還可選擇是否仍允許未加密的傳入或傳出連線。 支援的客戶端透過節點交換（PEX）和分散式雜湊表（DHT）通告它們已啟用 MSEPE。 安全性 該加密方法若對應常用的對稱加密演算法，加密強度約為 6080 位元。在密碼學領域，這個有效的金鑰長度相當低，但該協議不是為安全傳輸而設計，而是作為一種快速並有效的混淆方法。AES 曾被提出作為加密方法，但未被採用，因為會消耗太多的 CPU 時間。它需要迪菲 赫爾曼金鑰交換（DiffieHellman）金鑰來做到 AES 級別的安全性，而 AES 要做到會更大，或者需要橢圓曲線密碼學，使握手要使用較多的 CPU 時間。 效果 一些網際網路服務提供商正在使用更復雜的措施（例如模式 時量分析，或者基於通道側資料對埠進行分類）來檢測 BitTorrent 流量。這意味著加密的 BitTorrent 流量也可以被限流。但是，也有些服務商繼續使用簡單、便宜的方法來識別和限流 BitTorrent，因此當前的方案仍有效果。 對 BitTorrent 協議加密（也稱 MSE）的分析顯示，資料包大小的測量統計和 TCP 會話中前 100 個數據包的資料包方向可以被用來識別混淆的協議，具有超過 96 的準確性。 應用程式採用另一種途徑，透過使播種（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 BitTorrentorg Identifying the Message Stream Encryption MSE protocol for Statistical Protocol IDentification Sourceforge Block P2P Traffic on a Cisco IOS Router using NBAR Cisco Aria2c VPNProxy Tutorial GoTux CategoryBitTorrent Category 加密協議