1. 程式人生 > >GFW與SS/SSR

GFW與SS/SSR

簡單說SS/SSR與GFW

個人理解,如有錯誤請告知.

Phase 1:

起初,我們對網路的訪問時非常直接的,我們(客戶端)向對方(服務端)發出請求,對方迴應請求.

P1這tm沒什麼好講的

Phase 2:

P2

後來,在我party(和諧詞注意)英明的指揮下,建立了GFW(Great FireWall),也就是偉大的中國國家防火牆.

設計者據說就這貨設計的.

下面花一點篇幅說幾個GFW的封鎖原理.

1.域名解析服務快取汙染

首先,GFW使用了返回錯誤的DNS查詢結果的方式,比如,當長城監聽它骨幹出口上某埠的DNS查詢(當然這是UDP),接著對其進行入侵檢測,一旦發現了和黑名單上關鍵詞相匹配的域名查詢請求,就會馬上開始當演員,返回一個虛假的結果,這樣,我們就會遭遇連線重置,無法獲得目標網站的IP地址。

然而..

2010年3月,當美國和智利的使用者試圖訪問熱門社交網站如facebook.com和youtube.com還有twitter.com等域名,他們的域名查詢請求轉交給中國控制的DNS根映象伺服器處理,由於這些網站在中國被封鎖,結果使用者收到了錯誤的DNS解析資訊,此時長城的DNS汙染已影響國際網際網路。(因為多次汙染國際網際網路,北京的一臺根域DNS還被關停了一段時間…)

還有..

2015年1月2日起,汙染方式升級,不再是解析到固定的無效IP,而是隨機地指向境外的有效IP(有毒啊)剛開始只是對YouTube視訊域名(*.googlevideo.com)進行處理,之後逐漸擴大到大多數被汙染的域名.這導致了境外伺服器遭受來自中國的DDoS攻擊,部分網站因此遮蔽中國IP

2.針對境外的IP地址封鎖

防火長城的路由擴散技術中使用的靜態路由其實是一條錯誤的路由,而且是有意配置錯誤的,其目的就是為了把本來是發往某個IP地址的資料包統統引導到一個“黑洞伺服器”上,這個黑洞伺服器上可以什麼也不做,這樣資料包就被無聲無息地丟掉了,當然也可以進行一個虛假的回覆.接著通過路由重分發,整個網路被打通,大家就都知道這樣的IP要發向這麼一個黑洞了,效率也得到了提升(封IP封的越來越開心了呢)

3.IP地址特定埠封鎖

結合2,為了達到更精確的封鎖,長城會對特定埠上的資料包進行全部丟棄,以達到更徹底的封鎖.

常常封鎖的埠:

SSH TCP 22

HTTP 80

(PPTP)VPN TCP 1723

(L2TP)VPN UDP 1701

IPSec/L2TP UDP 500&4500

OpenVPN TCP/UDP 1194

TLS/SSL/HTTPS TCP 443

另外,中國X動,中國X通等ISP的手機IP端,所有的PPTP都被封鎖.

4.對加密連線的干擾

(不太瞭解加密握手可以看看隔壁的TLS/SSL) 在連線握手時,因為伺服器的公鑰是明文傳輸的,長城會阻斷特定證書的加密連線,方法和無狀態TCP連線重置一樣,都是先發現匹配的黑名單證書,之後通過偽裝成對方向連線兩端的計算機發送RST干擾兩者間正常的TCP連線,進而打斷與特定IP地址之間的TLS加密連線握手,或者乾脆直接將握手的資料包丟棄導致握手失敗,從而導致TLS連線失敗.

5.深度包檢測

深度資料包檢測(Deep Package Inspection)是一種於應用層對網路上傳遞的資料進行偵測與處理的技術,DPI可對報文內容和協議特徵進行檢測。(似乎這個就是所謂的流量審查)

在中國大陸,DPI一度被ISP用於追蹤使用者行為以改善其廣告推送業務的精準性,長城賴以檢測關鍵詞及嗅探加密流量的重要技術之一.基於必要的硬體設施、適宜的檢測模型及相應的模式匹配演算法,長城能夠精確且快速地從實時網路環境中判別出有悖於預期標準的可疑流量,並對此及時作出相應地應對措施.

Phase 3:

P3

針對一些封鎖技術,勤勞智慧而又充滿勇氣的天朝人民,使用了境外HTTP伺服器代理,SOCKS服務,VPN 等等各種方式來 Break the GFW.

然而,儘管SSH是安全的,長城並不能知道里面發生了什麼樣的資料交換,它卻依舊能在建立隧道時,分析連線特徵從而進行干擾或是重定向連線.

其他的幾種方式,也都差不多.

Phase 4:

P4

於是,出現了cloudwindy同學…帶來的SS,沒錯,他被警察請去喝茶了.

延續Phase3,ShadowSocks實際上是將 SSH 建立的 SOCKS5協議 拆成兩個部分,server 端和 client 端

不同的地方在於,客戶端發出的請求基於 Socks5 協議跟 ss-local 端進行通訊,由於這個 ss-local 一般是本機或路由器或區域網的其他機器,不經過 GFW,所以解決了上面被 GFW 通過特徵分析進行干擾的問題.

那麼,就總體來說一下SS的運作流程:

首先,在伺服器上配置好了 SS 伺服器後,使用者按照指定的密碼、加密方式和埠使用 SS 客戶端與其連線。在成功連線到伺服器後,客戶端會在使用者的電腦上構建一個本地 Socks5 代理。瀏覽網路時,網路流量會被分到本地 socks5 代理,客戶端將其加密之後傳送到伺服器,伺服器以同樣的加密方式將流量回傳給客戶端,以此實現代理上網。

Phase 5:

後來,在Party的調教下,似乎GFW對SS的流量有了某種辨識能力,於是,Github上一位叫BreakWa11的作者修改了原SS的程式碼,增加了混淆以及其他的一些功能(這裡面有場不小的風波,從中可以學到一些開源協議的知識…感興趣的去搜搜看),名為SSR.

其中使用的混淆機制有:

  • http_simple
  • tls_simple
  • random_head
  • tls1.0_session_auth

說說這其中比較好理解的

tls1.0_session_auth:模擬TLS1.0在客戶端有session ID的情況下的握手連線。因為有session ID所以沒有傳送證書等複雜步驟,因而防火牆無法根據證書做判斷(之前說過),同時自帶一定的抗重放攻擊的能力。

由於防火牆對TLS比較無能為力,抗封鎖能力較強

random_head:開始通訊前傳送一個幾乎為隨機的資料包,之後為原協議流。目標是讓首個數據包根本不存在任何有效資訊,使得GFW的統計學習機制失效.