「轉」Socks5協定中文文檔（RFC1928）

譯者：Radeon（Radeon [email protected]）

譯文釋出時間：2001-6-18

目錄

1.介紹

2．現有的協定

3．基于TCP協定的客戶

4．請求

5．位址

6．應答

7．基于UDP協定的客戶

8. 安全性考慮

9. 參考書目

利用網絡防火牆可以将組織内部的網絡結構從外部網絡如INTERNET中有效地隔離，這種方法在許多網絡系統中正變得流行起來。這種防火牆系統通常以應用

層網關的形式工作在兩個網絡之間，提供TELNET、FTP、SMTP等的接入。随着越來越多的使全球資訊查找更容易的複雜的應用層協定的出現，有必要提

供一個通用架構來使這些協定安全透明地穿過防火牆。而且在實際應用中還需要一種安全的認證方式用以穿越防火牆。這個要求起源于兩個組織的網絡中客戶/服務

器關系的出現，這個關系需要得到控制并要求有安全的認證。

在這兒所描述的協定架構是為了讓使用TCP和UDP的客戶/伺服器應用程式更友善安全地使用網絡防火牆所提供的服務所設計的。這個協定從概念上來講是介于

應用層和傳輸層之間的“中介層(shim-layer)”，因而不提供如傳遞ICMP資訊之類由網絡層網關的所提供的服務。

目前存在一個協定SOCKS

4，它為TELNET、FTP、HTTP、WAIS和GOPHER等基于TCP協定的客戶/伺服器程式提供了一個不安全的防火牆。而這個新的協定擴充了

SOCKS V4，以使其支援UDP、架構規定的安全認證方案、位址解析方案(addressing

scheme)中所規定的域名和IPV6。為了實作這個SOCKS協定，通常需要重新編譯或者重新連結基于TCP的用戶端應用程式以使用SOCKS庫中相

應的加密函數。

注意：

除非特别注明，所有出現在資料包格式圖中的十進制數字均以位元組表示相應域的長度。如果某域需要給定一個位元組的值，用X’hh’來表示這個位元組中的值。如果

某域中用到單詞’Variable’，這表示該域的長度是可變的，且該長度定義在一個和這個域相關聯（1 – 2個位元組）的域中，或一個資料類型域中。

當一個基于TCP協定的用戶端希望與一個隻能通過防火牆可以到達的目标(這是由實作所決定的)建立連接配接，它必須先建立一個與SOCKS伺服器上SOCKS

端口的TCP連接配接。通常這個TCP端口是1080。當連接配接建立後，用戶端進入協定的“握手(negotiation)”過程：認證方式的選擇，根據選中的

方式進行認證，然後發送轉發的要求。SOCKS伺服器檢查這個要求，根據結果，或建立合适的連接配接，或拒絕。

用戶端連到伺服器後，然後就發送請求來協商版本和認證方法：

VER

NMETHODS

METHODS

1

1 to 255

這個版本的SOCKS協定中，VER字段被設定成X'05'。NMETHODS字段包含了在METHODS字段中出現的方法标示的數目（以位元組為機關）。

伺服器從這些給定的方法中選擇一個并發送一個方法選中的消息回用戶端：

METHOD

如果選中的消息是X’FF’，這表示用戶端所列出的方法清單中沒有一個方法被選中，用戶端必須關閉連接配接。

目前定義的方法有：

· X’00’ 不需要認證

· X’01’ GSSAPI

· X’02’ 使用者名/密碼

· X’03’ -- X’7F’ 由IANA配置設定

· X’80’ -- X’FE’ 為私人方法所保留的

· X’FF’ 沒有可以接受的方法

然後客戶和伺服器進入由標明認證方法所決定的子協商過程(sub-negotiation)。各種不同的方法的子協商過程的描述請參考各自的備忘錄。

開發者如果要為自己的方法得到一個方法号，可以聯系IANA。可以參考關于已經被配置設定号碼的文檔以得到目前所有方法的清單和相應的協定。

符合本文檔的SOCKS V5實作必須支援GSSAPI，并且在将來支援使用者名/密碼認證方式。

一旦子協商過程結束後，用戶端就發送詳細的請求資訊。如果協商的方法中有以完整性檢查和/或安全性為目的的封裝，這些請求必須按照該方法所定義的方式進行封裝。

SOCKS請求的格式如下：

CMD

RSV

ATYP

DST.ADDR

DST.PROT

X’00’

Variable

2

其中

· VER 協定版本: 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 以網絡位元組順序出現的端口号

SOCKS伺服器會根據源位址和目的位址來分析請求，然後根據請求類型傳回一個或多個應答。

ATYP字段中描述了位址字段(DST.ADDR，BND.ADDR)所包含的位址類型：

· X'01'

基于IPV4的IP位址，4個位元組長

· X'03'

基于域名的位址，位址字段中的第一位元組是以位元組為機關的該域名的長度，沒有結尾的NUL位元組。

· X'04'

基于IPV6的IP位址，16個位元組長

一旦建立了一個到SOCKS伺服器的連接配接，并且完成了認證方式的協商過程，客戶機将會發送一個SOCKS請求資訊給伺服器。伺服器将會根據請求，以如下格式傳回：

REP

BND.ADDR

BND.PORT

其中：

· REP 應答字段:

· X’00’ 成功

· X’01’ 普通的SOCKS伺服器請求失敗

· X’02’ 現有的規則不允許的連接配接

· X’03’ 網絡不可達

· X’04’ 主機不可達

· X’05’ 連接配接被拒

· X’06’ TTL逾時

· X’07’ 不支援的指令

· X’08’ 不支援的位址類型

· X’09’ – X’FF’ 未定義

· IPV6：X’04’

· BND.ADDR 伺服器綁定的位址

· BND.PORT 以網絡位元組順序表示的伺服器綁定的段口

辨別為RSV的字段必須設為X’00’。

如果選中的方法中有以完整性檢查和/或安全性為目的的封裝，這些應答必須按照該方法所定義的方式進行封裝。

CONNECT

在對一個CONNECT指令的應答中，BND.PORT包含了伺服器配置設定的用來連到目标機的端口号，BND.ADDR則是相應的IP位址。由于SOCKS伺服器通常有多個IP，應答中的BND.ADDR常和用戶端連到SOCKS伺服器的那個IP不同。

SOCKS伺服器可以利用DST.ADDR和DST.PORT，以及用戶端源位址和端口來對一個CONNECT請求進行分析。

BIND

BIND請求通常被用在那些要求用戶端接受來自伺服器的連接配接的協定上。FTP是一個典型的例子。它建立一個從用戶端到伺服器端的連接配接來執行指令以及接收狀态的報告，而使用另一個從伺服器到用戶端的連接配接來接收傳輸資料的要求(如LS，GET，PUT)。

建議隻有在一個應用協定的用戶端在使用CONNECT指令建立主連接配接後才可以使用BIND指令建立第二個連接配接。建議SOCKS伺服器使用DST.ADDR和DST.PORT來評價BIND請求。

在一個BIND請求的操作過程中，SOCKS伺服器要發送兩個應答給用戶端。當伺服器建立并綁定一個新的套接口時發送第一個應答。BND.PORT字段包

含SOCKS伺服器用來監聽進入的連接配接的端口号，BAND.ADDR字段包含了對應的IP位址。用戶端通常使用這些資訊來告訴（通過主連接配接或控制連接配接）應

用伺服器連接配接的彙接點。第二個應答僅發生在所期望到來的連接配接成功或失敗之後。在第二個應答中，BND.PORT和BND.ADDR字段包含了連上來的主機

的IP位址和端口号。

UDP ASSOCIATE

UDP ASSOCIATE請求通常是要求建立一個UDP轉發程序來控制到來的UDP資料報。DST.ADDR和DST.PORT

字段包含用戶端所希望的用來發送UDP資料報的IP位址和端口号。伺服器可以使用這個資訊來限制進入的連接配接。如果用戶端在發送這個請求時沒有位址和端口信

息，用戶端必須用全0來填充。

當與UDP相應的TCP連接配接中斷時，該UDP連接配接也必須中斷。

應答UDP ASSOCIATE請求時，BND.PORT 和BND.ADDR字段指明了客戶發送UDP消息至伺服器的端口和位址。

應答處理

當一個應答(REP值不等于00)指明出錯時，SOCKS伺服器必須在發送完應答消息後一小段時間内終止TCP連接配接。這段時間應該在發現錯誤後少于10秒。

如果一個應答(REP值等于00)指明成功，并且請求是一個BIND或CONNECT時，用戶端就可以開始發送資料了。如果協商的認證方法中有以完整性、

認證和/或安全性為目的的封裝，這些請求必須按照該方法所定義的方式進行封裝。類似的，當以客戶機為目的地的資料到達SOCKS伺服器時，SOCKS服務

器必須用正在使用的方法對這些資料進行封裝。

在UDP

ASSOCIATE應答中由BND.PORT指明了伺服器所使用的UDP端口，一個基于UDP協定的客戶必須發送資料報至UDP轉發伺服器的該端口上。如

果協商的認證方法中有以完整性、認證和/或安全性為目的的封裝，這些資料報必須按照該方法所定義的方式進行封裝。每個UDP資料報都有一個UDP請求頭在

其首部：

FRAG

DST.PORT

DATA

在UDP請求頭中的字段是：

· RSV 保留 X’0000’

· FRAG 目前的分段号

· DATA 使用者資料

當一個UDP轉發伺服器轉發一個UDP資料報時，不會發送任何通知給用戶端；同樣，它也将丢棄任何它不能發至遠端主機的資料報。當UDP轉發伺服器從遠端伺服器收到一個應答的資料報時，必須加上上述UDP請求頭，并對資料報進行封裝。

UDP轉發伺服器必須從SOCKS伺服器得到期望的用戶端IP位址，并将資料報發送到UDP ASSOCIATE應答中給定的端口号。如果資料報從任何IP位址到來，而該IP位址與該特定連接配接中指定的IP位址不同，那麼該資料報會被丢棄。

FRAG字段指明資料報是否是一些分片中的一片。如果SOCKS伺服器要實作這個功能，X’00’指明資料報是獨立的；其他則越大越是資料報的尾端。介于

1到127之間的值說明了該分片在分片序列裡的位置。每個接收者都為這些分片提供一個重組隊列和一個重組的計時器。這個重組隊列必須在重組計時器逾時後重

新初始化，并丢棄相應的資料報。或者當一個新到達的資料報有一個比目前在處理的資料報序列中最大的FRAG值要小時，也必須重新初始化從組隊列。重組計時

器必須小于5秒。隻要有可能，應用程式最好不要使用分片。

分片的實作是可選的；如果某實作不支援分片，所有FRAG字段不為0的資料報都必須被丢棄。

一個SOCKS的UDP程式設計界面(The programming interface for a SOCKS-aware UDP)必須報告目前可用UDP資料報緩存空間小于作業系統提供的實際空間。

· 如果 ATYP是 X’01’ - 10+method_dependent octets smaller

· 如果 ATYP是X’03’ - 262+method_dependent octets smaller

· 如果 ATYP是X’04’ - 20+method_dependent octets smaller

這篇文檔描述了一個用來透過IP網絡防火牆的應用層協定。這種傳輸的安全性在很大程度上依賴于特定實作所擁有以及在SOCKS客戶與SOCKS伺服器之間經協商所標明的特殊的認證和封裝方式。

系統管理者需要對使用者認證方式的選擇進行仔細考慮。、

作者位址

Marcus Leech

Bell-Northern Research Ltd

P.O. Box 3511, Station C

Ottawa, ON

CANADA K1Y 4H7

Phone: (613) 763 - 9145

EMail: [email protected]

05-15 22:39