|
组织：中国互动出版网（http://www.china-pub.com/）
RFC文档中文翻译计划（http://www.china-
pub.com/compters/emook/aboutemook.htm）
E-mail：ouyang@china-pub.com
译者：Radeon（Radeon bise@cmmail.com）
译文发布时间：2001-6-18
版权：本中文翻译文档版权归中国互动出版网所有。可以用于非商业用途自由转载，
但必须保留本文档的翻译及版权信息。
Network Working Group M. Leech
Request for Comments:1929 Bell-Northern Research Ltd
Category: Standard 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
SOCKS V5
本备忘录状态：
本文档讲述了一种Internet社区的Internet标准跟踪协议，它需要进一步进行讨论和建议以
得到改进。请参考最新版的“Internet正式协议标准” (STD1)来获得本协议的标准化程度和状
态。本备忘录的发布不受任何限制。
知识背景
这个备忘录描述了从同一协议的前一版本(版本4[1])发展而来的一个协议。这个新的协议起
源于当前的一些讨论和原型的实现(active discussions and prototype implementations)。关键的贡
献人有：Marcus Leech: Bell-Northern Research, David Koblas: Independent Consultant, Ying-Da
Lee: NEC Systems Laboratory, LaMont Jones: Hewlett-Packard Company, Ron Kuris: Unify
Corporation, Matt Ganis: International Business Machines。
目录
1.介绍 2
2．现有的协议 2
3．基于TCP协议的客户 3
4．请求 3
5．地址 4
6．应答 4
7．基于UDP协议的客户 6
8. 安全性考虑 7
9. 参考书目 7
1.介绍
利用网络防火墙可以将组织内部的网络结构从外部网络如INTERNET中有效地隔离，这种方法
在许多网络系统中正变得流行起来。这种防火墙系统通常以应用层网关的形式工作在两个网络之
间，提供TELNET、FTP、SMTP等的接入。随着越来越多的使全球信息查找更容易的复杂的应用层协
议的出现，有必要提供一个通用框架来使这些协议安全透明地穿过防火墙。而且在实际应用中还需
要一种安全的认证方式用以穿越防火墙。这个要求起源于两个组织的网络中客户/服务器关系的出
现，这个关系需要得到控制并要求有安全的认证。
在这儿所描述的协议框架是为了让使用TCP和UDP的客户/服务器应用程序更方便安全地使用
网络防火墙所提供的服务所设计的。这个协议从概念上来讲是介于应用层和传输层之间的“中介层
(shim-layer)”，因而不提供如传递ICMP信息之类由网络层网关的所提供的服务。
2．现有的协议
当前存在一个协议SOCKS 4，它为TELNET、FTP、HTTP、WAIS和GOPHER等基于TCP协议的客
户/服务器程序提供了一个不安全的防火墙。而这个新的协议扩展了SOCKS V4，以使其支持UDP、
框架规定的安全认证方案、地址解析方案(addressing scheme)中所规定的域名和IPV6。为了实现
这个SOCKS协议，通常需要重新编译或者重新链接基于TCP的客户端应用程序以使用SOCKS库中相
应的加密函数。
注意：
除非特别注明，所有出现在数据包格式图中的十进制数字均以字节表示相应域的长度。如
果某域需要给定一个字节的值，用X''''hh''''来表示这个字节中的值。如果某域中用到单
词''''Variable''''，这表示该域的长度是可变的，且该长度定义在一个和这个域相关联（1 – 2
个字节）的域中，或一个数据类型域中。
3．基于TCP协议的客户
当一个基于TCP协议的客户端希望与一个只能通过防火墙可以到达的目标(这是由实现所决定
的)建立连接，它必须先建立一个与SOCKS服务器上SOCKS端口的TCP连接。通常这个TCP端口是
1080。当连接建立后，客户端进入协议的“握手(negotiation)”过程：认证方式的选择，根据选
中的方式进行认证，然后发送转发的要求。SOCKS服务器检查这个要求，根据结果，或建立合适的
连接，或拒绝。
除非特别注明，所有出现在数据包格式图中的十进制数字均以字节表示相应域的长度。如果某
域需要给定一个字节的值，用X''''hh''''来表示这个字节中的值。如果某域中用到单
词''''Variable''''，这表示该域的长度是可变的，且该长度定义在一个和这个域相关联（1 – 2个
字节）的域中，或一个数据类型域中。
客户端连到服务器后，然后就发送请求来协商版本和认证方法：
VER
NMETHODS
METHODS
1
1
1 to 255
这个版本的SOCKS协议中，VER字段被设置成X''''05''''。NMETHODS字段包含了在METHODS字段中
出现的方法标示的数目（以字节为单位）。
服务器从这些给定的方法中选择一个并发送一个方法选中的消息回客户端：
VER
METHOD
1
1
如果选中的消息是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，并且在将来支持用户名/密码认证方式。
4．请求
一旦子协商过程结束后，客户端就发送详细的请求信息。如果协商的方法中有以完整性检查和
/或安全性为目的的封装，这些请求必须按照该方法所定义的方式进行封装。
SOCKS请求的格式如下：
VER
CMD
RSV
ATYP
DST.ADDR
DST.PORT
1
1
X''''00''''
1
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服务器会根据源地址和目的地址来分析请求，然后根据请求类型返回一个或多个应答。
5．地址
ATYP字段中描述了地址字段(DST.ADDR，BND.ADDR)所包含的地址类型：
? X''''01''''
基于IPV4的IP地址，4个字节长
? X''''03''''
基于域名的地址，地址字段中的第一字节是以字节为单位的该域名的长度，没有结尾的NUL字
节。
? X''''04''''
基于IPV6的IP地址，16个字节长
6．应答
一旦建立了一个到SOCKS服务器的连接，并且完成了认证方式的协商过程，客户机将会发送一
个SOCKS请求信息给服务器。服务器将会根据请求，以如下格式返回：
VER
REP
RSV
ATYP
BND.ADDR
BND.PORT
1
1
X''''00''''
1
Variable
2
其中：
? VER 协议版本: X''''05''''
? 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'''' 未定义
? RSV 保留
? ATYP 后面的地址类型
? IPV4：X''''01''''
? 域名：X''''03''''
? 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连接也必须中断。
[1] [2] 下一页
没有相关教程
| 
注：本站部分文章源于互联网，版权归原作者所有！如有侵权，请原作者与本站联系，本站将立即删除！ 本站文章除特别注明外均可转载，但需注明出处！ [MinTao学以致用网] 
