差不多是對rcf1928的翻譯。 【zz】
筆者在實際學習中，由於在有些軟件用到了socks5(如oicq,icq等)，對其原理不甚瞭解，相信很多朋友對其也不是很瞭解，於是仔細研讀
了一下rfc1928，覺得有必要譯出來供大家參考。
1．介紹：
防火牆的使用，有效的隔離了機構的內部網絡和外部網絡，這種類型的Internet架構變得越來越流行。這些防火牆系統大都充當着網絡之
間的應用層網關的角色，通常提供經過控制的Telnet,FTP,和SMTP訪問。爲了推動全球信息的交流，更多的新的應用層協議的推出。這就有必要
提供一個總的架構使這些協議能夠更明顯和更安全的穿過防火牆。也就有必要在實際上爲它們穿過防火牆提供一個更強的認證機制。這種需要
源於客戶機-服務器聯繫在不同組織網絡之間的實現，而這種聯繫需要被控制和是很大程度上被認證的。
該協議被描述爲用來提供在TCP和UDP域下爲客戶機-服務器應用程序便利和安全的穿過防火牆的一個架構。該協議在概念上被描述爲一個介
於應用層和傳輸層之間的"隔離層"，但是這類服務並不提供網絡層網關服務，如ICMP報文的傳輸。
2．現狀：
SOCKS
4爲基於TCP的客戶機-服務器應用程序提供了一種不安全的穿越防火牆的機制，包括TELNET,FTP和當前最流行的信息發現協議如HTTP,WAIS和GOP
HER.
新協議爲了包括UDP擴展了SOCKS
4，爲了包括對總體上更強的認證機制的支持擴展了協議架構，爲了包括域名和IPv6地址的支持擴展了地址集。
SOCKS協議執行最具代表性的是包括了在SOCKS庫中利用適當的封裝程序來對基於TCP的客戶程序進行重編譯和重鏈結。
注意：
除非特別提及，封裝在包格式中的十進制數表示的是通訊域的長度(用八位組octect表示)。一個給定的八位組必須具有指定的值，格式X'h
h'被用來表示在該域中單個八位組的值。當單詞"變量Variable"被使用時，它指出了通訊域擁有一個可變長度，這個可變長度要麼由一個聯合
的(一個或兩個八位組)長度域定義，要麼由一個數據類型域所定義。
3．基於TCP客戶機的程序
當一臺基於TCP的客戶機希望和目標主機建立連接時，而這臺目標主機只有經過防火牆才能到達(這種情況？一直持續到？它被執行時)，它
就必須在SOCKS服務器端的適當的SOCKS端口打開一個TCP連結。SOCKS服務按常例來說定位於TCP端口1080。如果連接請求成功，客戶機爲即將使
用的認證方式進行一種協商，對所選的方式進行認證，然後發送一個轉發請求。SOCKS服務器對該請求進行評估，並且決定是否建立所請求轉發
的連接。
客戶機連接到服務器，發送一個版本標識/方法選擇報文：
+----+----------+----------+
|VER | NMETHODS | METHODS |
+----+----------+----------+
| 1 | 1 | 1 to 255 |
+----+----------+----------+
VER(版本)在這個協議版本中被設置爲X'05'。NMETHODS(方法選擇)中包含在METHODS(方法)中出現的方法標識八位組的數目。
服務器從METHODS給出的方法中選出一種，發送一個METHOD selection(方法選擇)報文：
+----+--------+
|VER | METHOD |
+----+--------+
| 1 | 1 |
+----+--------+
如果所選擇的METHOD的值是X'FF',則客戶機所列出的方法是沒有可以被接受的，客戶機就必須關閉連接。
當前被定義的METHOD的值有：
>> X'00' 無驗證需求
>> X'01' 通用安全服務應用程序接口(GSSAPI)
>> X'02' 用戶名/密碼(USERNAME/PASSWORD)
>> X'03' 至 X'7F' IANA 分配(IANA ASSIGNED)
>> X'80' 至 X'FE' 私人方法保留(RESERVED FOR PRIVATE METHODS)
>> X'FF' 無可接受方法(NO ACCEPTABLE METHODS)
***IANA是負責全球INTERNET上的IP地址進行編號分配的機構(譯者著)***
於是客戶機和服務器進入方法細節的子商議。方法選擇子商議另外描述於獨立的文檔中。
欲得到該協議新的METHOD支持的開發者可以和IANA聯繫以求得到METHOD號。已分配號碼的文檔需要參考METHOD號碼的當前列表和它們的通
訊協議。
如果想順利的執行則必須支持GSSAPI和支持用戶名/密碼(USERNAME/PASSWORD)認證方法。
4．需求
一旦方法選擇子商議結束，客戶機就發送請求細節。如果商議方法包括了完整性檢查的目的和/或機密性封裝，則請求必然被封在方法選擇
的封裝中。
SOCKS請求如下表所示：
+----+-----+-------+------+----------+----------+
|VER | CMD | RSV | ATYP | DST.ADDR | DST.PORT |
+----+-----+-------+------+----------+----------+
| 1 | 1 | X'00' | 1 | Variable | 2 |
+----+-----+-------+------+----------+----------+
其中：
o VER protocol version：X'05'
o CMD
o CONNECT X'01'
o BIND X'02'
o UDP ASSOCIATE X'03'
o RSV RESERVED
o ATYP address type of following address
o IP V4 address: X'01'
o DOMAINNAME: X'03'
o IP V6 address: X'04'
o DST.ADDR desired destination address
o DST.PORT desired destination port in network octet order
5．地址
在地址域(DST.ADDR,BND.ADDR)中，ATYP域詳細說明了包含在該域內部的地址類型：
o X'01'
該地址是IPv4地址，長4個八位組。
o X'03'
該地址包含一個完全的域名。第一個八位組包含了後面名稱的八位組的數目，沒有中止的空八位組。
o X'04'
該地址是IPv6地址，長16個八位組。
6．迴應
到SOCKS服務器的連接一經建立，客戶機即發送SOCKS請求信息，並且完成認證商議。服務器評估請求，返回一個迴應如下表所示：
+----+-----+-------+------+----------+----------+
|VER | REP | RSV | ATYP | BND.ADDR | BND.PORT |
+----+-----+-------+------+----------+----------+
| 1 | 1 | X'00' | 1 | Variable | 2 |
+----+-----+-------+------+----------+----------+
其中：
o VER protocol version: X'05'
o REP Reply field:
o X'00' succeeded
o X'01' general SOCKS server failure
o X'02' connection not allowed by ruleset
o X'03' Network unreachable
o X'04' Host unreachable
o X'05' Connection refused
o X'06' TTL expired
o X'07' Command not supported
o X'08' Address type not supported
o X'09' to X'FF' unassigned
o RSV RESERVED
o ATYP address type of following address
o IP V4 address: X'01'
o DOMAINNAME: X'03'
o IP V6 address: X'04'
o BND.ADDR server bound address
o BND.PORT server bound port in network octet order
標誌RESERVED(RSV)的地方必須設置爲X'00'。
如果被選中的方法包括有認證目的封裝，完整性和/或機密性的檢查，則迴應就被封裝在方法選擇的封裝套中。
CONNECT
在CONNECT的迴應中，BND.PORT包括了服務器分配的連接到目標主機的端口號，同時BND.ADDR包含了關聯的IP地址。此處所提供的BND.ADDR
通常情況不同於客戶機連接到SOCKS服務器所用的IP地址，因爲這些服務器提供的經常都是多址的(muti-homed)。都期望SOCKS主機能使用DST.A
DDR和DST.PORT,連接請求評估中的客戶端源地址和端口。
BIND
BIND請求被用在那些需要客戶機接受到服務器連接的協議中。FTP就是一個衆所周知的例子，它通過使用命令和狀態報告建立最基本的客戶
機-服務器連接，按照需要使用服務器-客戶端連接來傳輸數據。(例如：ls,get,put)
都期望在使用應用協議的客戶端在使用CONNECT建立首次連接之後僅僅使用BIND請求建立第二次連接。都期望SOCKS主機在評估BIND請求時能夠
使用DST.ADDR和DST.PORT。
有兩次應答都是在BIND操作期間從SOCKS服務器發送到客戶端的。第一次是發送在服務器創建和綁定一個新的socket之後。BIND.PORT域包
含了SOCKS主機分配和偵聽一個接入連接的端口號。BND.ADDR域包含了關聯的IP地址。 客戶端具有代表性的是使用這些信息來通報應用程序
連接到指定地址的服務器。第二次應答只是發生在預期的接入連接成功或者失敗之後。在第二次應答中，BND.PORT和BND.ADDR域包含了欲連接
主機的地址和端口號。
UDP ASSOCIATE(連接？)
UDP
連接請求用來建立一個在UDP延遲過程中操作UDP數據報的連接。DST.ADDR和DST.PORT域包含了客戶機期望在這個連接上用來發送UDP數據報的地
址和端口。服務器可以利用該信息來限制至這個連接的訪問。如果客戶端在UDP連接時不持有信息，則客戶端必須使用一個全零的端口號和地址
。
當一個含有UDP連接請求到達的TCP連接中斷時，UDP連接中斷。
在UDP連接請求的迴應中，BND.PORT和BND.ADDR域指明瞭客戶端需要被髮送UDP請求消息的端口號/地址。
迴應過程
當一個迴應(REP值非X'00')指明失敗時，SOCKS主機必須在發送後馬上中斷該TCP連接。該過程時間必須爲在偵測到引起失敗的原因後不超
過10秒。
如果迴應代碼(REP值爲X'00')時，則標誌成功，請求或是BIND或是CONNECT，客戶機現在就可以傳送數據了。如果所選擇的認證方法支持完
整性、認證機制和/或機密性的封裝，則數據被方法選擇封裝包來進行封裝。類似，當數據從客戶機到達SOCKS主機時，主機必須使用恰當的認
證方法來封裝數據。
7. Procedure for UDP-based clients
A UDP-based client MUST send its datagrams to the UDP relay server at
the UDP port indicated by BND.PORT in the reply to the UDP ASSOCIATE
request. If the selected authentication method provides
encapsulation for the purposes of authenticity, integrity, and/or
confidentiality, the datagram MUST be encapsulated using the
appropriate encapsulation. Each UDP datagram carries a UDP request
header with it:
+----+------+------+----------+----------+----------+
|RSV | FRAG | ATYP | DST.ADDR | DST.PORT | DATA |
+----+------+------+----------+----------+----------+
| 2 | 1 | 1 | Variable | 2 | Variable |
+----+------+------+----------+----------+----------+
The fields in the UDP request header are:
o RSV Reserved X'0000'
o FRAG Current fragment number
o ATYP address type of following addresses:
o IP V4 address: X'01'
o DOMAINNAME: X'03'
o IP V6 address: X'04'
o DST.ADDR desired destination address
o DST.PORT desired destination port
o DATA user data
When a UDP relay server decides to relay a UDP datagram, it does so
silently, without any notification to the requesting client.
Similarly, it will drop datagrams it cannot or will not relay. When
a UDP relay server receives a reply datagram from a remote host, it
MUST encapsulate that datagram using the above UDP request header,
and any authentication-method-dependent encapsulation.
The UDP relay server MUST acquire from the SOCKS server the expected
IP address of the client that will send datagrams to the BND.PORT
given in the reply to UDP ASSOCIATE. It MUST drop any datagrams
arriving from any source IP address other than the one recorded for
the particular association.
The FRAG field indicates whether or not this datagram is one of a
number of fragments. If implemented, the high-order bit indicates
end-of-fragment sequence, while a value of X'00' indicates that this
datagram is standalone. Values between 1 and 127 indicate the
fragment position within a fragment sequence. Each receiver will
have a REASSEMBLY QUEUE and a REASSEMBLY TIMER associated with these
fragments. The reassembly queue must be reinitialized and the
associated fragments abandoned whenever the REASSEMBLY TIMER expires,
or a new datagram arrives carrying a FRAG field whose value is less
than the highest FRAG value processed for this fragment sequence.
The reassembly timer MUST be no less than 5 seconds. It is
recommended that fragmentation be avoided by applications wherever
possible.
Implementation of fragmentation is optional; an implementation that
does not support fragmentation MUST drop any datagram whose FRAG
field is other than X'00'.
The programming interface for a SOCKS-aware UDP MUST report an
available buffer space for UDP datagrams that is smaller than the
actual space provided by the operating system:
o if ATYP is X'01' - 10+method_dependent octets smaller
o if ATYP is X'03' - 262+method_dependent octets smaller
o if ATYP is X'04' - 20+method_dependent octets smaller
8. Security Considerations
This document describes a protocol for the application-layer
traversal of IP network firewalls. The security of such traversal is
highly dependent on the particular authentication and encapsulation
methods provided in a particular implementation, and selected during
negotiation between SOCKS client and SOCKS server.
Careful consideration should be given by the administrator to the
selection of authentication methods.
9. References
[1] Koblas, D., "SOCKS", Proceedings: 1992 Usenix Security Symposium.
Author's Address
Marcus Leech
Bell-Northern Research Ltd
P.O. Box 3511, Stn. C,
Ottawa, ON
CANADA K1Y 4H7
Phone: (613) 763-9145
EMail: [email protected]