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