王永鑒，孫光浩，劉丹青

(天津工業(yè)大學 計算機科學與軟件學院，天津 300387)

基于socks5代理輕量級網(wǎng)絡流量加密研究

王永鑒，孫光浩，劉丹青

(天津工業(yè)大學 計算機科學與軟件學院，天津 300387)

隨著Internet的飛速發(fā)展，網(wǎng)絡環(huán)境日趨復雜，用戶面臨電子郵件被竊取、信息被篡改等威脅。因此，保護網(wǎng)絡流量日趨重要。本項目提出輕量級網(wǎng)絡流量加密解決方案，基于socks5[4]代理原理，通過對稱加密算法和TCP協(xié)議數(shù)據(jù)偽裝技術(shù)實現(xiàn)。本項目具有配置客戶端快速、訪問網(wǎng)絡安全性高、訪問行為隱蔽性高、用戶感知不明顯、需要配置低等優(yōu)勢。預期成果可以用于郵件加密、隱私保護、公共WIFI安全等相關(guān)領(lǐng)域，市場前景廣闊。

socks5；TCP/IP協(xié)議；Epoll模型

0 引言

Socks[1]協(xié)議是網(wǎng)絡代理協(xié)議，它的設計初衷是為了支持應用穿越防火墻訪問外部網(wǎng)絡。Socks在協(xié)議棧的TCP層上運行，是介于傳輸層和應用層之間的中介層協(xié)議, 是為了讓使用TCP和UDP的客戶/服務器應用程序更方便安全地使用網(wǎng)絡防火墻所提供的服務而設計的。對于上層應用層協(xié)議來說，Socks[2]代理只是簡單地傳遞數(shù)據(jù)包，而不必關(guān)心是何種應用協(xié)議(比如 FTP，H TTP請求)。Socks協(xié)議的工作原理與應用代理相似，作為網(wǎng)絡邊界上的Socks 服務器接收客戶的請求，并代理外部的應用服務器，使得客戶與外部的聯(lián)系實質(zhì)上是 Socks[5]客戶與 Socks 服務器之間的聯(lián)系；而外部的應用服務器所接受的請求是來自Socks服務器的外部接口,也就是說 Socks服務器對內(nèi)部網(wǎng)絡的客戶來說是服務器，對外部網(wǎng)絡的應用服務器來說是客戶。

1 相關(guān)技術(shù)簡介

1.1 TCP/IP協(xié)議

TCP/IP參考模型是一個抽象的分層模型，這個模型中，所有的TCP/IP系列網(wǎng)絡協(xié)議都被歸類到4個抽象的“層”中。每一抽象層創(chuàng)建在低一層提供的服務上，并且為高一層提供服務。完成一些特定的任務需要眾多的協(xié)議協(xié)同工作，這些協(xié)議分布在參考模型的不同層中的，因此有時稱它們?yōu)橐粋€協(xié)議棧。TCP/IP參考模型為TCP/IP協(xié)議棧訂身制作。其中IP協(xié)議只關(guān)心如何使得數(shù)據(jù)能夠跨越本地網(wǎng)絡邊界的問題，而不關(guān)心如何利用傳輸媒體，數(shù)據(jù)如何傳輸。整個TCP/IP協(xié)議棧則負責解決數(shù)據(jù)如何通過許許多多個點對點通路（一個點對點通路，也稱為一“跳”，1 hop）順利傳輸，由此不同的網(wǎng)絡成員能夠在許多“跳”的基礎(chǔ)上創(chuàng)建相互的數(shù)據(jù)通路。如想分析更普遍的網(wǎng)絡通信問題，ISO的OSI模型也能起更好的幫助作用。 因特網(wǎng)協(xié)議族是一組實現(xiàn)支持因特網(wǎng)和大多數(shù)商業(yè)網(wǎng)絡運行的協(xié)議棧的網(wǎng)絡傳輸協(xié)議。它有時也被稱為TCP/IP協(xié)議組，這個名稱來源于其中兩個最重要的協(xié)議：傳輸控制協(xié)議（TCP）和因特網(wǎng)協(xié)議（IP），它們也是最先定義的兩個協(xié)議。同許多其他協(xié)議一樣網(wǎng)絡傳輸協(xié)議也可以看作一個多層組合，每層解決數(shù)據(jù)傳輸中的一組問題并且向使用這些低層服務的高層提供定義好的服務。高層邏輯上與用戶更為接近，所處理數(shù)據(jù)更為抽象，它們依賴于低層將數(shù)據(jù)轉(zhuǎn)換成最終能夠進行實體控制的形式。 網(wǎng)絡傳輸協(xié)議能夠大致匹配到一些廠商喜歡使用的固定7層的OSI模型。然而這些層并非都能夠很好地與基于ip的網(wǎng)絡對應（根據(jù)應用的設計和支持網(wǎng)絡的不同它們確實是涉及到不同的層）并且一些人認為試圖將因特網(wǎng)協(xié)議組對應到OSI會帶來混淆而不是有所幫助。

1.2 Socks5協(xié)議

RFC（request for comments）1928 文檔里面定義了 Socks5 協(xié)議[3]。該協(xié)議最初設計的目的是為了讓有權(quán)限的用戶可以穿過防火墻的限制，使用戶能夠訪問不能直接連接的資源。目前該協(xié)議的最高版本是 Socks5[4]。該協(xié)議在 1996 年被 IETF 確認為標準通信協(xié)議。目前，大量的網(wǎng)絡應用程序都支持Socks5[6]代理。由于 Socks5 實際上仍然對應了socket的操作，所以通過編程很容易實現(xiàn)讓不支持Socks5[7]協(xié)議的應用軟件也能通過 Socks5[8]服務器進行網(wǎng)絡通信，該通信過程對被代理的應用軟件透明。如Initex 公司開發(fā)的 Proxifier。因此，目前SOCKS 協(xié)議大多應用于突破網(wǎng)絡通信限制，提升網(wǎng)絡權(quán)限。由于通過 Socks5[9]可以代理任何基于socket 協(xié)議的應用軟件，因此服務端只是做轉(zhuǎn)發(fā)，并不知道客戶端使用數(shù)據(jù)的應用和具體的數(shù)據(jù)格式。通過對轉(zhuǎn)發(fā)數(shù)據(jù)的加密，可以保證客戶端數(shù)據(jù)網(wǎng)絡傳輸?shù)陌踩?。Socks5[10]代理協(xié)議的原理是客戶端先連到代理服務器，然后客戶端發(fā)送的所有TCP數(shù)據(jù)包請求都通過服務端轉(zhuǎn)發(fā)。對于接收端，認為所有的請求都來自代理服務器。代理服務器接收遠端發(fā)來的消息后，根據(jù)維護的客戶端列表，將數(shù)據(jù)轉(zhuǎn)發(fā)給不同的客戶。

Socks5[11]代理服務的工作流程如下:

①客戶端建立到代理服務器的 TCP 連接。②客戶端向代理服務器發(fā)送代理請求。

③代理服務接收代理客戶端應答，根據(jù)相應標記判斷是否允許代理。

④客戶端向代理服務器發(fā)送協(xié)商請求信息以及相關(guān)的端口信息。

⑤客戶端將數(shù)據(jù)發(fā)送到代理服務器并由代理服務器進行數(shù)據(jù)傳遞操作。

基于以上 Socks5 代理協(xié)議的特點，Socks5[12]代理協(xié)議非常適合無線局域網(wǎng)通過 Socks5 上網(wǎng)

1.3 Epoll模型簡介

epoll是Linux內(nèi)核為處理大批量文件描述符而作了改進的poll，是Linux下多路復用IO接口select/poll的增強版本，它能顯著提高程序在大量并發(fā)連接中只有少量活躍的情況下的系統(tǒng)CPU利用率。另一原因就是獲取事件的時候，它無須遍歷整個被偵聽的描述符集，只要遍歷那些被內(nèi)核IO事件異步喚醒而加入準備隊列的描述符集合就行了。epoll除了提供select/poll那種IO事件的水平觸發(fā)（Level Triggered）外，還提供了邊緣觸發(fā)（Edge Triggered），這就使得用戶空間程序有可能緩存IO狀態(tài)，減少系統(tǒng)調(diào)用，提高應用程序效率。

1.4 對稱密鑰加密算法

對稱密鑰加密（英語：Symmetric-key algorithm）又稱為對稱加密、私鑰加密、共享密鑰加密，是密碼學中的一類加密算法。這類算法在加密和解密時使用相同的密鑰，或是使用兩個可以簡單地相互推算的密鑰。實務上，這組密鑰成為在兩個或多個成員間的共同秘密，以便維持專屬的通訊聯(lián)系。與公開密鑰加密相比，要求雙方取得相同的密鑰是對稱密鑰加密的主要缺點之一。

常見的對稱加密算法有DES、3DES、AES、Blowfish、IDEA、RC5、RC6。對稱加密的速度比公鑰加密快很多，在很多場合都需要對稱加密。RC5分組密碼算法是1994由麻薩諸塞技術(shù)研究所的Ronald L. Rivest教授發(fā)明的，并由RSA實驗室分析。它是參數(shù)可變的分組密碼算法，三個可變的參數(shù)是：分組大小、密鑰大小和加密輪數(shù)。在此算法中使用了三種運算：異或、加和循環(huán)。

2 應用場景

輕量級網(wǎng)絡流量加密系統(tǒng)屬于遠程訪問技術(shù)，簡單地說就是利用公用網(wǎng)絡架設專用網(wǎng)絡。例如某公司員工出差到外地，他想訪問企業(yè)內(nèi)網(wǎng)的服務器資源，這種訪問就屬于遠程訪問。

在傳統(tǒng)的企業(yè)網(wǎng)絡配置中，要進行遠程訪問，傳統(tǒng)的方法是租用DDN（數(shù)字數(shù)據(jù)網(wǎng)）專線或幀中繼，這樣的通訊方案必然導致高昂的網(wǎng)絡通訊和維護費用。對于移動用戶（移動辦公人員）與遠端個人用戶而言，一般會通過撥號線路（Internet）進入企業(yè)的局域網(wǎng)，但這樣必然帶來安全上的隱患。

讓外地員工訪問到內(nèi)網(wǎng)資源，利用該解決方法就是在內(nèi)網(wǎng)中架設一臺socks5服務器。外地員工在當?shù)剡B上互聯(lián)網(wǎng)后，通過互聯(lián)網(wǎng)連接socks5服務器，然后通過該服務器進入企業(yè)內(nèi)網(wǎng)。為了保證數(shù)據(jù)安全，服務器和客戶機之間的通訊數(shù)據(jù)都進行了加密處理。有了數(shù)據(jù)加密，就可以認為數(shù)據(jù)是在一條專用的數(shù)據(jù)鏈路上進行安全傳輸，就如同專門架設了一個專用網(wǎng)絡一樣，但實際上VPN使用的是互聯(lián)網(wǎng)上的公用鏈路，其實質(zhì)上就是利用加密技術(shù)在公網(wǎng)上封裝出一個數(shù)據(jù)通訊隧道。有了該技術(shù)，用戶無論是在外地出差還是在家中辦公，只要能上互聯(lián)網(wǎng)就能訪問內(nèi)網(wǎng)資源。

3 實現(xiàn)過程

shadowsocks 是將原來 ssh 創(chuàng)建的 Socks5[13]協(xié)議拆開成 server 端和 client 端，所以下面這個原理圖基本上和利用 ssh tunnel 大致類似1、6）客戶端發(fā)出的請求基于 Socks5 協(xié)議跟 ss-local 端進行通訊，由于這個 ss-local 一般是本機或路由器或局域網(wǎng)的其他機器，不經(jīng)過 GFW，所以解決了上面被GFW通過特征分析進行干擾的問題2、5) ss-local 和 ss-server 兩端通過多種可選的加密方法進行通訊，經(jīng)過GFW的時候是常規(guī)的TCP包，沒有明顯的特征碼而且GFW也無法對通訊數(shù)據(jù)進行解密3、4）ss-server 將收到的加密數(shù)據(jù)進行解密，還原原來的請求，再發(fā)送到用戶需要訪問的服務，獲取響應原路返回。

圖1 Shadowsocks的實現(xiàn)過程Fig.1 hadowsocks the realization of the process

4 基本原理

shadowsocks的基本工作原理并不復雜。shadowsocks包括local和server兩個程序。local 運行在用戶自己的機器上，server 運行在墻外的服務器上。正常工作模式下，local 通常會監(jiān)聽本地1080端口，提供socks v5協(xié)議接口。在用戶本機進程和local的1080端口建立TCP連接之后，首先會發(fā)送一個hello包，或者叫handshake 握手包。local 程序接收到這個包之后，進行簡單的包數(shù)據(jù)檢查之后就返回一個確認包。本機進程收到確認的包之后，會再發(fā)送一個請求包，包的主要內(nèi)容就是目標服務的地址和端口號。local程序接收到請求包之后，會和server程序建立一個TCP連接，連接建立之后會把上面的目標服務的地址和端口號傳給server。這個連接是穿墻的關(guān)鍵，連接里面?zhèn)鬏數(shù)臄?shù)據(jù)都是經(jīng)過加密的，最常用的就是aes-256-cfb。local程序會對請求包返回一個確認的包。然后本機進程就開始向local傳輸實際的數(shù)據(jù)，local接收到之后加密繼續(xù)傳給server。server接收到之后把數(shù)據(jù)解密出來，然后和目標服務建立TCP連接，并把解密后的數(shù)據(jù)發(fā)送出去。然后接收數(shù)據(jù)就是上述的反過來。

為了理解以上內(nèi)容，強烈建議閱讀一下socks v5協(xié)議的RFC 1928。不長，一共才9頁，定義的包格式也很少。

圖2 Shadowsocks 的基本工作原理Fig.2 hadowsocks the basic working principle

4.1 shadowsocks

shadowsocks Python版本主要包括 Event loop、TCP Relay、UDP Relay和DNSResolver 這幾個模塊。我們主要介紹TCP的模式，UDP不做過多介紹。

shadowsocks 主要的工作流程就是先進行配置處理，然后針對每個需要監(jiān)聽的端口建立一個TCP Relay和UDP Relay，并添加到eventloop里。然后啟動eventloop的循環(huán)。當eventloop接收到事件時，將事件分發(fā)，調(diào)用對應的handle_event進行處理。對于每個建立的客戶端發(fā)起的TCP連接，都會新建一個TCP Relay Handler 進行處理。

在這里，local和server 使用的是同一個 TCPRelay類，他們的處理流程都統(tǒng)一了起來。但是就是因為如此，代碼的理解上反而顯的不是那么清晰。

4.2 Eventloop

shadowsocks 最早期的版本是基于線程的模型處理并發(fā)連接的。由于種種原因，線程模型在頻繁建立連接、高并發(fā)的情況下效率并不高?，F(xiàn)在的版本是基于eventloop的處理模型。shadowsocks里使用的eventloop是基于epoll模型的封裝，把 select和kqueue都封裝成了epoll模型的接口。

eventloop 最重要的方法run里的邏輯，就是典型的epoll處理方式。這里強烈建議去理解一下epoll的工作模型。這里很簡單，接收到event之后，調(diào)用對應的 handle_event方法進行處理。

4.3 TCPRelay

TCPRelay 里有個概念就是_server_socket，表示的是監(jiān)聽端口的socket。然后看 TCPRelay 的handle_event邏輯就分為了兩塊，如果是 _server_ socket，那么就只有客戶端請求建立連接的事件，_ server_socket負責accept之后創(chuàng)建新的 TCPRelayHandler；如果不是，那么說明是客戶端連接的讀寫事件，直接分發(fā)到對應的TCPRelayHandler調(diào)用handle_event進行處理。

在tcprelay.py 這個文件最上方，有一段注釋是描述的客戶端連接建立的全部過程。

# as sslocal:

# stage 1 addr received from local, query DNS for remote

# stage 2 UDP assoc

# stage 3 DNS resolved, connect to remote

# stage 4 still connecting, more data from local received

# stage 5 remote connected, piping local and re-mote

# as ssserver:

# stage 0 just jump to stage 1

# stage 1 addr received from local, query DNS for remote

# stage 3 DNS resolved, connect to remote

# stage 4 still connecting, more data from local received

# stage 5 remote connected, piping local and remote

在 TCPRelayHandler 里，就是按照如下定義的stage 的流程運行的。

STAGE_INIT = 0

STAGE_ADDR = 1

STAGE_UDP_ASSOC = 2

STAGE_DNS = 3

STAGE_CONNECTING = 4

STAGE_STREAM = 5

STAGE_DESTROYED = -1

先看handle_event，里面的邏輯分成了remote_ sock和local_sock兩部分。先從local_sock開始。從客戶端建立TCP連接之后，TCPRelayHandler創(chuàng)建的時候，local_sock就存在了，由于是客戶端主動建立的連接，數(shù)據(jù)也都是客戶端先發(fā)起的，所以先從local_sock的可讀事件開始。記住，我們目前處于STAGE_INIT狀態(tài)。在進入_on_local_read之后，緊守著is_local和_stage兩個變量，就可以按照上面基本原理里面說的工作流程，將狀態(tài)機運行起來了。

eventloop模型比較讓人討厭的就是要不停的循環(huán)，然后進入各自的 handle_event 里去思考流程，比較麻煩

5 結(jié)論

基于Socks5[14]協(xié)議的輕量級網(wǎng)絡流量加密系統(tǒng)可適應不同客戶端，多種用戶需求，便于管理，代價低等優(yōu)點。適合在不同終端中加密網(wǎng)絡流量。概括而言，本系統(tǒng)通過C/S（服務器/客戶端）架構(gòu)，比傳統(tǒng)代理方式（PPTPL2TPIPSecOPENVPN等）更加輕量，拋棄了密鑰協(xié)商的過程，將需要加密的網(wǎng)絡流量數(shù)據(jù)偽裝為TCP協(xié)議數(shù)據(jù)，更不容易被阻斷，采取事先在服務器端設置好固定密鑰的方式來加密連接，同時可以自定義端口和支持遠程DNS解析，專為移動設備和無線網(wǎng)絡優(yōu)化。

[1] Delfs, Hans & Knebl, Helmut. Symmetric-key encryption. Introduction to cryptography: principles and applications. Springer. 2007. ISBN 9783540492436.

[2] Mullen, Gary & Mummert, Carl. Finite fields and applications. American Mathematical Society. 2007: 112. ISBN 9780821844182.

[3] William Stallings. 操作系統(tǒng)——精髓與設計原理.: 530. ISBN 7-121-02196-X.

[4] Marcus Leech. SOCKS Protocol Version 5[S]. IETF RFC 1928, 1996.

[5] 俞定國，舒明磊，譚成翔. 基于 Socks5代理的移動SSL VPN系統(tǒng)研究與實現(xiàn)[J]. 計算機科學, 2011, 38(1): 119-122.

[6] 喻小光，陳維斌，潘孝銘. 一種基于SOCKS5的 Web 安全代理技術(shù)[J]. 華僑大學學報: 自然科學版，2007，28(3): 268-271.

[7] 孫偉平. 有關(guān)幾種網(wǎng)絡代理協(xié)議的探討[J]. 微計算機信息, 2006, (12): 167-169.

[8] 梁海, 范輝. Socks5協(xié)議實現(xiàn)防火墻穿透[J]. 現(xiàn)代計算機(專業(yè)版), 2004, (11): 25-29+65.

[9] 劉洪柱. 一種基于SOCKS5協(xié)議的代理服務器的設計和實現(xiàn)[J]. 大眾科技, 2004, (04): 68-69.

[10] 林心愉. 解決Socks5代理服務器因進程過多而無法運行的問題[J]. 計算機時代, 2001, (03): 3.

[11] 閆鵬. Socks 5點述代理服務[J]. 微電腦世界, 2001, (04): 94-95.

[12] 畢保祥, 肖德寶. SOCKS5的身份認證機構(gòu)[J]. 計算機應用, 2000, (07): 38-40.

[13] 范雄飛, 汪霖. 基于LSP的SOCKS5代理客戶端設計[J]. 湖南工業(yè)大學學報, 2009, (05): 102-105.

[14] 陳靜. 基于SOCKS5協(xié)議的專用網(wǎng)絡文件傳輸?shù)脑O計與實現(xiàn)[J]. 大眾科技, 2009, (09): 33-34.

Research on Lightweight Network Traffic Encryption Based on socks5 Proxy

WANG Yong-jian, SUN Guang-hao, LIU Dan-qing
(School of Computer Science and Software, Tianjin Polytechnic University, Tianjin 300387, China)

With the rapid development of the Internet, the network environment is becoming increasingly complex, users face e-mail theft, information tampering and other threats. As a result, protecting network traffic is becoming increasingly important. The project proposed lightweight network traffic encryption solution, based on socks5[4]proxy principle, through the symmetric encryption algorithm and TCP protocol data disguise technology to achieve. This project has the advantages of fast client configuration, high access network security, high concealment behavior, lack of user perception, and low configuration. Expected results can be used for mail encryption, privacy protection, public WIFI security and other related fields, the market prospect is broad.

Socks5; TCP/IP protocol; Epoll model

SOCKS hello

from local, send hello to local

TP391.41

A

10.3969/j.issn.1003-6970.2017.05.022

本文著錄格式：王永鑒，孫光浩，劉丹青. 基于socks5代理輕量級網(wǎng)絡流量加密研究[J]. 軟件，2017，38（5）：107-111