譯者：Radeon（Radeon bise@cmmail.com）
譯文發(fā)布時間：2001-6-18
目錄
1.介紹
2．現(xiàn)有的協(xié)議
3．基于TCP協(xié)議的客戶
4．請求
5．地址
6．應(yīng)答
7．基于UDP協(xié)議的客戶
8. 安全性考慮
9. 參考書目
1.介紹
利用網(wǎng)絡(luò)防火墻可以將組織內(nèi)部的網(wǎng)絡(luò)結(jié)構(gòu)從外部網(wǎng)絡(luò)如INTERNET中有效地隔離，這種方法在許多網(wǎng)絡(luò)系統(tǒng)中正變得流行起來。這種防火墻系統(tǒng)通常以應(yīng)用層網(wǎng)關(guān)的形式工作在兩個網(wǎng)絡(luò)之間，提供TELNET、FTP、SMTP等的接入。隨著越來越多的使全球信息查找更容易的復(fù)雜的應(yīng)用層協(xié)議的出現(xiàn)，有必要提供一個通用框架來使這些協(xié)議安全透明地穿過防火墻。而且在實際應(yīng)用中還需要一種安全的認(rèn)證方式用以穿越防火墻。這個要求起源于兩個組織的網(wǎng)絡(luò)中客戶/服務(wù)器關(guān)系的出現(xiàn)，這個關(guān)系需要得到控制并要求有安全的認(rèn)證。
在這兒所描述的協(xié)議框架是為了讓使用TCP和UDP的客戶/服務(wù)器應(yīng)用程序更方便安全地使用網(wǎng)絡(luò)防火墻所提供的服務(wù)所設(shè)計的。這個協(xié)議從概念上來講是介于應(yīng)用層和傳輸層之間的“中介層(shim-layer)”，因而不提供如傳遞ICMP信息之類由網(wǎng)絡(luò)層網(wǎng)關(guān)的所提供的服務(wù)。
2．現(xiàn)有的協(xié)議
當(dāng)前存在一個協(xié)議SOCKS 4，它為TELNET、FTP、HTTP、WAIS和GOPHER等基于TCP協(xié)議的客戶/服務(wù)器程序提供了一個不安全的防火墻。而這個新的協(xié)議擴(kuò)展了SOCKS V4，以使其支持UDP、框架規(guī)定的安全認(rèn)證方案、地址解析方案(addressing scheme)中所規(guī)定的域名和IPV6。為了實現(xiàn)這個SOCKS協(xié)議，通常需要重新編譯或者重新鏈接基于TCP的客戶端應(yīng)用程序以使用SOCKS庫中相應(yīng)的加密函數(shù)。
注意：
除非特別注明，所有出現(xiàn)在數(shù)據(jù)包格式圖中的十進(jìn)制數(shù)字均以字節(jié)表示相應(yīng)域的長度。如果某域需要給定一個字節(jié)的值，用X’hh’來表示這個字節(jié)中的值。如果某域中用到單詞’Variable’，這表示該域的長度是可變的，且該長度定義在一個和這個域相關(guān)聯(lián)（1 – 2個字節(jié)）的域中，或一個數(shù)據(jù)類型域中。
3．基于TCP協(xié)議的客戶
當(dāng)一個基于TCP協(xié)議的客戶端希望與一個只能通過防火墻可以到達(dá)的目標(biāo)(這是由實現(xiàn)所決定的)建立連接，它必須先建立一個與SOCKS服務(wù)器上SOCKS端口的TCP連接。通常這個TCP端口是1080。當(dāng)連接建立后，客戶端進(jìn)入?yún)f(xié)議的“握手(negotiation)”過程：認(rèn)證方式的選擇，根據(jù)選中的方式進(jìn)行認(rèn)證，然后發(fā)送轉(zhuǎn)發(fā)的要求。SOCKS服務(wù)器檢查這個要求，根據(jù)結(jié)果，或建立合適的連接，或拒絕。
除非特別注明，所有出現(xiàn)在數(shù)據(jù)包格式圖中的十進(jìn)制數(shù)字均以字節(jié)表示相應(yīng)域的長度。如果某域需要給定一個字節(jié)的值，用X’hh’來表示這個字節(jié)中的值。如果某域中用到單詞’Variable’，這表示該域的長度是可變的，且該長度定義在一個和這個域相關(guān)聯(lián)（1 – 2個字節(jié)）的域中，或一個數(shù)據(jù)類型域中。
客戶端連到服務(wù)器后，然后就發(fā)送請求來協(xié)商版本和認(rèn)證方法：
| VER |
NMETHODS |
METHODS |
| 1 |
1 |
1 to 255 |
這個版本的SOCKS協(xié)議中，VER字段被設(shè)置成X'05'。NMETHODS字段包含了在METHODS字段中出現(xiàn)的方法標(biāo)示的數(shù)目（以字節(jié)為單位）。
服務(wù)器從這些給定的方法中選擇一個并發(fā)送一個方法選中的消息回客戶端：
如果選中的消息是X’FF’，這表示客戶端所列出的方法列表中沒有一個方法被選中，客戶端必須關(guān)閉連接。
當(dāng)前定義的方法有：
· X’00’ 不需要認(rèn)證
· X’01’ GSSAPI
· X’02’ 用戶名/密碼
· X’03’ -- X’7F’ 由IANA分配
· X’80’ -- X’FE’ 為私人方法所保留的
· X’FF’ 沒有可以接受的方法
然后客戶和服務(wù)器進(jìn)入由選定認(rèn)證方法所決定的子協(xié)商過程(sub-negotiation)。各種不同的方法的子協(xié)商過程的描述請參考各自的備忘錄。
開發(fā)者如果要為自己的方法得到一個方法號，可以聯(lián)系IANA。可以參考關(guān)于已經(jīng)被分配號碼的文檔以得到當(dāng)前所有方法的列表和相應(yīng)的協(xié)議。
符合本文檔的SOCKS V5實現(xiàn)必須支持GSSAPI，并且在將來支持用戶名/密碼認(rèn)證方式。
4．請求
一旦子協(xié)商過程結(jié)束后，客戶端就發(fā)送詳細(xì)的請求信息。如果協(xié)商的方法中有以完整性檢查和/或安全性為目的的封裝，這些請求必須按照該方法所定義的方式進(jìn)行封裝。
SOCKS請求的格式如下：
| VER |
CMD |
RSV |
ATYP |
DST.ADDR |
DST.PROT |
| 1 |
1 |
X’00’ |
1 |
Variable |
2 |
其中
· VER 協(xié)議版本: X’05’
· CMD
· CONNECT：X’01’
· BIND：X’02’
· UDP ASSOCIATE：X’03’
· RSV 保留
· ATYP 后面的地址類型
· IPV4：X’01’
· 域名：X’03’
· IPV6：X’04’'
· DST.ADDR 目的地址
· DST.PORT 以網(wǎng)絡(luò)字節(jié)順序出現(xiàn)的端口號
SOCKS服務(wù)器會根據(jù)源地址和目的地址來分析請求，然后根據(jù)請求類型返回一個或多個應(yīng)答。
5．地址
ATYP字段中描述了地址字段(DST.ADDR，BND.ADDR)所包含的地址類型：
· X'01'
基于IPV4的IP地址，4個字節(jié)長
· X'03'
基于域名的地址，地址字段中的第一字節(jié)是以字節(jié)為單位的該域名的長度，沒有結(jié)尾的NUL字節(jié)。
· X'04'
基于IPV6的IP地址，16個字節(jié)長
6．應(yīng)答
一旦建立了一個到SOCKS服務(wù)器的連接，并且完成了認(rèn)證方式的協(xié)商過程，客戶機(jī)將會發(fā)送一個SOCKS請求信息給服務(wù)器。服務(wù)器將會根據(jù)請求，以如下格式返回：
| VER |
REP |
RSV |
ATYP |
BND.ADDR |
BND.PORT |
| 1 |
1 |
X’00’ |
1 |
Variable |
2 |
其中：
· VER 協(xié)議版本: X’05’
· REP 應(yīng)答字段:
· X’00’ 成功
· X’01’ 普通的SOCKS服務(wù)器請求失敗
· X’02’ 現(xiàn)有的規(guī)則不允許的連接
· X’03’ 網(wǎng)絡(luò)不可達(dá)
· X’04’ 主機(jī)不可達(dá)
· X’05’ 連接被拒
· X’06’ TTL超時
· X’07’ 不支持的命令
· X’08’ 不支持的地址類型
· X’09’ – X’FF’ 未定義
· RSV 保留
· ATYP 后面的地址類型
· IPV4：X’01’
· 域名：X’03’
· IPV6：X’04’
· BND.ADDR 服務(wù)器綁定的地址
· BND.PORT 以網(wǎng)絡(luò)字節(jié)順序表示的服務(wù)器綁定的段口
標(biāo)識為RSV的字段必須設(shè)為X’00’。
如果選中的方法中有以完整性檢查和/或安全性為目的的封裝，這些應(yīng)答必須按照該方法所定義的方式進(jìn)行封裝。
CONNECT
在對一個CONNECT命令的應(yīng)答中，BND.PORT包含了服務(wù)器分配的用來連到目標(biāo)機(jī)的端口號，BND.ADDR則是相應(yīng)的IP地址。由于SOCKS服務(wù)器通常有多個IP，應(yīng)答中的BND.ADDR常和客戶端連到SOCKS服務(wù)器的那個IP不同。
SOCKS服務(wù)器可以利用DST.ADDR和DST.PORT，以及客戶端源地址和端口來對一個CONNECT請求進(jìn)行分析。
BIND
BIND請求通常被用在那些要求客戶端接受來自服務(wù)器的連接的協(xié)議上。FTP是一個典型的例子。它建立一個從客戶端到服務(wù)器端的連接來執(zhí)行命令以及接收狀態(tài)的報告，而使用另一個從服務(wù)器到客戶端的連接來接收傳輸數(shù)據(jù)的要求(如LS，GET，PUT)。
建議只有在一個應(yīng)用協(xié)議的客戶端在使用CONNECT命令建立主連接后才可以使用BIND命令建立第二個連接。建議SOCKS服務(wù)器使用DST.ADDR和DST.PORT來評價BIND請求。
在一個BIND請求的操作過程中，SOCKS服務(wù)器要發(fā)送兩個應(yīng)答給客戶端。當(dāng)服務(wù)器建立并綁定一個新的套接口時發(fā)送第一個應(yīng)答。BND.PORT字段包含SOCKS服務(wù)器用來監(jiān)聽進(jìn)入的連接的端口號，BAND.ADDR字段包含了對應(yīng)的IP地址。客戶端通常使用這些信息來告訴（通過主連接或控制連接）應(yīng)用服務(wù)器連接的匯接點。第二個應(yīng)答僅發(fā)生在所期望到來的連接成功或失敗之后。在第二個應(yīng)答中，BND.PORT和BND.ADDR字段包含了連上來的主機(jī)的IP地址和端口號。
UDP ASSOCIATE
UDP ASSOCIATE請求通常是要求建立一個UDP轉(zhuǎn)發(fā)進(jìn)程來控制到來的UDP數(shù)據(jù)報。DST.ADDR和DST.PORT 字段包含客戶端所希望的用來發(fā)送UDP數(shù)據(jù)報的IP地址和端口號。服務(wù)器可以使用這個信息來限制進(jìn)入的連接。如果客戶端在發(fā)送這個請求時沒有地址和端口信息，客戶端必須用全0來填充。
當(dāng)與UDP相應(yīng)的TCP連接中斷時，該UDP連接也必須中斷。
應(yīng)答UDP ASSOCIATE請求時，BND.PORT 和BND.ADDR字段指明了客戶發(fā)送UDP消息至服務(wù)器的端口和地址。
應(yīng)答處理
當(dāng)一個應(yīng)答(REP值不等于00)指明出錯時，SOCKS服務(wù)器必須在發(fā)送完應(yīng)答消息后一小段時間內(nèi)終止TCP連接。這段時間應(yīng)該在發(fā)現(xiàn)錯誤后少于10秒。
如果一個應(yīng)答(REP值等于00)指明成功，并且請求是一個BIND或CONNECT時，客戶端就可以開始發(fā)送數(shù)據(jù)了。如果協(xié)商的認(rèn)證方法中有以完整性、認(rèn)證和/或安全性為目的的封裝，這些請求必須按照該方法所定義的方式進(jìn)行封裝。類似的，當(dāng)以客戶機(jī)為目的地的數(shù)據(jù)到達(dá)SOCKS服務(wù)器時，SOCKS服務(wù)器必須用正在使用的方法對這些數(shù)據(jù)進(jìn)行封裝。
7．基于UDP協(xié)議的客戶
在UDP ASSOCIATE應(yīng)答中由BND.PORT指明了服務(wù)器所使用的UDP端口，一個基于UDP協(xié)議的客戶必須發(fā)送數(shù)據(jù)報至UDP轉(zhuǎn)發(fā)服務(wù)器的該端口上。如果協(xié)商的認(rèn)證方法中有以完整性、認(rèn)證和/或安全性為目的的封裝，這些數(shù)據(jù)報必須按照該方法所定義的方式進(jìn)行封裝。每個UDP數(shù)據(jù)報都有一個UDP請求頭在其首部：
| RSV |
FRAG |
ATYP |
DST.ADDR |
DST.PORT |
DATA |
| 2 |
1 |
1 |
Variable |
2 |
Variable |
在UDP請求頭中的字段是：
· RSV 保留 X’0000’
· FRAG 當(dāng)前的分段號
· ATYP 后面的地址類型
· IPV4：X’01’
· 域名：X’03’
· IPV6：X’04’
· DST.ADDR 目的地址
· DST.PORT 以網(wǎng)絡(luò)字節(jié)順序出現(xiàn)的端口號
· DATA 用戶數(shù)據(jù)
當(dāng)一個UDP轉(zhuǎn)發(fā)服務(wù)器轉(zhuǎn)發(fā)一個UDP數(shù)據(jù)報時，不會發(fā)送任何通知給客戶端；同樣，它也將丟棄任何它不能發(fā)至遠(yuǎn)端主機(jī)的數(shù)據(jù)報。當(dāng)UDP轉(zhuǎn)發(fā)服務(wù)器從遠(yuǎn)端服務(wù)器收到一個應(yīng)答的數(shù)據(jù)報時，必須加上上述UDP請求頭，并對數(shù)據(jù)報進(jìn)行封裝。
UDP轉(zhuǎn)發(fā)服務(wù)器必須從SOCKS服務(wù)器得到期望的客戶端IP地址，并將數(shù)據(jù)報發(fā)送到UDP ASSOCIATE應(yīng)答中給定的端口號。如果數(shù)據(jù)報從任何IP地址到來，而該IP地址與該特定連接中指定的IP地址不同，那么該數(shù)據(jù)報會被丟棄。
FRAG字段指明數(shù)據(jù)報是否是一些分片中的一片。如果SOCKS服務(wù)器要實現(xiàn)這個功能，X’00’指明數(shù)據(jù)報是獨立的；其他則越大越是數(shù)據(jù)報的尾端。介于1到127之間的值說明了該分片在分片序列里的位置。每個接收者都為這些分片提供一個重組隊列和一個重組的計時器。這個重組隊列必須在重組計時器超時后重新初始化，并丟棄相應(yīng)的數(shù)據(jù)報。或者當(dāng)一個新到達(dá)的數(shù)據(jù)報有一個比當(dāng)前在處理的數(shù)據(jù)報序列中最大的FRAG值要小時，也必須重新初始化從組隊列。重組計時器必須小于5秒。只要有可能，應(yīng)用程序最好不要使用分片。
分片的實現(xiàn)是可選的；如果某實現(xiàn)不支持分片，所有FRAG字段不為0的數(shù)據(jù)報都必須被丟棄。
一個SOCKS的UDP編程界面(The programming interface for a SOCKS-aware UDP)必須報告當(dāng)前可用UDP數(shù)據(jù)報緩存空間小于操作系統(tǒng)提供的實際空間。
· 如果 ATYP是 X’01’ - 10+method_dependent octets smaller
· 如果 ATYP是X’03’ - 262+method_dependent octets smaller
· 如果 ATYP是X’04’ - 20+method_dependent octets smaller
8. 安全性考慮
這篇文檔描述了一個用來透過IP網(wǎng)絡(luò)防火墻的應(yīng)用層協(xié)議。這種傳輸?shù)陌踩栽诤艽蟪潭壬弦蕾囉谔囟▽崿F(xiàn)所擁有以及在SOCKS客戶與SOCKS服務(wù)器之間經(jīng)協(xié)商所選定的特殊的認(rèn)證和封裝方式。
系統(tǒng)管理員需要對用戶認(rèn)證方式的選擇進(jìn)行仔細(xì)考慮。