SOCKS5协议中文翻译
SOCKS协议版本5
Network Working Group M. Leech
Request for Comments: 1928 Bell-Northern Research Ltd
Category: Standards Track M. Ganis
International Business Machines
Y. Lee
NEC Systems Laboratory
R. Kuris
Unify Corporation
D. Koblas
Independent Consultant
L. Jones
Hewlett-Packard Company
March 1996
互联网上搜索到SOCKS5协议中文版有不少，但不太适应他们的行文习惯，因此自译一篇留存。基本按照原文直译，部分内容按自己的理解作出行文上的修改。
本备忘录的状态
本文档为互联网社区规定了一个标准的互联网跟踪协议，希望大家可以讨论和建议如何改进。请参考当前版本的《互联网标准》（STD 1），以了解本协议的状态与其中的标准化描述。本备忘录的发布是不受限制的。
致谢
本备忘录描述了本协议上一版本（SOCKS4）的演变。新的协议来自于活跃的讨论与原型实现。关键的贡献者有：Marcus Leech: Bell-Northern Research, David Koblas:Independent Consultant, Ying-Da Lee: NEC Systems Laboratory, LaMontJones: Hewlett-Packard Company, Ron Kuris: Unify Corporation, MattGanis: International Business Machines。
1.介绍
网络防火墙系统的使用日益流行，这种系统有效将公司的内部网络与外部网络（例如英特网）阻隔开来。这些防火墙系统一般在不同网络体之间充当着应用层网关的作用，由它们对TELNET，FTP，SMTP等网络服务提供授权。为了促进全球信息发现，一些更复杂的协议被设计出来，有必要提供一种通用框架，以帮助（使用）这些协议（的流量）安全而透明地穿过防火墙。而在实际工作中，由于服务端与客户端存在于不同的公司网络之间，这些对防火墙的穿透行为还需要控制手段与强力的认证机制。
本协议旨在为使用TCP和UDP的CS结构程序提供一个框架，以帮助他们方便而安全地使用网络防火墙的服务。在概念上，本协议是位于应用层和传输层之间的“垫片层”，因此不提供网络层网关服务，例如ICMP消息的转发。
2.现有做法
目前我们拥有SOCKS协议的版本4，它为基于TCP的CS结构程序（包括TELNET、FTP，以及流行的信息发现协议例如HTTP、WAIS、GOPHER等）提供了不安全的防火墙穿透方案。
新的协议（版本5）扩展了SOCKS4，以支持UDP、强力认证以及通过域名和IPV6寻址。
实现对SOCKS5协议的支持，通常需要重新编译和链接基于TCP的客户端，以使用封装在SOCKS库中的子程序。
注意
除非另有说明，出现在包格式图表中的十进制数字表示相应字段的长度（以八位字节为单位）。如果某个字节必须设置为指定的值，这个值会被以X’hh’ 这样的语法表示（两位十六进制数）。当使用了’Variable’这个词，说明相应字段的长度是变化的，字节数由开头的（一个或两个字节）字段表示，或者由一个数据类型字段表示。
3. 基于TCP的客户端程序
当一个基于TCP的客户端程序希望连接到一个只能透过防火墙访问的对象（由于工程实现的缘由），它必须通过TCP连接到SOCKS服务端监听的SOCKS端口。按照传统，端口号一般为1080。连接成功后，如果有认证方式被启用，客户端将进入认证协商流程，使用被选择的方式进行认证，然后发送一条中继请求。SOCKS服务端将评估认证请求，并决定是否同意建立SOCKS连接。
除非另有说明，出现在包格式图表中的十进制数字表示相应字段的长度（以八位字节为单位）。如果某个字节必须设置为指定的值，这个值会被以X’hh’ 这样的语法表示（两位十六进制数）。当使用了’Variable’这个词，说明相应字段的长度是变化的，字节数由开头的（一个或两个字节）字段表示，或者由一个数据类型字段表示。
客户端向服务端发起连接，并发送一条【版本号/认证方式】选择消息：
| VER | NMETHODS | METHODS |
|---|---|---|
| 1 | 1 | 1 to 255 |
在本协议中，VER字段需要被设定为X’05’。NMETHODS字段表明了出现在METHODS子弹中的字节数量。
译者注：
| VER | NMETHODS | METHODS |
|---|---|---|
| 协议版本号（0x05） | 支持的认证方式数量 | 包含了所有支持的认证方式的编号的数组 |
服务端从METHODS中给出方式里选出一种，并发送一条METHOD（认证方式）选择消息：
| VER | METHOD |
|---|---|
| 1 | 1 |
如果被选择的方式为X’FF’，说明服务端不支持任何一种客户端提供的方式，客户端必须关闭连接。
METHOD字段的可选项如下：
| METHOD值 | 含义 |
|---|---|
| X’00’ | 不需要任何认证 |
| X’01’ | GSSAPI |
| X’02’ | 账户/密码 |
| X’03’到X’7F’ | IANA ASSIGNED |
| X’80’到X’FE’ | 被保留的私人方法 |
| X’FF’ | 没有可接受的方法 |
接下来客户端与服务端将进入被选择的认证方式对应的子流程。
认证方法相关的子流程将会在独立备忘录中被描述。
为协议提供新认证方式支持的开发者应该联系IANA以获得METHOD号码。号码分配文档应该提到现有的METHOD号码列表和和它们相应的协议。
规范的实现必须支持GSSAPI，也应该支持账户/密码的认证方式。
4. 请求消息
一旦认证协商相关的子流程结束，客户端将发送具体的请求消息。如果协商方式包含了以完整性检查和（或）安全性为目的的封装，请求消息必须是以该方式指定的方法封装。
SOCKS请求遵循以下格式：
| VER | CMD | RSV | ATYP | DST.ADDR | DST.PORT |
|---|---|---|---|---|---|
| 1 | 1 | X’00’ | 1 | Variable | 2 |
其中：
| 字段名 | 含义 |
|---|---|
| VER | 协议版本号：X’05’ |
| CMD | 指令（SOCKS连接方式） |
| RSV | 保留（置0） |
| ATYP | 地址类型 |
| DST.ADDR | 期望的目的地址 |
| DST.PORT | 期望的目的端口 |
| 指令 | 取值 |
|---|---|
| CONNECT（连接，如TCP） | X’01’ |
| BIND（绑定，如FTP） | X’02’ |
| UDP ASSOCIATE | X’03’ |
| 地址类型 | 取值 |
|---|---|
| IP V4 | X’01’ |
| 域名 | X’03’ |
| IP V6 | X’04’ |
SOCKS服务端一般将会基于源地址和目的地址评估请求，然后以请求类型对应的回复方式，返回一条或几条回复消息。
5. 地址
ATYP字段指定了地址字段（DST.ADDR，BIND.ADDR）的数据类型：
X’01’
地址类型为IPV4，长度为4个字节。
X’03’
地址类型为完全合格的域名。第一个字节为接下来域名所占的字节数，注意是没有NULL字节作为结束符的。
X’04’
地址类型为IPV6，长度为16字节。
6. 回复
在客户端与SOCKS服务器建立连接之后，它会尽快发送SOCKS请求信息，以及结束认证协商。服务端评估请求，并按以下格式进行回复：
| VER | REP | RSV | ATYP | BND.ADDR | BND.PORT |
|---|---|---|---|---|---|
| 1 | 1 | X’00’ | 1 | Variable | 2 |
其中：
| 字段名 | 含义 |
|---|---|
| VER | 协议版本号：X’05’ |
| REP | 回复内容 |
| RSV | 保留（置0） |
| ATYP | 地址类型 |
| BND.ADDR | 服务器绑定地址 |
| BND.PORT | 服务器绑定端口 |
| 回复内容 | 含义 |
|---|---|
| X’00’ | 成功 |
| X’01’ | SOCKS服务端的一般错误 |
| X’02’ | 被连接规则所禁止 |
| X’03’ | 网络无法访问 |
| X’04’ | 主机无法访问 |
| X’05’ | 连接被拒绝 |
| X’06’ | TTL超时 |
| X’07’ | 指令不支持 |
| X’08’ | 地址类型不受支持 |
| X’09’到X’FF’ | 未定义 |
| 地址类型 | 取值 |
|---|---|
| IP V4 | X’01’ |
| 域名 | X’03’ |
| IP V6 | X’04’ |
如果被选择的方式包含了目的为认证、完整性和（或）机密性的封装，回复需要被以该方式相应的封装方法进行封装。
CONNECT
当客户端选择CONNECT模式时，服务端的回复消息中，BND.PORT是服务端用来连接目的主机的端口号，同时BND.ADDR是相关的IP地址。被提供的BND.ADDR经常与客户端连接的SOCKS服务器IP不同，因为这些服务器经常是多宿主的（运行在不同的服务器上）。SOCKS服务端会在评估连接请求时综合考虑DST.ADDR、DST.PORT以及客户端的源地址与端口。
BIND
BIND请求被用于需要客户端接受来自服务端请求的协议中。FTP是一个常见的例子，在FTP中，由客户端到服务端的连接被用于指令和状态报告，而服务端到客户端的连接被用于按需求传输数据。
在应用层协议中，客户端侧最好只在已有主要连接使用CONNECT时，使用BIND请求建立次要连接。SOCKS服务器最好在评估BIND请求时考虑DST.ADDR和DST.PORT。
在一个BIND操作中，会有两条回复消息被SOCKS服务端发往客户端。第一条发送于服务端创建和绑定一个新socket之后。BND.PORT字段表示该socket监听的端口号。BND.ADDR表示该socket的IP。客户端一般会利用这些信息来通知（通过主连接或控制连接）服务端程序会合的地址。第二条回复消息只会在预期的连入请求成功或失败后发送。
在第二条回复消息中，BND.PORT和BND.ADDR字段是连接的主机的地址和端口号。
UDP ASSOCIATE
UDP ASSOCIATE请求被用于建立一个会话（以及与之相关的UDP中继过程）用来处理UDP数据报。DST.ADDR和DST.PORT字段指的是客户端期望UDP数据报发往的地址和端口。服务端可能会用这些信息来限定该会话的权限。如果客户端不再需要维持这个UDP会话，客户端必须使用全零的地址和端口号（来告知）。
当请求UDP会话的TCP连接被终止，该UDP会话也会终止。
在针对UDP ASSOCIATE请求的回复中，BND.PORT和BND.ADDR字段标明客户端发送需要被转发的UDP请求时使用的目标地址与端口。
Reply Processing（回复处理）
当一条回复消息表示出错（指REP字段不是X’00’时），SOCKS服务端必须在发送这条消息之后马上关闭该TCP连接。以检测出错误时为基准，不能超过10秒。
如果回复消息表示成功（指REP字段为X’00’时），且请求不是BIND或CONNECT，客户端可以马上开始发送数据。如果认证方式支持以完整性、认证、保密为目的的封装，数据必须先以指定的方式进行封装。近似地，当发往客户端的数据到达SOCKS服务端，服务端也必须按照指定的方式进行封装。
7. UDP客户端的流程
一个基于UDP的客户端必须将需要被转发的UDP数据报发往指定的端口，该端口由UDP ASSOCIATE请求的回复消息中的BND.PORT告知。如果认证方式提供以认证、完整性和（或）保密为目的的封装方法，数据报必须以该方法封装。每个UDP数据报携带一个如下所示的UDP请求头：
| RSV | FRAG | ATYP | DST.ADDR | DST.PORT | DATA |
|---|---|---|---|---|---|
| 2 | 1 | 1 | Variable | 2 | Variable |
请求头中字段的含义如下：
| 字段 | 含义 |
|---|---|
| RSV | 保留（置0） |
| FRAG | 当前帧号 |
| ATYP | 地址类型 |
| DST.ADDR | 目的地址 |
| DST.PORT | 目的端口 |
| DATA | 用户数据 |
| 地址类型 | 取值 |
|---|---|
| IP V4 | X’01’ |
| 域名 | X’03’ |
| IP V6 | X’04’ |
当一个UDP中继服务决定转发一个UDP数据报，他不会向请求客户端发送任何通知。近似地，当它不会或不能转发时，它会丢弃数据报。当一个UDP中继服务从远端收到一条转发数据报，它必须按照以上UDP请求头的格式封装该数据报，以及按照认证方式指定的方法封装。
UDP中继服务必须从SOCKS服务端获得将向BND.PORT（来自UDP ASSOCIATE回复消息）发送数据的客户端的IP地址。来自除这个IP地址之外的数据报都必须被丢弃。
FRAG字段表示的是这个数据报是否是某个数据帧中的一部分。在实现中，高位的一个bit表示在帧中的序号，X’00’标明这个数据报是独立的。1到127表示这个帧在帧序列中的位置。每个接收者会建立关于这些帧的重组队列和重组计时器。当计时器超时，重组队列必须丢弃所有帧且重置。正常情况下，一个新的数据报到达，它的FRAG字段会小于该帧序列处理的最高FRAG值。客户端应该尽量避免碎片帧的出现。
实现对碎片帧的支持是一个选项；不支持对碎片帧的支持的实现必须丢弃所有FRAG字段非零的数据报。
SOCKS-aware UDP的程序接口必须报告给UDP数据报一个可用的缓冲区，这个缓冲区应小于操作系统实际给出的空间大小：
| ATYP的值 | 空间大小 |
|---|---|
| X’01’ | 10+method_dependent octets smaller |
| X’03’ | 262+method_dependent octets smaller |
| X’04’ | 20+method_dependent octets smaller |
8. 安全注意事项
这篇文档阐述了一个穿透IP网络防火墙的应用层协议。这些穿透行为的安全性高度依赖特定实现提供的，在SOCKS客户端服务端协商中选定的，特定的认证方式与封装方法。
认证方式的选择应该由管理员认真考虑后设定。
9. 参考
[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: mleech@bnr.ca
