socks5协议（rfc1928）

备注：本篇文档是根据rfc1928协议和网络上相关的译文编写的，由于阅读这些内容时感觉到晦涩难懂。所以，在该文档中编写本篇内容时，夹杂了较多的个人理解的内容。这些内容难免会有理解错误的地方，希望在阅读时稍加注意。

1．背景

        防火墙的使用，有效的隔离了机构的内部网络和外部网络，这种类型的Internet架构变得越来越流行。这些防火墙系统大都充当着网络之间的应用层网关的角色，通常提供经过控制的Telnet、FTP和SMTP访问。为了推动全球信息的交流，更多的新的应用层协议的推出。这就有必要提供一个总的架构使这些协议能够更明显和更安全的穿过防火墙。也就有必要在实际上为它们穿过防火墙提供一个更强的认证机制。这种需要源于客户机-服务器联系在不同组织网络之间的实现，而这种联系需要被控制和是很大程度上被认证的。

        该协议框架是为了让使用TCP和UDP的客户/服务器应用程序更方便地使用网络防火墙所提供的服务所设计的。该协议在概念上被描述为一个介于应用层和传输层之间的"隔离层"，但是这类服务并不提供网络层网关服务，如ICMP报文的传输。

2．现有的协议

        SOCKS4为基于TCP的客户机/服务器应用程序提供了一种不安全的穿越防火墙的机制，包括TELNET、FTP和当前最流行的信息发现（information-discovery）协议如HTTP、WAIS和GOPHER. 这个新的协议扩展了SOCKS4模型以包含UDP，通过扩展了框架以包含通用强认证方案的条款，通过扩展地址解析方案(addressing scheme)以包含域名和IPV6地址。

        SOCKS协议的实现通常涉及到基于TCP的客户端应用程序的重新编译或者重新链接，以使用SOCKS库中适当的封装程序。

3．基于TCP客户机的程序

        当一个基于TCP协议的客户端希望与一个只能通过防火墙可以到达的目标(这是由实现所决定的)建立连接时，它就必须在SOCKS服务器端的适当的SOCKS端口打开一个TCP连接。S通常这个TCP端口是1080。当连接建立后，客户端进入协议的“握手(negotiation)”过程：认证方式的选择，根据选中的 方式进行认证，然后发送转发的要求。SOCKS服务器检查这个要求，根据结果，或建立合适的连接，或拒绝。

备注：

        除非特别说明，所有出现在报文格式图中的十进制数字均表示该字段的字节长度。如果某个字节需要给出具体的数值，则使用X’hh’的格式来表示这个字段的值。如果某个字段的给定的字节长度是’Variable’，则表示该字段的字节长度是可变的，具体的字节长度由一个相关联字段指定。该关联字段定义长度的方式有两种，一种是具体的长度数值（1-2个字节），另外一种是说明数值类型。

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

VER	NMETHODS	METHODS
1	1	1 to 255

这个版本的SOCKS协议中，VER字段被设置成X'05'。NMETHODS字段包含了在METHODS字段中出现的方法标示的数目（以字节为单位）（客户端可以指定多个方法组成一个方法列表供服务器端选择，这里的NMETHODS代表方法个数）。

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

VER	METHOD
1	1

如果选中的消息是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)

        然后客户和服务器进入由选定认证方法所决定的子协商过程(sub-negotiation)。各种不同的方法的子协商过程的描述请参考各自的备忘录。

        定义了支持该协议的新METHOD的开发者可以通过与IANA联系来获得METHOD号码。有关当前所有方法的列表和相应的协议可以参考已分配号码的文档（The ASSIGNED NUMBERS document）。

        符合本文档的SOCKS V5实现必须支持GSSAPI，并且在将来支持用户名/密码认证方式。

4．请求

        一旦子协商过程结束后，客户端就发送详细的请求信息。如果协商的方法中有以完整性检查和/或安全性为目的的封装，这些请求必须按照该方法所定义的方式进行封装。

SOCKS请求如下表所示：

VER	CMD	RSV	ATYP	DST.ADDR	DST.PORT
1	1	1	1	Variable	2

其中：

• VER protocol version：X'05'
• CMD
  • CONNECT X'01'
  • BIND X'02'
  • UDP ASSOCIATE X'03'
• RSV RESERVED（保留）
• ATYP address type of following address（后面的地址类型）
  • IP V4 address: X'01'
  • DOMAINNAME: X'03'
  • IP V6 address: X'04'
• DST.ADDR desired destination address（目的地地址）
• DST.PORT desired destination port in network octet order（目的地端口号）

SOCKS服务器会根据源地址和目的地址来分析请求，然后根据请求类型返回一个或多个应答。

5．地址

在地址域(DST.ADDR,BND.ADDR)中，ATYP域详细说明了包含在该域内部的地址类型：

• X'01' 该地址是IPv4地址，4个字节
• X'03' 基于域名的地址，地址字段中的第一字节是以字节为单位的该域名的长度，没有结尾的NUL字节
• X'04' 该地址是IPv6地址，16字节

6．应答

        一旦建立了一个到SOCKS服务器的连接，并且完成了认证方式的协商过程，客户机将会发送一个SOCKS请求信息给服务器。服务器将会根据请求，以如下格式返回：

VER	REP	RSV	ATYP	BND.ADDR	BND.PORT
1	1	1	1	Variable	2

其中：

• VER protocol version: X'05'
• REP Reply field:
  • X'00' succeeded
  • X'01' general SOCKS server failure（普通的SOCKS服务器请求失败）
  • X'02' connection not allowed by ruleset（现有的规则不允许的连接）
  • X'03' Network unreachable（网络不可达）
  • X'04' Host unreachable（主机不可达）
  • X'05' Connection refused
  • X'06' TTL expired（TTL超时）
  • X'07' Command not supported（不支持的命令）
  • X'08' Address type not supported（不支持的地址类型）
  • X'09' to X'FF' unassigned（未定义）
• RSV RESERVED（保留）
• ATYP address type of following address
  • IP V4 address: X'01'
  • DOMAINNAME: X'03'
  • IP V6 address: X'04'
• BND.ADDR server bound address（服务器绑定的地址）
• BND.PORT server bound port in network octet order（以网络字节顺序表示的服务器绑定的端口）

标志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）。

        如果人们希望某个应用协议的客户端可以使用BIND请求，那么需要先使用CONNECT命令建立主连接后才可以使用BIND命令建立第二个连接。在这个操作中SOCKS服务器将使用DST.ADDR和DST.PORT来评估这个BIND请求。

        在一个BIND请求的操作过程中，SOCKS服务器要发送两个应答给客户端。当服务器建立并绑定一个新的端口时发送第一个应答。BND.POR字段包含SOCKS服务器用来监听进入的连接的端口号，BND.ADDR字段包含了对应的IP地址。客户端通常使用这些信息来告诉（通过主连接或控制连接）应用服务器连接的汇接点。第二个应答仅发生在所期望到来的连接成功或失败之后。在第二个应答中，BND.PORT和BND.ADDR字段包含了连接主机的 IP地址和端口号。

个人理解：客户端通过SOCKS服务器与应用服务器发起请求时，需要在请求中携带响应地址（即汇接点 the rendezvous address）。操作顺序如下图：

 

UDP ASSOCIATE

        UDP ASSOCIATE请求用于在UDP转发进程中建立一个插口（an association）来处理UDP数据报。。客户端将要发送UDP数据报的地址和端口，由DST.ADDR和DST.PORT 字段指定。服务器可以使用这些信息来限制进入的连接。如果客户端在发送这个请求时没有地址和端口信息，客户端必须使用一个端口号和用全0表示的地址来填充。

        当与UDP ASSOCIATE相关的TCP连接中断时，该UDP association也会被终止。

        在应答UDP ASSOCIATE请求时，BND.PORT 和BND.ADDR字段指明了客户端发送UDP消息至服务器的端口和地址。

应答处理

        当一个应答(REP值不等于00)指明出错时，SOCKS服务器必须在发送完应答消息后一小段时间内终止TCP连接。这段时间应该在发现错误后少于10秒。

        如果一个应答(REP值等于00)指明成功，并且请求是一个BIND或CONNECT时，客户端就可以开始发送数据了。如果协商的认证方法中有以完整性、 认证和/或安全性为目的的封装，这些请求必须按照该方法所定义的方式进行封装。类似的，当客户机请求的数据到达SOCKS服务器时，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

UDP请求报头是：

• RSV Reserved X'0000'（保留X'0000'）
• FRAG Current fragment number（当前的分段号）
• ATYP address type of following addresses:
  • IP V4 address: X'01'
  • DOMAINNAME: X'03'
  • IP V6 address: X'04'
• DST.ADDR desired destination address（目的地址）
• DST.PORT desired destination port（目的地端口号）
• DATA user data（用户数据）

        当一个UDP转发服务器转发一个UDP数据报时，不会发送任何通知给客户端；同样，它也将丢弃任何它不能发至远端主机的数据报。当UDP转发服务器从远端服务器收到一个应答的数据报时，必须加上上述UDP请求头，并对数据报进行封装。

        UDP转发服务器必须从SOCKS服务器得到期望的客户端IP地址，并将数据报发送到UDP ASSOCIATE应答中给定的端口号。如果数据报从其他IP地址到来，而该IP地址与该特定连接中指定的IP地址不同，那么该数据报会被丢弃。

        FRAG字段指明当前接收的报文是否是完整的。如果实现了，FRAG字段的值越大表明该段报文越是整个数据报的尾端；当FRAG字段的值为X’00’时表明数据报是独立的。介于1到 127之间的值说明了该分端在分段序列里的位置。每个接收者都为这些分段提供一个重组队列和一个重组的计时器。这个重组队列必须在重组计时器超时后重新初始化，并丢弃相应的数据报。或者当一个新到达的数据报有一个比当前在处理的数据报序列中最大的FRAG值要小时，也必须重新初始化从组队列。重组计时器必须小于5秒。只要有可能，应用程序最好不要使用分片。

        分段的实现是可选的；如果某实现不支持分段，所有FRAG字段不为0的数据报都必须被丢弃。

        一个SOCKS的UDP编程界面(The programming interface for a SOCKS-aware UDP)必须报告当前可用UDP数据报缓存空间小于操作系统提供的实际空间。　

• • if ATYP is X'01' - 10+method_dependent octets smaller
  • if ATYP is X'03' - 262+method_dependent octets smaller
  • if ATYP is X'04' - 20+method_dependent octets smaller

个人理解：UDP代理相关流程如下图：

8．安全考虑

        这篇文档描述了一个用来透过IP网络防火墙的应用层协议。这种传输的安全性在很大程度上依赖于特定实现所拥有以及在SOCKS客户与SOCKS服务器之间经协商所选定的特殊的认证和封装方式。

        系统管理员需要对用户认证方式的选择进行仔细考虑。

 

参考链接：

https://www.ietf.org/rfc/rfc1928.txt  协议的TXT格式版本，内容排版不好，不适宜阅读

https://tools.ietf.org/pdf/rfc1928.pdf 协议的PDF格式版本，排版较好，适宜阅读

https://www.cnblogs.com/happyhotty/articles/2181522.html  本文档的主要参考译文，由中国互动出版网组织翻译

https://blog.csdn.net/cszhouwei/article/details/74362427  本文当的次要参考译文

http://www.cppblog.com/noflybird/archive/2009/12/26/104149.html  《SOCKS5协议的原理和应用》，本篇文章可以帮助理解SOCKS协议的相关信息

https://blog.csdn.net/cszhouwei/article/details/74362427  《SOCKS5代理原理探索》，作者使用了抓包工具对相关请求进行了分析