core
/
socks
1
0
Fork 0
Code Releases 1 Activity
A SOCKS (SOCKS4, SOCKS4A and SOCKS5) Proxy Package for Go
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
31 Commits
1 Branch
400 KiB
 
Branch: master
Branches Tags
${ item.name }
Create branch ${ searchTerm }
from 'master'
${ noResults }
socks/spec/SOCKS4.protocol.txt

151 lines
6.8 KiB
Raw Permalink Blame History 

  1. 	SOCKS: A protocol for TCP proxy across firewalls

  2. 

  3. 			Ying-Da Lee

  4. 		yingda@best.com  or  yingda@esd.sgi.com

  5. 

  6. SOCKS was originally developed by David Koblas and subsequently modified

  7. and extended by me to its current running version -- version 4. It is a

  8. protocol that relays TCP sessions at a firewall host to allow application

  9. users transparent access across the firewall. Because the protocol is

  10. independent of application protocols, it can be (and has been) used for

  11. many different services, such as telnet, ftp, finger, whois, gopher, WWW,

  12. etc. Access control can be applied at the beginning of each TCP session;

  13. thereafter the server simply relays the data between the client and the

  14. application server, incurring minimum processing overhead. Since SOCKS

  15. never has to know anything about the application protocol, it should also

  16. be easy for it to accommodate applications which use encryption to protect

  17. their traffic from nosey snoopers.

  18. 

  19. Two operations are defined: CONNECT and BIND.

  20. 

  21. 1) CONNECT

  22. 

  23. The client connects to the SOCKS server and sends a CONNECT request when

  24. it wants to establish a connection to an application server. The client

  25. includes in the request packet the IP address and the port number of the

  26. destination host, and userid, in the following format.

  27. 

  28. 		+----+----+----+----+----+----+----+----+----+----+....+----+

  29. 		| VN | CD | DSTPORT |      DSTIP        | USERID       |NULL|

  30. 		+----+----+----+----+----+----+----+----+----+----+....+----+

  31.  # of bytes:	   1    1      2              4           variable       1

  32. 

  33. VN is the SOCKS protocol version number and should be 4. CD is the

  34. SOCKS command code and should be 1 for CONNECT request. NULL is a byte

  35. of all zero bits.

  36. 

  37. The SOCKS server checks to see whether such a request should be granted

  38. based on any combination of source IP address, destination IP address,

  39. destination port number, the userid, and information it may obtain by

  40. consulting IDENT, cf. RFC 1413.  If the request is granted, the SOCKS

  41. server makes a connection to the specified port of the destination host.

  42. A reply packet is sent to the client when this connection is established,

  43. or when the request is rejected or the operation fails. 

  44. 

  45. 		+----+----+----+----+----+----+----+----+

  46. 		| VN | CD | DSTPORT |      DSTIP        |

  47. 		+----+----+----+----+----+----+----+----+

  48.  # of bytes:	   1    1      2              4

  49. 

  50. VN is the version of the reply code and should be 0. CD is the result

  51. code with one of the following values:

  52. 

  53. 	90: request granted

  54. 	91: request rejected or failed

  55. 	92: request rejected becasue SOCKS server cannot connect to

  56. 	    identd on the client

  57. 	93: request rejected because the client program and identd

  58. 	    report different user-ids

  59. 

  60. The remaining fields are ignored.

  61. 

  62. The SOCKS server closes its connection immediately after notifying

  63. the client of a failed or rejected request. For a successful request,

  64. the SOCKS server gets ready to relay traffic on both directions. This

  65. enables the client to do I/O on its connection as if it were directly

  66. connected to the application server.

  67. 

  68. 

  69. 2) BIND

  70. 

  71. The client connects to the SOCKS server and sends a BIND request when

  72. it wants to prepare for an inbound connection from an application server.

  73. This should only happen after a primary connection to the application

  74. server has been established with a CONNECT.  Typically, this is part of

  75. the sequence of actions:

  76. 

  77. -bind(): obtain a socket

  78. -getsockname(): get the IP address and port number of the socket

  79. -listen(): ready to accept call from the application server

  80. -use the primary connection to inform the application server of

  81.  the IP address and the port number that it should connect to.

  82. -accept(): accept a connection from the application server

  83. 

  84. The purpose of SOCKS BIND operation is to support such a sequence

  85. but using a socket on the SOCKS server rather than on the client.

  86. 

  87. The client includes in the request packet the IP address of the

  88. application server, the destination port used in the primary connection,

  89. and the userid.

  90. 

  91. 		+----+----+----+----+----+----+----+----+----+----+....+----+

  92. 		| VN | CD | DSTPORT |      DSTIP        | USERID       |NULL|

  93. 		+----+----+----+----+----+----+----+----+----+----+....+----+

  94.  # of bytes:	   1    1      2              4           variable       1

  95. 

  96. VN is again 4 for the SOCKS protocol version number. CD must be 2 to

  97. indicate BIND request.

  98. 

  99. The SOCKS server uses the client information to decide whether the

  100. request is to be granted. The reply it sends back to the client has

  101. the same format as the reply for CONNECT request, i.e.,

  102. 

  103. 		+----+----+----+----+----+----+----+----+

  104. 		| VN | CD | DSTPORT |      DSTIP        |

  105. 		+----+----+----+----+----+----+----+----+

  106.  # of bytes:	   1    1      2              4

  107. 

  108. VN is the version of the reply code and should be 0. CD is the result

  109. code with one of the following values:

  110. 

  111. 	90: request granted

  112. 	91: request rejected or failed

  113. 	92: request rejected becasue SOCKS server cannot connect to

  114. 	    identd on the client

  115. 	93: request rejected because the client program and identd

  116. 	    report different user-ids.

  117. 

  118. However, for a granted request (CD is 90), the DSTPORT and DSTIP fields

  119. are meaningful.  In that case, the SOCKS server obtains a socket to wait

  120. for an incoming connection and sends the port number and the IP address

  121. of that socket to the client in DSTPORT and DSTIP, respectively. If the

  122. DSTIP in the reply is 0 (the value of constant INADDR_ANY), then the

  123. client should replace it with the IP address of the SOCKS server to which

  124. the cleint is connected. (This happens if the SOCKS server is not a

  125. multi-homed host.)  In the typical scenario, these two numbers are

  126. made available to the application client prgram via the result of the

  127. subsequent getsockname() call.  The application protocol must provide a

  128. way for these two pieces of information to be sent from the client to

  129. the application server so that it can initiate the connection, which

  130. connects it to the SOCKS server rather than directly to the application

  131. client as it normally would.

  132. 

  133. The SOCKS server sends a second reply packet to the client when the

  134. anticipated connection from the application server is established.

  135. The SOCKS server checks the IP address of the originating host against

  136. the value of DSTIP specified in the client's BIND request.  If a mismatch

  137. is found, the CD field in the second reply is set to 91 and the SOCKS

  138. server closes both connections.  If the two match, CD in the second

  139. reply is set to 90 and the SOCKS server gets ready to relay the traffic

  140. on its two connections. From then on the client does I/O on its connection

  141. to the SOCKS server as if it were directly connected to the application

  142. server.

  143. 

  144. 

  145. 

  146. For both CONNECT and BIND operations, the server sets a time limit

  147. (2 minutes in current CSTC implementation) for the establishment of its

  148. connection with the application server. If the connection is still not

  149. establiched when the time limit expires, the server closes its connection

  150. to the client and gives up.