深入浅出【迷雾通】之第二篇

本文章由 @为啥改名还要葱 冠名赞助!

他赞助了本文1600葱!


感嘆作者的更新速度!我每次讀完代碼,打算開始寫文章,作者就又提交代碼了。。。

還是繼續第一篇的主旋律【翻墻】,也就是客戶端到網橋這部分代碼。
如果,今天我能説完網橋部分,我在下一篇更新出口通信。也就是tinyss協議【講起來挺多的】

我們從網橋開始講起~
/cmd/geph-bridge/main.go 我們注意到listenLoop函數
人話版本:在網橋服務器上啓動隨機一個TCP的監聽端口,來接收客戶端發來的TCP請求
收到請求以後,通過cshirt2協議收發報文,處理邏輯在cmd/geph-bridge/handle.go的handle函數

那麽問題來了,客戶端如何知道網橋的地址呢?
首先,網橋往 https://checkip.amazonaws.com 這個地址,發送一個GET請求,應答就是自己的公網IP
然後,網橋往【警告:链接内容可能存在钓鱼网址,请勿打开】 https://bin der.geph.io/v2/add-bridge 這個地址,發送一個GET請求,添加自己的信息
{
    binderKey   用來鑒權,防止未授權的服務器發送此請求,把不安全的網橋加入到binder
    cookie        32字節隨機數,後面生成密鑰用到
    網橋的公網地址    包含IP:Port
}
現在輪到客戶端了~【隱去盲簽相關過程】
首先,客戶端往  https://netlify.com/v2/get-bridges 這個地址,發送一個GET請求【隨便一個CDN地址,不一定這個】
然後,客戶端得到了網橋信息
最後, 通過 getSingleTCP 去連接網橋,如果失敗,通過getWarpfrontCon 去連接網橋

重點講解 getSingleTCP ,也就是cshirt2協議,因爲getWarpfrontCon和Tor的meek原理一樣,實現差不多,沒有講解的價值【講了好幾次了~】
首先 , 調用 dialBridge(bi.Host, bi.Cookie)函數去連接服務器,獲得TCP連接【坑爹~】
{作者隱去了端口,讓我們猜端口號是多少,所以。。。自己改源碼吧}

接著,獲得連接以後,調用cshirt2.Client(cookie, conn)函數
1.先計算得到自己的私鑰和公鑰
2.調用 writePK(secret, 0, myPK, false, transport)
{
獲取當前時間【秒數 mod 30】,組裝字符串"handshake-[秒數 mod 30]-false"
以cookie為key,mac256(cookie, 組裝的字符串)得到臨時chacha20密鑰,加密自己的公鑰
得到的密文 ,後面append一堆隨機長度填充,然後發送給服務器
}
3.服務器收到handshake以後,返回應答
4.客戶端讀取前32個字節,就是服務器的公鑰
{
獲取當前時間【秒數 mod 30】+/-3秒,組裝字符串"handshake-[秒數 mod 30+/-3]-true"
以cookie為key,mac256(cookie, 組裝的字符串)得到臨時chacha20密鑰,解密報文
前32個字節就是服務器的公鑰,33-34字節是填充的長度
}
5.根據自己的私鑰和服務器的公鑰,通過ECDHE計算得到對稱密鑰SS
6.mac256(ss, []byte("c2s")) ,得到最終的cshirt2的通信密鑰
7.然後用chacha20加密解密收發報文就可以了
-------------------
8.最後 調用 connThroughBridge(bridgeConn)  往網橋發送
conn/feedback
exitName
來和出口節點橋接
9.接下來就是通過tinyss協議交互了,第三篇講解~
21
分享 2020-04-25

8 个评论

霏艺Faye 图书管理员
人話版本:
前面講解,估計很多人聽不懂。我還是總結下吧~

客戶端,向Binder服務器發送請求,獲得了網橋的IP端口,cookie等信息【通過CDN,所以不能墻】
客戶端,根據剛獲得的網橋地址,去TCP連接,中間過程是加密的【對GFW是明文~但是只能知道公鑰】
客戶端,收到服務器應答,得到服務器公鑰,中間過程是加密的【對GFW是明文~但是只能知道公鑰】
客戶端,通過ECC計算得到最終的密鑰,通過此密鑰傳輸數據【對GFW是密文】

第三篇,講解的是tinyss~

給讀者的建議:
dialBridge 明明可以直接連接網橋的IP端口地址,作者卻在代碼裏,截斷了【端口字符串】,改成客戶端本地隨機產生端口,然後讓用戶一個個去試【PoW啊~】,你們可以修改這個函數,就不用一個個端口測試過來了

給作者的建議:
我建議cookie不要使用rand,而使用ECC公鑰!
我自己的設計如下:
1.網橋 通過 ECC生成自己的公鑰 和 私鑰
2.把公鑰 按 你現在的cookie方式 發給binder
3.客戶端 按 你現在的方式,獲得網橋信息和 網橋的ECC公鑰【你的cookie】
4.客戶端調用cshirt2 的client,自己用得到的cookie和自己的私鑰,直接得到對稱密鑰ss
5.再用 cookie為key,計算mac256(cookie, ss),得到cshirt2層的 chacha20的密鑰
6.客戶端 發送 【自己的公鑰[明文] +  chacha20("conn/feedback" + exitName)[密文]】
---------------
服務端收到,客戶端報文,前32個字節就是公鑰,計算得到密鑰,解密33字節開始的報文
。。。

整個過程,只需要客戶端明文發送公鑰,其他所有流量全是加密數據
對GFW而言,所有流量都是全程加密的,而且握手協議比你現在的簡單很多
以上過程,我是模仿火狐的【DoH + ESNI】,你的binder服務器,我就當是DoH服務器了
DNS返回的txt record,也就是你的cookie



你的dialBridge函數,使用隨機端口,除了欺負下不懂代碼的用戶,我感覺沒有任何用處。。。
霏艺Faye 图书管理员 回复 柏賽東
如何赞助葱呢,我也想赞助点
霏艺Faye 图书管理员 回复 带带大师兄
如何赞助葱呢,我也想赞助点

我問了admin,但是他沒有告訴我

我也很好奇怎麽做到的
这个用是用了,但是始终没发现如何修改密码,注册之后就一直保持原来的密码吗?
涉及到一個叫盲籤的算法,不能改密碼

好家伙,这个就狠了。这样被猜出密码的话,账号也就相当于没咯。
已隐藏
挺不错的,支持作者一下

要发言请先登录注册

要发言请先登录注册

发起人

霏艺Faye 图书管理员

https://www.facebook.com/booklove.crown/

状态

  • 最新活动: 2023-05-29
  • 浏览: 31159