MSE/PE 的實做

看到 Bittorrent 的 Protocol header encrypt(PHE)、Message Stream Encryption(MSE)/PE 這篇提到:

另外,和 rxlin 討論的時候,他有提到說都公佈了實作部分的話,那是不是 ISP 也知道怎麼擋了…-_-|

SSL 也公佈了實做的部分,你目前有辦法截聽內容嗎?同樣的思路放到這邊來,我只要把固定字串的判斷改用密碼學裡面的方法,是不是也可以達到「無法偵測」的效果?

目前 MSE 1.0 版是透過五個步驟把資料送出去:

A->B
Diffie Hellman Ya (96 bytes)
PadA (Random, 0 ~ 512 bytes)
B->A
Diffie Hellman Yb (96 bytes)
PadB (Random, 0 ~ 512 bytes)
A->B
HASH('req1', S) (16 bytes)
HASH('req2', SKEY) xor HASH('req3', S) (16 bytes)
ENCRYPT(VC, crypto_provide, len(PadC), PadC, len(IA)) (Random, RC4)
ENCRYPT(IA) (Random, RC4)
B->A
ENCRYPT(VC, crypto_select, len(padD), padD)
ENCRYPT2(Payload Stream) (這邊開始傳實際的內容)
A->B
ENCRYPT2(Payload Stream) (這邊開始傳實際的內容)

前面兩個步驟是雙方先各自產生一個 Xa 及 Xb,然後各自計算出 Ya 及 Yb 丟給對方。對方收到後用自己的 Xb (或 Xa) 與 Ya (或 Yb) 運算,就會得到 S,也就是規格裡面這段:

DH secret: S = (Ya^Xb) mod P = (Yb^Xa) mod P

這就是 D-H exchange,如果你問,在得知 Ya 與 Yb 後,是否可以求得 S,或是更強烈,直接求得 Xa/Xb:這是密碼學上的 ,目前 768 bits 的強度已經足夠應付藍星的 P-Cube 或是其他類似的設備。

接下來的 SKEY 是 .torrent 檔案裡面的資訊,第四步的 ENCRYPT 是 RC4,最後面的 ENCRYPT2 是選用 plaintext 或 RC4 編碼,但到這邊的 offset 已經不固定了...。

以這個架構,目前看不出來要怎麼擋。也許是透過軟體實做上的瑕疵 (像是亂數太過規則之類的),不過這個就算發生,也只是那套軟體的問題。另外一種可能是透過 MSE 在大量連線上可能造成密碼系統的弱點,不過到時候 2.0 版又會跟著出爐...

Bittorrent 的 Encryption (MSE/PE)

上看到 Bittorrent Encryption 的條目【】,說明最近這幾個月 (Bittorrent) Header Encryption 的故事。

這段故事從 先在 0.60 版實作 Protocol Header Encryption (PHE) 開始講,但是這部份的實作細節並沒有公開發表,所以其他 軟體也不知道要怎麼做。

過了幾個月後 宣稱找到方法偵測 的 PHE (由於 的實作方式沒有公開,這部份應該是使用逆向工程法找出規則)。

再來是 決定自己發展一套規格,後來經過了一些事情,決定與 一起合作。

我剛剛看了一下目前的 Spec 網頁,發現在 2/9 的時候 1.0 版的實作規格就已經定案:,而 2.4.0.0 也成為第一個支援 MSE/PE 的正式版本, 的 Beta 版也有支援部份 Protocol。

BitComet 0.62

0.62 的 Release Note:

  • GUI Improved: add the ability to fetch remote channel xml file and display its items in favourite bar
  • GUI Improved: adjust the toolbar position of embedded browser
  • GUI Bugfix: fix the bug that sometimes the embedded browser can't handle BCTP link properly
  • GUI Bugfix: fix the bug that sometimes the task name displayed as the http link of torrent file
  • GUI Bugfix: fix the bug that sometimes the task status displayed as failed after DHT torrent download finished successfully
  • Core Improved: user favourite data file changed from .\fav\my_fav.xml to .\Favourite.xml
  • Core Bugfix: fix possible crash when exit program while hashing
  • Core Bugfix: fix possible crash when detects WMP version at BitComet startup
  • Core Bugfix: fix possible memory access violation when remove task after DHT torrent file download finished

1/28 的漏洞 (我在 BitComet 安全漏洞 這篇有提過),拖了這麼久... Changelog 上面卻沒看到修正記錄?

Bittorrent Encryption

( 的作者) 在他的 Blog 上對某些 Client 為了避開 ISP 過濾所做的行為 (像是 的 Encryption Header,或是 計畫的東西) 提出看法:Obfuscating BitTorrent

提到了如果你用 Encryption 可能會造成的優缺點:你可能因為 Encryption 避開了 ISP 的限流,也有可能因為 Encryption 避開了 ISP 的 P2P Cache。(在台灣幾乎都是限流的設備,不過這是另外一回事了)

回到原來主題, 的作法是直接修改 Protocol (Backward-compatible),很明顯的, 在文章裡並不贊成這種作法。他提出了另外一個方法解決這個問題:Tracker Extension。

這個作法是向 Tracker 註冊時告訴 Tracker「我有 Encryption 的能力」,當 Tracker 傳 Peer list 回來的時候也順便告訴我有哪些 Peer 也支援這樣的功能。這樣的話不支援的 Client 也可以順利的繼續跑,而支援的 Client 之間就可以加密傳輸了。

至於後面講到 Diffie-Hellman Key Exchange,呃... 用 infohash 就好了啊...

BitComet 安全漏洞

剛剛在 看到的:BitCometURI.c,攻擊者可以製造一個特殊的 .torrent 然後散佈出去,當 開啟檔案的時候會 crash,而且會執行 .torrent 檔裡面所帶有的 evil code:

A vulnerability in BitComet allows remote attackers to construct a special .torrent file and put it on any BitTorrent publishing web site. When a user downloads the .torrent file and clicks on publishers name, BitComet will crash. An attacker can run arbitrary code on victims' host by specially crafted .torrent file.

看起來 不久後就得出 0.62 了 :p

eMule 的 Encrypted Connection

那邊看到 不打算加入 Encrypted Connection 的功能:emule 發展者對加密傳輸的政策

在 eMule 的 forum 上,Frequently Asked Features, read this before posting a new Request 這篇文章裡:

Features you won't see in eMule:
Encrypted transfer - This only wastes resources and offers you no advantage. It doesn't offer you more privacy as the receiver of the data always has to decrypt it and the receiver could be any untrusted person. Encryption would only help against a Man-In-The-Middle attack which never happens for P2P-Networks as there are easier ways (see the sentence above).

不過似乎沒抓到重點,Encrypted Connection 的目的只是要閃開 P2P Filtering 的設備...

VPN 的使用量增加不少...

最近發現 提供給學生的 使用量增加不少:

211.76.240.29_fa3-day

使用的人數大約在 100 人左右 (還在增加),這種不分晝夜都是一樣的流量,一定是 P2P 軟體... 大概是想用 P2P 的人發現 的存在了?

在學校測試了一下 ,連國外的部分都被擋了下來,不過,如果雙方都用 BitComet 0.60 版的時候就不受到影響,這大概是因為 Encryption 的關係吧。

再來測 ,慘兮兮地,什麼地方都不能連,即使用 VPN 先把 Kad 跑起來,斷線以後也沒辦法建立起連線,看起來只有等到 開始支援 Encryption,讓這些設備廠頭痛之後才有解 :p (來個 SSL-compatible encryption,那麼全世界搞 Content Filtering 的就當場暈倒 :p)

Suprnova 消失的故事

上轉錄了 的系統管理者 描述 從網路上消失的故事:

事情的發生是從 2004 年十一月的時候開始, 接到 ISP 的電話,通知他警方搜查了他的 server。在同年十二月初的時候,路透社報導了 ,而其他的報紙也跟著報導, 覺得不太對勁,決定暫時關閉 Suprnova.org。

在關閉 Suprnova.org 一個月後的某個早晨,警方拿著搜索票造訪 的家裡,帶走了兩台電腦以及一堆資料。

再一個月後 (原文是 About a month or so later), 被警方傳喚,警方做了一份表格,包括了那兩台電腦裡的資料以及從 ISP 那邊取得的資料。

在一個月後,警方再度傳喚 與他的律師決定不回答任何的問題。警方告知 他們會將這些資料交給檢察官繼續執行。 的律師告訴 大概會在暑假後收到通知。

在今年的 10/18, 收到從檢察官那寄來的通知了:檢方決定不起訴。而 也拿回原來的那兩台電腦以及所有的資料。