(RFC1928)SOCKS V5

【 tulaoshi.com - 编程语言 】

　　本备忘录状态：

　　本文档讲述了一种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．现有的协议

　　3．基于TCP协议的客户

　　4．请求

　　5．地址

　　6．应答

　　7．基于UDP协议的客户

　　8. 安全性考虑

　　9. 参考书目

　　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个字节）的域中，或一个数据类型域中。

　　客户端连到服务器后，然后就发送请求来协商版本和认证方法：

　　这个版本的SOCKS协议中，VER字段被设置成X'05'。NMETHODS字段包含了在METHODS字段中出现的方法标示的数目（以字节为单位）。

　　服务器从这些给定的方法中选择一个并发送一个方法选中的消息回客户端：

　　如果选中的消息是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 协议版本: 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 协议版本: 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不同。